Re: Uploaded squeak-vm 3.11.3
Locked
12
12
Re: Uploaded squeak-vm 3.11.3
 
|
On 26.01.2010, at 05:31, José L. Redrejo wrote: > > I've just uploaded the latest version of the vm. > I've removed RomePlugin for all the archs, except i386. It's the only > one where I've tested it works. > I've also tempted of doing the same with ogg and gstreamer plugins, but > finally I've let them there. They segfaults often in amd64 too, but > don't do it unless the user tries to use those features. With Romeplugin > it was different: some squeak images (as etoys) have it activated by > default, so squeak segfaults when the image is loaded. Ah, right. I seem to remember there was a similar problem with Rome on the Mac. I'm cc'ing vm-dev ... > There are still some important bugs in Debian, and some very ugly > lintian messages. I don't have too much spare time, so I need some help > to deal with them: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497583 I have not ideas > to argue with this man. In fact, I think he might be totally right. Well, there is a source for this of course (in the VMMaker Squeak package). Generating the C code is a manual, interactive process and requires a running Squeak installation. Making that scriptable is possible, but so far nobody has done it AFAIK. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528774 : let's way how > the new package behaves in the autobuilders, but I'm not very > optimistic. My only idea is removing hppa arch from the package. Any > help in doing it is welcome too. Let's see how the new package builds, maybe it works better? - Bert - |
Re: Uploaded squeak-vm 3.11.3
|
|
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg <[hidden email]> wrote:
FYI, Peter von der Ahe did it in the Newspeak project. This isn't entirely relevant because some of this may be Newspeak code, but the source is available from http://newspeaklanguage.org/the-newspeak-programming-language/downloads/ & newspeak-source-2009-10-28.zip
|
Re: Uploaded squeak-vm 3.11.3
|
|
On 26.01.2010, at 11:03, Eliot Miranda wrote:
I guess you're referring to NsVmMaker.ns1? That does not seem to be used by the regular build process. I guess it is invoked manually to regenerate the sources. - Bert - |
Re: Uploaded squeak-vm 3.11.3
|
|
On Tue, Jan 26, 2010 at 11:56 AM, Bert Freudenberg <[hidden email]> wrote:
Yes-ish, IIRC from a gnu make makefile.
|
Re: Uploaded squeak-vm 3.11.3
|
|
On 26.01.2010, at 12:01, Eliot Miranda wrote:
If so, it's not included in the source release. No makefile (or other build-related file) refers to "NsVmMaker". Thanks anyway :) - Bert - |
|
|
On Tue, Jan 26, 2010 at 12:27:54PM -0800, Bert Freudenberg wrote: > > On 26.01.2010, at 12:01, Eliot Miranda wrote: > > > > On Tue, Jan 26, 2010 at 11:56 AM, Bert Freudenberg <[hidden email]> wrote: > > > > On 26.01.2010, at 11:03, Eliot Miranda wrote: > >> > >> > >> On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg <[hidden email]> wrote: > >> > >> On 26.01.2010, at 05:31, Jos? L. Redrejo wrote: > >> > > >> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497583 I have not ideas > >> > to argue with this man. In fact, I think he might be totally right. > >> > >> Well, there is a source for this of course (in the VMMaker Squeak package). Generating the C code is a manual, interactive process and requires a running Squeak installation. Making that scriptable is possible, but so far nobody has done it AFAIK. > >> > >> FYI, Peter von der Ahe did it in the Newspeak project. This isn't entirely relevant because some of this may be Newspeak code, but the source is available from http://newspeaklanguage.org/the-newspeak-programming-language/downloads/ & newspeak-source-2009-10-28.zip > >> > > > > I guess you're referring to NsVmMaker.ns1? That does not seem to be used by the regular build process. I guess it is invoked manually to regenerate the sources. > > > > Yes-ish, IIRC from a gnu make makefile. > > > If so, it's not included in the source release. No makefile (or other build-related file) refers to "NsVmMaker". > > Thanks anyway :) > > - Bert - > Got to give Tim Rowledge some credit on this one folks. Given a known directory structure and a VMMaker configuration file saved from a VMMakerTool, the script for generating the source code is just this: (VMMaker forConfigurationFile: 'myConfig.config') deleteEntireGeneratedTree; generateEntire. VMMaker is also designed to be scriptable (i.e. controllable independent of the VMMakerTool interactive tool). See Tim's class comment for details. Dave |
Re: Uploaded squeak-vm 3.11.3
|
|
In reply to this post by Bert Freudenberg
On Tuesday 26 January 2010 11:09:26 pm Bert Freudenberg wrote: > Well, there is a source for this of course (in the VMMaker Squeak package). > Generating the C code is a manual, interactive process and requires a > running Squeak installation. Making that scriptable is possible, but so > far nobody has done it AFAIK That is because most of the builds so far have been one target (which is also the host). Batch builds are needed for multiple variants (e.g debug/release) or when cross-compiling (say to ARM targets). Subbu |
Re: Uploaded squeak-vm 3.11.3
|
|
On 27.01.2010, at 05:37, K. K. Subramaniam wrote: > > On Tuesday 26 January 2010 11:09:26 pm Bert Freudenberg wrote: >> Well, there is a source for this of course (in the VMMaker Squeak package). >> Generating the C code is a manual, interactive process and requires a >> running Squeak installation. Making that scriptable is possible, but so >> far nobody has done it AFAIK > That is because most of the builds so far have been one target (which is also > the host). Batch builds are needed for multiple variants (e.g debug/release) > or when cross-compiling (say to ARM targets). Ian does batched cross-builds. But the source is still only generated once. All targets use the same generated sources. - Bert - |
Re: Uploaded squeak-vm 3.11.3
|
|
On Wed, Jan 27, 2010 at 7:26 AM, Bert Freudenberg <[hidden email]> wrote:
Ditto. We changed to a single src tree for Mac OS, win32 & linux very recently. The VMMaker per platform strikes me as absurd. All Microsoft and Mac compilers I've ever used are happy with LF line endings. The only significant difference between the platforms is whether to use the struct for interpreter variables and with a little macrology the choice can be left up to the platform's makefiles. In the Teleplace VMs the structure declaration looks like:
/*** Variables ***/ #if SQ_USE_GLOBAL_STRUCT
# define _iss /* define in-struct static as void */ struct foo {
#else # define _iss static
#endif _iss char * stackPointer;
_iss sqInt primFailCode; _iss sqInt specialObjectsOop;
_iss char * framePointer; _iss StackPage * stackPage;
_iss sqInt nilObj; ... _iss char * stackMemory; _iss sqInt theUnknownShort;
#undef _iss #if SQ_USE_GLOBAL_STRUCT
} fum; # define DECL_MAYBE_SQ_GLOBAL_STRUCT register struct foo * foo = &fum;
# define DECL_MAYBE_VOLATILE_SQ_GLOBAL_STRUCT volatile register struct foo * foo = &fum;
# define GIV(interpreterInstVar) (foo->interpreterInstVar) #else
# define DECL_MAYBE_SQ_GLOBAL_STRUCT /* oh, no mr bill! */ # define DECL_MAYBE_VOLATILE_SQ_GLOBAL_STRUCT /* oh no, mr bill! */
# define GIV(interpreterInstVar) interpreterInstVar #endif
#if SQ_USE_GLOBAL_STRUCT static struct foo * foo = &fum;
#endif and then a function that uses global variables looks like
EXPORT(sqInt) addGCRoot(sqInt *varLoc) {
DECL_MAYBE_SQ_GLOBAL_STRUCT if (GIV(extraRootCount) >= ExtraRootSize) {
return 0; }
GIV(extraRoots)[GIV(extraRootCount) += 1] = varLoc; return 1;
} And for us whether to use the global struct or not on Mac OS depends on whether we're using the Intel compiler or gcc. The Intel compiler produces an interpreter (not a JIT) that is 10% faster if it uses the global struct, whereas gcc produces one that is slightly slower. So making the choice depend on platform is a mistake anyway. It depends on platform and compiler.
|
|
|
On 27.01.2010, at 09:28, Eliot Miranda wrote:
Sounds cool. I'd love to have the generated sources to be identical across platforms, plus have the plugin sources be the same for internal and external plugins. For each plugin I'd like to choose to build it internally or externally or not at all, without regenerating. - Bert - |
Re: Uploaded squeak-vm 3.11.3
|
|
In reply to this post by David T. Lewis
On 26.01.2010, at 16:54, David T. Lewis wrote: > > > On Tue, Jan 26, 2010 at 12:27:54PM -0800, Bert Freudenberg wrote: >> >> On 26.01.2010, at 12:01, Eliot Miranda wrote: >>> >>> On Tue, Jan 26, 2010 at 11:56 AM, Bert Freudenberg <[hidden email]> wrote: >>> >>> On 26.01.2010, at 11:03, Eliot Miranda wrote: >>>> >>>> >>>> On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg <[hidden email]> wrote: >>>> >>>> On 26.01.2010, at 05:31, Jos? L. Redrejo wrote: >>>>> >>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497583 I have not ideas >>>>> to argue with this man. In fact, I think he might be totally right. >>>> >>>> Well, there is a source for this of course (in the VMMaker Squeak package). Generating the C code is a manual, interactive process and requires a running Squeak installation. Making that scriptable is possible, but so far nobody has done it AFAIK. >>>> >>>> FYI, Peter von der Ahe did it in the Newspeak project. This isn't entirely relevant because some of this may be Newspeak code, but the source is available from http://newspeaklanguage.org/the-newspeak-programming-language/downloads/ & newspeak-source-2009-10-28.zip >>>> >>> >>> I guess you're referring to NsVmMaker.ns1? That does not seem to be used by the regular build process. I guess it is invoked manually to regenerate the sources. >>> >>> Yes-ish, IIRC from a gnu make makefile. >> >> >> If so, it's not included in the source release. No makefile (or other build-related file) refers to "NsVmMaker". >> >> Thanks anyway :) >> >> - Bert - >> > > Got to give Tim Rowledge some credit on this one folks. Given a known > directory structure and a VMMaker configuration file saved from a > VMMakerTool, the script for generating the source code is just this: > > (VMMaker forConfigurationFile: 'myConfig.config') > deleteEntireGeneratedTree; > generateEntire. > > VMMaker is also designed to be scriptable (i.e. controllable independent > of the VMMakerTool interactive tool). See Tim's class comment for details. > > Dave Maybe I didn't make myself clear :) I know VMMaker is "scriptable" inside Squeak. What the OP was referring to was putting that translation step into a makefile. Which would need a tightly controlled setup of vm, image, and packages to work reliably. Which IMHO is too much trouble right now. Maybe we just need to come up with a satisfying answer to the question raised in the bug report? It seems as if just describing how this was generated might be sufficient. - Bert - |
Re: Uploaded squeak-vm 3.11.3
|
|
In reply to this post by Eliot Miranda-2
On Wed, 27 Jan 2010, Eliot Miranda wrote: > Ditto. We changed to a single src tree for Mac OS, win32 & linux very > recently. The VMMaker per platform strikes me as absurd. All Microsoft and > Mac compilers I've ever used are happy with LF line endings. The only > significant difference between the platforms is whether to use the struct > for interpreter variables and with a little macrology the choice can be > left up to the platform's makefiles. In the Teleplace VMs the structure > declaration looks like: Sounds good. Does it compile with gcc 4+? Will these changes be open source or should we redo them (or something similar)? Levente |
|
|
In reply to this post by Eliot Miranda-2
On 2010-01-27, at 9:28 AM, Eliot Miranda wrote:
BTW the register struct foo * foo = &fum stuck in the different procedures, (interp() can be different btw), was based on usage, I think use of > twice or something then it was inserted, otherwise it was not. At the time on the PowerPC the compiler would need 2 instructions to reference foo->erk, loading foo out of the global area, then doing foo->fum If foo was local to the procedure then it was one instruction taking foo in register N and loading with offset. So you needed > 2 references to justify the cost of loading into a register then using. The use of register keyword over time is respected or not by the compiler and compiler version. For interp() the construct for referring to foo can significantly effect bytecode rates again depending on the compiler etc. -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
|
In reply to this post by Bert Freudenberg
On Wed, Jan 27, 2010 at 9:34 AM, Bert Freudenberg <[hidden email]> wrote:
Yes, that's what we do. Basically plugins.int plugins.ext and sqNamedPrims.h are part of the platform's makefiles (although sqNamedPrims.h should be generated), and so one pushes out a superset of the plugins and decides in the platform makefiles which to include and which are internal or external. As soon as my Feb deliverable is done I'll put some energy into getting Cog released.
best Eliot
|
Re: Uploaded squeak-vm 3.11.3
|
|
In reply to this post by Levente Uzonyi-2
2010/1/27 Levente Uzonyi <[hidden email]>
yes. Will these changes be open source or should we redo them (or something similar)? They would be open source. I just have to find the time to make a release.
|
|
|
In reply to this post by Bert Freudenberg
On Wed, Jan 27, 2010 at 09:41:26AM -0800, Bert Freudenberg wrote: > > On 26.01.2010, at 16:54, David T. Lewis wrote: > > > > VMMaker is also designed to be scriptable (i.e. controllable independent > > of the VMMakerTool interactive tool). See Tim's class comment for details. > > Maybe I didn't make myself clear :) Sorry, my mistake. > I know VMMaker is "scriptable" inside Squeak. What the OP was referring > to was putting that translation step into a makefile. Which would need > a tightly controlled setup of vm, image, and packages to work reliably. > Which IMHO is too much trouble right now. Agreed. On a related note, we seem to be running into problems with people taking the existing generated sources from platforms/unix/src and doing a configure/make on their 64 bit Linux box, resulting in a broken VM. Their expectation that this should work is perfectly reasonable, but the fact is that it does not; we still have too many broken plugins on 64 bits. I'm not sure how best to prevent this problem, although possibly just adding -m32 to the CFLAGS as a default would help (I'm not sure if this is safe to do for all the various unices). > Maybe we just need to come up with a satisfying answer to the question > raised in the bug report? It seems as if just describing how this was > generated might be sufficient. That would certainly be the simplest solution, and if it turns out not to be good enough, it would at least make it easier to identify what *would* be sufficient. Dave |
Re: Uploaded squeak-vm 3.11.3
|
|
On Wed, 27 Jan 2010, David T. Lewis wrote: > > On Wed, Jan 27, 2010 at 09:41:26AM -0800, Bert Freudenberg wrote: >> >> On 26.01.2010, at 16:54, David T. Lewis wrote: >>> >>> VMMaker is also designed to be scriptable (i.e. controllable independent >>> of the VMMakerTool interactive tool). See Tim's class comment for details. >> >> Maybe I didn't make myself clear :) > > Sorry, my mistake. > >> I know VMMaker is "scriptable" inside Squeak. What the OP was referring >> to was putting that translation step into a makefile. Which would need >> a tightly controlled setup of vm, image, and packages to work reliably. >> Which IMHO is too much trouble right now. > > Agreed. On a related note, we seem to be running into problems with people > taking the existing generated sources from platforms/unix/src and doing > a configure/make on their 64 bit Linux box, resulting in a broken VM. > Their expectation that this should work is perfectly reasonable, but the > fact is that it does not; we still have too many broken plugins on 64 bits. > > I'm not sure how best to prevent this problem, although possibly just > adding -m32 to the CFLAGS as a default would help (I'm not sure if this > is safe to do for all the various unices). I had an issue earlier with -m32. I had to tell the linker that the object files are for 32 bit otherwise the build process stopped with an error message. Some plugins had their own flags which couldn't be overriden by CFLAGS (FloatMathPlugin for example, don't know if it still uses -O only). My (quick-and-dirty) workaround was to pass the compiler arguments in CC and leave CFLAGS empty. (CC="gcc -m32 ..." CFLAGS="") Levente > >> Maybe we just need to come up with a satisfying answer to the question >> raised in the bug report? It seems as if just describing how this was >> generated might be sufficient. > > That would certainly be the simplest solution, and if it turns out not > to be good enough, it would at least make it easier to identify what > *would* be sufficient. > > Dave > > |
Re: Uploaded squeak-vm 3.11.3
|
|
In reply to this post by Bert Freudenberg
On Thursday 28 January 2010 10:08:11 am Eliot Miranda wrote: > So while attractive in the abstract I think making the generated sources > purely an intermediate form is a mistake. In this case If It Ain't Broke > Don't Fix It. The issue is a practical one for Debian packagers. From copyright and licensing viewpoints should the generated files be considered "source" or "intermediate"? If it is a source file, then where can one find the corresponding copyright and license terms? BTW, I found the necessary information in platforms/unix/doc/ directory (HowToBuildFromSource.*, COPYRIGHT and LICENSE files). I assume these should be sufficient to answer the queries raised in the bug report. Subbu |
|
|
In reply to this post by Bert Freudenberg
On 28 January 2010 06:38, Eliot Miranda <[hidden email]> wrote: > > > > On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam <[hidden email]> wrote: >> >> On Wednesday 27 January 2010 08:56:07 pm Bert Freudenberg wrote: >> > On 27.01.2010, at 05:37, K. K. Subramaniam wrote: >> > > On Tuesday 26 January 2010 11:09:26 pm Bert Freudenberg wrote: >> > >> Well, there is a source for this of course (in the VMMaker Squeak >> > >> package). Generating the C code is a manual, interactive process and >> > >> requires a running Squeak installation. Making that scriptable is >> > >> possible, but so far nobody has done it AFAIK >> > > >> > > That is because most of the builds so far have been one target (which is >> > > also the host). Batch builds are needed for multiple variants (e.g >> > > debug/release) or when cross-compiling (say to ARM targets). >> > >> > Ian does batched cross-builds. But the source is still only generated once. >> > All targets use the same generated sources. >> The generated files are not the "source". To reiterate the issue raised in the >> bug report - >> --- >> the file platforms/unix/src/vm/interp.c starts with: >> >> /* Automatically generated from Squeak on an Array(9 May 2008 11:24:03 am) >> by VMMaker 3.8b6 [...] >> >> However, I cannot identify the source file for that file. Also, >> debian/copyright doesn't contain any hint how this file is generated. > > Indeed. In the Teleplace VMs we generate e.g. > /* Automatically generated by > CCodeGenerator VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431 > from > SimpleStackBasedCogit VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431 > */ > static char __buildInfo[] = "SimpleStackBasedCogit VMMaker-eem.524 uuid: 9b748596-0986-4ca7-ac5b-b7a050a08431 " __DATE__ ; > char *__cogitBuildInfo = __buildInfo; > > where the UUIDs are those form the Monticello package. If the package is dirty when the source file is output it gains an asterisk: > /* Automatically generated by > CCodeGeneratorGlobalStructure * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be > from CoInterpreter * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be > */ > static char __buildInfo[] = "CoInterpreter * VMMaker-eem.519 uuid: 151cad6d-ee56-4458-a45d-a5c53502b5be " __DATE__ ; > char *__interpBuildInfo = __buildInfo; > So we can determine both the Smalltalk source and the version of the generator that pushed out the C, or if it was an indeterminate version. This is also available through the system parameter primitive. Also note that tehthedate is the date of compilation, not generation, which should be immaterial. > >> ---- >> The "source" for this file is in embedded in vmmaker image. The header only >> states that VMMaker was used as a tool but it is not evident that this version >> of VMMaker also embeds the "source" for the interpreter (and the plugins). I >> realize the tool and the sources are all one big blob in Squeak, but we still >> need to consider interpreter and plugins as separate units during builds. >> >> So the questions that arise for downstream builders are : >> >> a) Where is the information about generating this intermediate file from the >> source? (i.e. tool, makefile, batch script) >> b) What is the license on that particular source unit which was used to >> generate this intermediate file? Should all plugins use the same license as the >> interpreter? >> >> In a manual process, these are all "in the head" but that doesn't help >> downstream builders like Debian. In a batch process these steps are recorded >> in scripts for anyone to read, follow and modify, if necessary. >> >> Isn't "generated source" an oxymoron :-)? I would favor getting rid of these >> files from version control and go directly to filing Slang changesets into >> VMMaker and translating them on the fly in Makefiles. I would even support >> writing unix/ and Cross/ in Slang. Let C become the assembly language in >> Squeak. > > Practically it is much more convenient to be able to gather all the C/C++ files together for a Vm build than it is to start form a set of C/C++ files and a Smalltalk source file and a Smalltalk image and a tool. We keep an image containing a VMMaker in svn (in a directory image alongside platforms) and generate the vm/plugin tree form that image, updating it when VMMaker or a plugin is changed. So a checking checks in the new source and the new image. But if one wants to build one simply checks out the entire tree and builds, instead of having to fire up the VMMaker image. Once Squeak is reliably headlessly scriptable across platforms one might revisit that but then you'd introduce a dependency of having to have a working VM to run VMMaker to punch out the sources, which could put a damper on developing for new platforms. That's really wrong. Ask yourself, what you would do with those C/C++ sources, while not having C compiler for new platform? Yes! First, you will need to build a compiler binary for target platform on a platform where compiler exists and can run, and only then you could move inside and use it on new platform to compile stuff. So, why it should be different for VM? Migrating to new platform always means using some tool chain on existing platform(s) to generate appropriate bootstrap code/binaries. Sure , you can go without it, if you want to fall back to 60-70's era, where no common tools existed and you had to work with binary data manually and bootstrap from ZERO point. But that would be really stupid and we should discourage people from porting VM in such way. > So while attractive in the abstract I think making the generated sources purely an intermediate form is a mistake. In this case If It Ain't Broke Don't Fix It. >> >> Subbu -- Best regards, Igor Stasenko AKA sig. |
Re: Uploaded squeak-vm 3.11.3
|
|
On Thu, Jan 28, 2010 at 3:19 PM, Igor Stasenko <[hidden email]> wrote:
I don't think it's wrong at all. The current Squeak CVM is entirely dependent on having a C compiler. If one doesn't have a C compiler one can't have a Squeak VM, i's as simple as that. The platforms tree is C, the generated source is C.
You have an argument only when the system becomes self-hosting, targeting either assembler or machine code, and there are a host of other issues lurking there such as what one uses for debugging, whether one has to generate debug info in the object code, etc, etc. But for the current VM a C compiler is an absolute prerequisite.
Yes! First, you will need to build a compiler binary for target Go ahead and change it. But the current VM is based on the availability of a C compiler and so including the src tree in svn is perfectly reasonable.
Migrating to new platform always means using some tool chain on |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |