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 -
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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.
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.ziphttp://downloads.sourceforge.net/newspeakpl/newspeak-source-2009-10-28.zip
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 -
On 26.01.2010, at 11:03, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.de 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.
- Bert -
On Tue, Jan 26, 2010 at 11:56 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 26.01.2010, at 11:03, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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.ziphttp://downloads.sourceforge.net/newspeakpl/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.
- Bert -
On 26.01.2010, at 12:01, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 11:56 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.01.2010, at 11:03, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.de 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 -
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 bert@freudenbergs.de wrote:
On 26.01.2010, at 11:03, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.de 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
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 bert@freudenbergs.de wrote:
On 26.01.2010, at 11:03, Eliot Miranda wrote:
On Tue, Jan 26, 2010 at 9:39 AM, Bert Freudenberg bert@freudenbergs.de 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 -
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
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
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
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 -
On Wed, Jan 27, 2010 at 7:26 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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.
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.
- Bert -
On 27.01.2010, at 09:28, Eliot Miranda wrote:
On Wed, Jan 27, 2010 at 7:26 AM, Bert Freudenberg bert@freudenbergs.de 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.
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.
- Bert -
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 -
On Wed, Jan 27, 2010 at 9:34 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 27.01.2010, at 09:28, Eliot Miranda wrote:
On Wed, Jan 27, 2010 at 7:26 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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.
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.
- Bert -
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.
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
- Bert -
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
2010/1/27 Levente Uzonyi leves@elte.hu
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+?
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.
Levente
On 2010-01-27, at 9:28 AM, Eliot Miranda wrote:
# define DECL_MAYBE_SQ_GLOBAL_STRUCT register struct foo * foo = &fum; # define DECL_MAYBE_VOLATILE_SQ_GLOBAL_STRUCT volatile register struct foo * foo = &fum;
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 johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
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. ---- 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.
Subbu
On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam subbukk@gmail.comwrote:
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.
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
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
On 28 January 2010 06:38, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam subbukk@gmail.com 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
On Thu, Jan 28, 2010 at 3:19 PM, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2010 06:38, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam subbukk@gmail.com
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?
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
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?
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
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.
On 29 January 2010 19:02, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Jan 28, 2010 at 3:19 PM, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2010 06:38, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Jan 27, 2010 at 7:13 PM, K. K. Subramaniam subbukk@gmail.com 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?
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.
If one doesn't have/can't run VMMaker, one couldn't have VM, its as simple as that. ;) It would be miracle if all what you would need to port Squeak on new platform is to have just a C compiler and VM sources. But that's too far from true. So, what the point in sticking with just C compiler toolchain and pretending that we could avoid using VMMaker when building VM? C compiler is just a basic tool in toolchain, and being alone it worthless , because as developer who porting VM you should have a full access to every stage of VM building process, starting from VMMaker. Its obvious!
I repeat: VMMaker _is_ a dependency, which we can't avoid, as well as C compiler. And hindering it behind providing a pregenerated C sources is really bad and misleading approach. A generated source don't have any value if you can't access to tool which generating them.
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.
You forgot about other prerequisites, including: make, gawk, CMake etc etc. A whole host staying behind C tool chain. But again, i'm not trying to dismantle the rule C compiler. I just want to put VMMaker on top of it making it the first absolute prerequisite above anything else.
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?
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.
Example: many of linux packages providing an html documentation. But instead html format they using a bare-bone sgml or xml files, which require an additional stages/tools to get an html docs out of them. Moreover, some packages assuming that people know how to generate html from sgml and even not including makefile rules for generating these docs. Javadoc is another example.. Example2: yacc/byson sources. Same thing. A C code is generated from corresponding .Y files and on my own experience porting projects on windows, where i had only C compiler, i had first to get and build a byson tool first.
So, what are you talking about? Instead of stating from very starting: don't even think of building VM without VMMaker, we including the pregenerated sources into svn tree, in this way, making people think, that this is all what they need. And then over and over again, every time someone new coming and asking the very same question: WTF, VM can't be built? why my VM defunct? etc etc..
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.
vm-dev@lists.squeakfoundation.org