64-bit VMs
Locked
12
12
 
|
Folks,
I've just released 64-bit compatible sources for 3.8, and checked-in both Unix and Cross changes to the TRUNK of the repository. To build a Unix VM from the repository, first check out the trunk as usual, then: mkdir bld cd bld ../platforms/unix/config/configure --with-src=src32 make will build a 32-bit VM. If you say ../platforms/unix/config/configure --with-src=src64 instead then it will build you a 64-bit VM. I have tested both 32- and 64-bit VMs on PowerPC (32-bit native), Intel Pentium and Intel Itanium 2. All appears to work. Note that I have made some changes to the platforms/Cross part of the repository. While I tried hard to keep things as backwardly compatible as possible (e.g., the Unix tree happily compiles pre-3.8 sources as-is) this might have temporarily broken the build for other platforms. My apologies if this is the case, OTOH it's a wonderful forcing function to have the maintainer of your favorite platform get a 64-bit VM out the door Real Soon Now. I've not had chance to update my usual download page to reflect the new 32/64 duality in the distribution, but I did have time to make some archives of source code, 32- and 64-bit images, and 32- and 64-bit VMs for the three architectures mentioned above. You can pick them up here: http://squeak.hpl.hp.com/squeak64/dist3/ wherein: Squeak-3.8a-2.src.tar.gz contains the source code, and a handy one-stop top-levelMakefile at which you can type 'make WIDTH=32' and 'make width=64'. Squeak32-3.8g-6548.image.tar.gz Squeak64-3.8g-6548.image.tar.gz contain 32- and 64-bit images, respectively. (Note that I had to condense the changes in the base 3.8g-6548 image because of reaching the limit on source position stamp.) Squeak32-3.8a-2.i686-pc-linux-gnu.tar.gz Squeak32-3.8a-2.ia64-linux-gnu.tar.gz Squeak32-3.8a-2.powerpc-apple-darwin7.8.0.tar.gz contain 32-bit VMs precompiled for Pentium, Itanium 2 and PowerPC. Squeak64-3.8a-2.i686-pc-linux-gnu.tar.gz Squeak64-3.8a-2.ia64-linux-gnu.tar.gz Squeak64-3.8a-2.powerpc-apple-darwin7.8.0.tar.gz contain 64-bit VMs precompiled for Pentium, Itanium 2 and PowerPC. Finally... ChangeSets is a directory containing everything that was used to create the above, relative to the base 3.8g-6548 image: VMMaker-tpr.14.mcz is Tim's latest VMMaker. VMM38b4-64bit-vm1-ikp.1.cs are Dan and my 64-bit changes, plus various changes Tim made to VMM since 3.7-5, all spiffed up and including a final couple of (nasty) new bugs (one original bug, and a few that crept in which merging VMM with the 64-bit changes) thoroughly fixed. This gets you enough to generate interp.c plus the three essential plugins: BitBlt, Ballon and File. VMM38b4-64bit-vm2-ikp.2.cs is new 64-bit support for plugins using the SmartSyntax thing. I made SocketPlugin (which uses it) 64-bit clean to make sure it was working reasonably. With both of the above loaded you should be able to regenerate the src32 and src64 trees included in the source tarball (and included in the unix part of the repository). System-Tracing.2.cs is the new SystemTracer from Anthony and Stephen, subclassed by Dan to make 64-bit images. This ONLY works on big-endian machines for now. (We know about this. Don't yell at us.) VMM38b4-64bit-image1-ikp.1.cs VMM38b4-64bit-image2-ikp.1.cs contain various changes to the class library that you probably need to have a healthy image running with 64-bit oops. (Tim, especially, will want to take the vm1 and vm2 changesets and file them into VMMaker _immediately_, before it becomes a 'moved target' [again]. No need to read these files: they are the changes Dan and I sent you, that you sent back last week with your recent VMM additions filed-in over the top, in which I then fixed some subtle 'merge' bugs that crept in during the process along with the WeakArray problem in primStringReplace posted to squeak-dev a couple of days ago. Trust me. Just hit 'install'. It's one huge chunk of goodness.) Enjoy! Ian (totally exhausted, and declaring the weekend already arrived ;-) |
|
|
In message <[hidden email]>
Ian Piumarta <[hidden email]> wrote: > Folks, > > I've just released 64-bit compatible sources for 3.8, and checked-in > both Unix and Cross changes to the TRUNK of the repository. Curio noticed while comparing dirs to see what changed; the unix 'configure' script is - wait for it - 839Kb in size! Good grief. And aclocal.m4 is another 213Kb. Whatever happened to lean, mean unix? Did it get too many tokens for super-duper-sizing at mcdonalds? Aside from that it looks good so far. I'll probably get a revised VMMaker out tomorrow. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Useful random insult:- An 8080 in a StrongARM environment. |
|
|
On Thu, Mar 31, 2005 at 06:50:05PM -0800, Tim Rowledge wrote:
> Curio noticed while comparing dirs to see what changed; the unix 'configure' > script is - wait for it - 839Kb in size! Good grief. And aclocal.m4 is another > 213Kb. Whatever happened to lean, mean unix? Did it get too many tokens for > super-duper-sizing at mcdonalds? About every 30 years or so you have to do a Unix>>condenseChanges. Dave |
|
|
In reply to this post by Ian Piumarta-3
Thanks Ian! This is wonderful progress.
Cheers, - Andreas Ian Piumarta wrote: > Folks, > > I've just released 64-bit compatible sources for 3.8, and checked-in > both Unix and Cross changes to the TRUNK of the repository. > > To build a Unix VM from the repository, first check out the trunk as > usual, then: > > mkdir bld > cd bld > ../platforms/unix/config/configure --with-src=src32 > make > > will build a 32-bit VM. If you say > > ../platforms/unix/config/configure --with-src=src64 > > instead then it will build you a 64-bit VM. > > I have tested both 32- and 64-bit VMs on PowerPC (32-bit native), > Intel Pentium and Intel Itanium 2. All appears to work. > > Note that I have made some changes to the platforms/Cross part of the > repository. While I tried hard to keep things as backwardly > compatible as possible (e.g., the Unix tree happily compiles pre-3.8 > sources as-is) this might have temporarily broken the build for other > platforms. My apologies if this is the case, OTOH it's a wonderful > forcing function to have the maintainer of your favorite platform get > a 64-bit VM out the door Real Soon Now. > > I've not had chance to update my usual download page to reflect the > new 32/64 duality in the distribution, but I did have time to make > some archives of source code, 32- and 64-bit images, and 32- and > 64-bit VMs for the three architectures mentioned above. You can pick > them up here: > > http://squeak.hpl.hp.com/squeak64/dist3/ > > wherein: > > Squeak-3.8a-2.src.tar.gz > contains the source code, and a handy one-stop top-levelMakefile > at which you can type 'make WIDTH=32' and 'make width=64'. > > Squeak32-3.8g-6548.image.tar.gz > Squeak64-3.8g-6548.image.tar.gz > contain 32- and 64-bit images, respectively. (Note that I had > to condense the changes in the base 3.8g-6548 image because > of reaching the limit on source position stamp.) > > Squeak32-3.8a-2.i686-pc-linux-gnu.tar.gz > Squeak32-3.8a-2.ia64-linux-gnu.tar.gz > Squeak32-3.8a-2.powerpc-apple-darwin7.8.0.tar.gz > contain 32-bit VMs precompiled for Pentium, Itanium 2 and PowerPC. > > Squeak64-3.8a-2.i686-pc-linux-gnu.tar.gz > Squeak64-3.8a-2.ia64-linux-gnu.tar.gz > Squeak64-3.8a-2.powerpc-apple-darwin7.8.0.tar.gz > contain 64-bit VMs precompiled for Pentium, Itanium 2 and PowerPC. > > Finally... > > ChangeSets > > is a directory containing everything that was used to create the > above, relative to the base 3.8g-6548 image: > > VMMaker-tpr.14.mcz > is Tim's latest VMMaker. > > VMM38b4-64bit-vm1-ikp.1.cs > are Dan and my 64-bit changes, plus various changes Tim made to VMM > since 3.7-5, all spiffed up and including a final couple of (nasty) > new bugs (one original bug, and a few that crept in which merging > VMM with the 64-bit changes) thoroughly fixed. This gets you > enough to generate interp.c plus the three essential plugins: > BitBlt, Ballon and File. > > VMM38b4-64bit-vm2-ikp.2.cs > is new 64-bit support for plugins using the SmartSyntax thing. > I made SocketPlugin (which uses it) 64-bit clean to make > sure it was working reasonably. > > With both of the above loaded you should be able to regenerate the > src32 and src64 trees included in the source tarball (and included in > the unix part of the repository). > > System-Tracing.2.cs > is the new SystemTracer from Anthony and Stephen, subclassed > by Dan to make 64-bit images. This ONLY works on big-endian > machines for now. (We know about this. Don't yell at us.) > > VMM38b4-64bit-image1-ikp.1.cs > VMM38b4-64bit-image2-ikp.1.cs > contain various changes to the class library that you probably > need to have a healthy image running with 64-bit oops. > > (Tim, especially, will want to take the vm1 and vm2 changesets and file > them into VMMaker _immediately_, before it becomes a 'moved target' > [again]. No need to read these files: they are the changes Dan and I > sent you, that you sent back last week with your recent VMM additions > filed-in over the top, in which I then fixed some subtle 'merge' bugs > that crept in during the process along with the WeakArray problem in > primStringReplace posted to squeak-dev a couple of days ago. Trust > me. Just hit 'install'. It's one huge chunk of goodness.) > > Enjoy! > > Ian (totally exhausted, and declaring the weekend already arrived ;-) > > |
|
|
In reply to this post by Ian Piumarta-3
Hi!
Ian Piumarta <[hidden email]> wrote: > Folks, > > I've just released 64-bit compatible sources for 3.8, and checked-in > both Unix and Cross changes to the TRUNK of the repository. I just want to say - Great Work! And have a nice weekend. :) regards, Göran |
|
|
In reply to this post by Ian Piumarta-3
Great job!
Do you know which, if any, plugins need special attention / weren't tested? Ned |
|
|
On Apr 1, 2005, at 07:05, Ned Konz wrote:
> Do you know which, if any, plugins need special attention / weren't > tested? Yes -- and I have some thoughts on this. I'll make a "plugin progress matrix" and post it Sunday or Monday. Cheers, Ian |
|
|
In reply to this post by Ian Piumarta-3
In message <[hidden email]>
Ian Piumarta <[hidden email]> wrote: > > ChangeSets > > is a directory containing everything that was used to create the > above, relative to the base 3.8g-6548 image: > In the svn download I received there is no 'ChangeSets' directory but the mentioned files are in platforms.unix.misc - so I'm going to work on the assumption that you merely mistyped while tired. Correct me if neccessary. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Strange OpCodes: EF: Emulate Fireworks |
|
|
In reply to this post by Andreas.Raab
Thoughts from merging to make a new mcz:-
SmartSyntaxPluginCodeGenerator>generateCPtrAsOop:on:indent: currently uses a '- sizeof(sqInt) to backspace from a ptr to make an oop. It would be nicer to find a way to make use of the 'proper' BaseHeaderSize value for both readability and safety (who knows what size the header might become?) at some point. Unsigned<ccgDecl.... uses 'unsigned int' rather than 'usqInt' - intentional or typo? I intend to finally remove TestInterpreterPlugin; we sunset it for 3.6 and it should have faded out a year ago. Various methods in 'plugin generation' protocols (WordArray, Float etc) have been moved into *VMMaker-plugin generation to suck them into the package. A changeset to remove them from the main image will be released. The VMM38b4-64bit-image1-ikp.1.cs will be re-released as I had to move a couple of things out from the -vm1- file that aren't legitimately part of the VMMaker package. If possible we should squeeze this into 3.8 gamma. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Strange OpCodes: LB: connect Line-voltage to BITNET |
|
|
OK, it finally built. At least _something_ succeeded today; I was making some
drawers this morning and everything possible went wrong. Clamps didn't, fixtures weren't, router bits took the wrong route... grr. I had to add #define HAVE_INTERP_H 1 to my non-generated-by-spawn-of-satan- autoconf config.h to prevent CodeMist bitching about the #warning lines in sqMemoryAccess.h But then it was needed anyway I expect. I had to change the declaration of sourcePtr in BitBltSimulation>primitiveDisplayString from 'unsigned char *' to 'char *' to prevent whining about implicit cast of pointer to non-equal pointer in a byteAt - byteAt expects a char *. 'unsigned char *' is, apparently so vilely not like a 'char *' that all hell breaks loose, sirens, flashing lights, threatening emails, the lot. The amusing part is that byteAt actually explicitly casts the input char * to an unsigned char *... Sigh. FloatArray didn't compile since primitiveDivFloatArray abuses longAt: and has a type clash. I really couldn't be bothered with it at this hour. It loads an image, runs it ok, garbage collects, moves windows etc. Must be ok. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim I must have slipped a disk; my pack hurts. |
|
|
On Apr 3, 2005, at 10:25 PM, Tim Rowledge wrote:
> It loads an image, runs it ok, garbage collects, moves windows etc. > Must be > ok. Cool. (Did you make a 64-bit VM and run the 64-bit image too?) The other thing we (desperately) need is a set of radio buttons in VMM to select: 1) generate 32-bit VM 2) generate 64-bit VM 3) generate both with (3) appending a '32' or '64' to the 'path to generated sources' string. (I'd put these radio buttons vertically, to the right of the two rows of way-too-wide buttons in the top frame, which seems to me to be the place of most disposable real estate.) Ian |
|
|
In message <[hidden email]>
Ian Piumarta <[hidden email]> wrote: > On Apr 3, 2005, at 10:25 PM, Tim Rowledge wrote: > > > It loads an image, runs it ok, garbage collects, moves windows etc. > > Must be > > ok. > > Cool. > > (Did you make a 64-bit VM and run the 64-bit image too?) Nope; no 64bit machine so I can't really do anything useful with it. If I was being paid I might feel like spending the money for such a machine, yadda yadda. Send money. > > The other thing we (desperately) need is a set of radio buttons in VMM > to select: > > 1) generate 32-bit VM > 2) generate 64-bit VM > 3) generate both > > with (3) appending a '32' or '64' to the 'path to generated sources' > string. pathnames in the makefiles. Not certain about what paths are in win32 & mac makefiles so such a change might require makelife editing. I imagine people are capable of that once they know what is changed... I'm not sure about a 'both' button though. With having to re-init OM for each form it wouldn't be doable to simply write out a 32b followed by a 64 b version of each file in turn. It would have to be; do one version of all requested work (remember you can ask for entire vm, just the core+internal, just the external plugins, an individual plugin) and then re-init OM and repeat. Of course, you can script it easily enough for batch processing; VMMaker has always been scriptable since it was originally written for exobox to do overnight automated builds. Stick somethng like:- ObjectMemory initBytesPerWord: 4. (VMMaker default sourceDirectoryName: 'somewhervalid/src32' ; initializeInternal: #(BitBltPlugin MiscPrimsPlugin FilePlugin) external: #(SocketPlugin ZipPlugin B2DPlugin) generateEntire. ObjectMemory initBytesPerWord: 8. (VMMaker default sourceDirectoryName: 'somewhervalid/src34' ; initializeInternal: #(BitBltPlugin MiscPrimsPlugin FilePlugin) external: #(SocketPlugin ZipPlugin B2DPlugin) generateEntire. in a buttonmorph script. Modulo the lineend issues you can even use the #setPlatName: method to do cross- 'compilation' which might be useful for batch building and compiling. Given the vile mess of file streams and naming that currently exists it would probably be simpler to make some shell script to do the lineend munging for dos & mac trees. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Useful random insult:- Been one too many times through the wormhole. |
|
|
On Apr 4, 2005, at 2:00 PM, Tim Rowledge wrote:
>> (Did you make a 64-bit VM and run the 64-bit image too?) > Nope; no 64bit machine so I can't really do anything useful with it. The whole point is that you can run a 64-bit VM on 32-bit hardware provided your compiler has a 64-bit integer type (long long or whatever). I made pre-compiled 64-bit VMs available for Pentium and (32-bit native) PowerPC, neither of which are 64-bit hardware. > Send money. Not necessary. Execute 'ObjectMemory initBytesPerWord: 8', regenerate, [ recompile, fix errors, run 64-bit VM ] repeatAsNecessary. > I'm not sure about a 'both' button though. With having to re-init OM > for each > form it wouldn't be doable to simply write out a 32b followed by a 64 > b version > of each file in turn. It would have to be; do one version of all > requested work > (remember you can ask for entire vm, just the core+internal, just the > external > plugins, an individual plugin) and then re-init OM and repeat. That's what we need. With appending '32' and '64' to the path so that each version of the VM goes into a different tree. But it's no real hassle to re-accept the path I guess, since it's mainly once per VM release that most people who care will be wanting to generate both at the same time... Ian |
|
|
In reply to this post by Ned Konz
On Apr 1, 2005, at 7:05 AM, Ned Konz wrote:
> Do you know which, if any, plugins need special attention / weren't > tested? Here is the current state (as far as I am aware) of plugins w.r.t. 64-bit conversion. Plugin Status Owner ------ ------ ----- ADPCMCodecPlugin ? ? AsynchFilePlugin ? [ikp] B2DPlugin 1/2 ar?+di? B3DAcceleratorPlugin ? ar? BMPReadWriterPlugin ? ? BitBltPlugin ok? [di] DSAPrims ? ? DropPlugin ? ? FFTPlugin ? ? FileCopyPlugin ? [ikp] FilePlugin ok ikp FloatArrayPlugin ? ? GeniePlugin ? ? JPEGReadWriter2Plugin ? ? JPEGReaderPlugin ? ? JoystickTabletPlugin ? ? Klatt ? ? LargeIntegers ? ? MIDIPlugin ? ? Matrix2x3Plugin ? ? MiscPrimitivePlugin ? [ikp] Mpeg3Plugin ? ? OSPP ? dl? RePlugin ? ? SecurityPlugin ? ? SerialPlugin ? ? SocketPlugin ok ikp SoundCodecPrims ? ? SoundGenerationPlugin ? ? SoundPlugin ? ? StarSqueakPlugin ? ? SurfacePlugin ? ? Squeak3D ? ar? SqueakFFIPrims ? ar?+ikp ZipPlugin ? ? The 'owner' column shows the initials of the person responsible for the conversion. Initials in [ ] brackets are people who will take charge of conversion if nobody else volunteers. Initials with a trailing ? query point are my best guess at who should take charge. di = Dan, ar = Andreas, dl = Dave Lewis, ikp = me. I have no idea of (or am too lazy to look up) the most likely responsible person for the others. (If anyone on this list would like to claim responsibility for any of the above plugins [and commit to converting it/them] then please let me know. After a suitable timeout I'll repeat the call on squeak-dev, and after another timeout I'll start giving out 'plugin tokens' to anyone willing to work on anything.) The 'status' column reflects the state of conversion. '?' means untested (but presumed to require some work), although plugins written exclusively in Slang should require minimal (or no) work (with the probable exception of OSPP). '1/2' means just enough to paint the screen is converted and working, but otherwise severely underconverted and requiring much careful attention from an expert. 'ok?' means compiles without error and appears to work, but could definitely benefit from a once-over from a well-trained and knowledgeable eye. 'ok' means converted and believed to be working fine. (The '?'s may require work in the plugin and/or in obscure corners of the CCodeGenerator and relatives to correct the usual gross 32-bit assumptions.) The two main 'gotchas' in Slang-based code (so far, at least) are: 1. Things declared to be 'int' that are supposed to contain oops and/or pointers into memory. Every single one of these will need fixing, carefully. 2. 'C' structures stored in ObectMemory as ByteArrays that contain pointers (or anything else that might be 64-bit aligned on 64-bit hardware). These have to be read/written specially to avoid unaligned accesses (e.g., FilePlugin in which the file [pointer] and fileSize [off_t or somesuch] members of SQFile are read/written by memory copy rather than by load/store). Ian |
|
|
In reply to this post by Ian Piumarta-4
In message <[hidden email]>
Ian Piumarta <[hidden email]> wrote: > Not necessary. Execute 'ObjectMemory initBytesPerWord: 8', regenerate, > [ recompile, fix errors, run 64-bit VM ] repeatAsNecessary. Ah, that. Well unfortunately that triggers the first actual CodeMist bug I've seen since around '89. No can do. I'll ping the supplier but I won't hold my breath. > That's what we need. With appending '32' and '64' to the path so that > each version of the VM goes into a different tree. But it's no real > hassle to re-accept the path I guess, since it's mainly once per VM > release that most people who care will be wanting to generate both at > the same time... I have a '64bit vm' button for now - I was disturbed by just how hard it was to find a morphic widget that did what I want and to find out how to use it - that works well enough for a first try. It maintains the rule that a user-typed path overrides any default, so if you leave the default path an press for 'machine word size'~ then it changes the path to blah-blah/src[64,32] but if you have set the path manually to 'blahblah/fredsCustomVMSrc' it stays that way. For batch making of many VMs the script is by far the more efficient approach. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim REALITY.SYS corrupted- reboot Universe (Y/N)? |
|
|
OK, at http://sumeru.stanford.edu/pooters/SqFiles/packages/VMMaker/VMM64bit-2.zip is
the MC file a filein to remove some obsolete protocols a revised filein to be filedin BEFORE the MC file is loaded For me it makes a working 32b vm and generates 64b code that my CC dislikes. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim You depend too much on computers for information. |
|
|
On Tuesday 05 April 2005 4:49 pm, Tim Rowledge wrote:
> OK, at > http://sumeru.stanford.edu/pooters/SqFiles/packages/VMMaker/VMM64bit-2.zip > is the MC file > a filein to remove some obsolete protocols > a revised filein to be filedin BEFORE the MC file is loaded > > For me it makes a working 32b vm and generates 64b code that my CC > dislikes. I'm getting a 404 on that... Not Found The requested URL /pooters/SqFiles/packages/VMMaker/VMM64bit-2.zip was not found on this server. -- Ned Konz http://bike-nomad.com |
|
|
In message <[hidden email]>
Ned Konz <[hidden email]> wrote: > On Tuesday 05 April 2005 4:49 pm, Tim Rowledge wrote: > > OK, at > > http://sumeru.stanford.edu/pooters/SqFiles/packages/VMMaker/VMM64bit-2.zip > > is the MC file > > a filein to remove some obsolete protocols > > a revised filein to be filedin BEFORE the MC file is loaded > > > > For me it makes a working 32b vm and generates 64b code that my CC > > dislikes. > > I'm getting a 404 on that... http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMM64bit-2.zip tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Original Sin is hard to find, but the digitally enhanced version is readily available. |
|
|
In reply to this post by Tim Rowledge-2
On Tuesday 05 April 2005 1:07 pm, Tim Rowledge wrote:
> I have a '64bit vm' button for now - I was disturbed by just how hard it > was to find a morphic widget that did what I want and to find out how to > use it - that works well enough for a first try. It maintains the rule that > a user-typed path overrides any default, so if you leave the default path > an press for 'machine word size'~ then it changes the path to > blah-blah/src[64,32] but if you have set the path manually to > 'blahblah/fredsCustomVMSrc' it stays that way. Attached are some changes that make a real checkBox and also simplify the GUI building. And a bit of minor code polishing as well (deprecated methods, you know...). -- Ned Konz http://bike-nomad.com |
VMMaker64Fixes-nk.3.cs.gz (11K) |
|
In message <[hidden email]>
Ned Konz <[hidden email]> wrote: > Attached are some changes that make a real checkBox and also simplify the GUI > building. > > And a bit of minor code polishing as well (deprecated methods, you know...). Thanks Ned. Couple of questions about the changes. Why the Object>touch: ? (and >primitive* for that matter) What on earth is AlignmentMorph inARow: ? Never seen that one before.. tim -- Tim Rowledge, [hidden email], http://sumeru.stanford.edu/tim Useful random insult:- There are great people in the world, but she's not one of them. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |