64-bit VMs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

64-bit VMs

Ian Piumarta-3
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 ;-)


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Andreas.Raab
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 ;-)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

goran.krampe
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

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ned Konz
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

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ian Piumarta-3
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ian Piumarta-4
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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.
Could work out of the box for you (on unix) and me (on RISC OS) with relative
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.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ian Piumarta-4
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ian Piumarta-3
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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)?

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ned Konz
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


Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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...
D'oh! Left out 'tim' in the middle.

 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.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Ned Konz
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) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit VMs

Tim Rowledge-2
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.

12