(cc squeak-dev per Bert's suggestion)

Hi Dan,

Indeed it is "#define SQ_VI_BYTES_PER_WORD 8". This macro
is the one used in sqMemoryAccess.h, so BYTES_PER_WORD and
BASE_HEADER_SIZE are set from SQ_VI_BYTES_PER_WORD. It turned
out that it is possible to rearrange some class and instance
variables in ObjectMemory and Intepreter such that the generated
C code is the same for 32 and 64 bit object memory, controlled
at compile time by the SQ_VI_BYTES_PER_WORD macro. I'm afraid
it makes the Smalltalk source less readable, but it's nice
not to need to generate different sets of C sources for src32
and src64.

I should mention that recent versions of VMMaker can no longer
be loaded into a Squeak 3.8 image, primarily due to the use of
pragmas, e.g. "<inline: true>" rather than "self inline: true",
which in turn means that at the moment one cannot genererate a
current VM from the Squeak 3.8 based 64-bit image. I will have
a bit of time to play with this on Tuesday, so I'll see if I can
find a way to either load current VMMaker into the 3.8 image,
or to trace an up-to-date Squeak 4.1 image to 64 bits. I'll let
you know before Wednesday if I have made any progress.

Dave

On Fri, Oct 29, 2010 at 10:40:39PM -0700, Dan Ingalls wrote:
> Hi David -
> 
> Thanks for the pointers.  I'm assuming you meant BYTES_PER_WORD 8, right?
> Do let me know if you gather more infor in the next few days.  I think I'm not going to have a chance at this until after next Wed.
> 
> All the best
> 	- Dan
> ---------------------------------------
> >On Fri, Oct 29, 2010 at 09:48:11AM +0200, Bert Freudenberg wrote:
> >> On 29.10.2010, at 06:25, Dan Ingalls wrote:
> >>
> >> > Hi Guys ;-)
> >> >
> >> > Anyone have experience with running super huge Squeaks?  I have the chance to use an absurdly big machine.  I'd appreciate advice (offline unless you think it would be generally useful) regarding the relative stability of, say, linux and windoze builds of 64-bit Squeaks known (or thought) to run with over a terabyte of objects, and also where there may be some pre-built 64-bit images (sorry if this is in an obvious place).  Finally (since I've mainly used a Mac for Squeak) I guess I'll have to know how to tell it how big to be, or would it grow gracefully if I just said "(String new: 1000000000000) size" in a normal image?
> >> >
> >> > Thanks
> >> >
> >> >	- Dan
> >>
> >> Dave Lewis has been working on 64 bit stuff, he surely will respond (and please keep responses on list, this is rather interesting). A recent image is here:
> >>
> >>	http://squeakvm.org/squeak64/sq64-dtl.zip
> >>
> >> I think there isn't even much experience with a Gigabyte-sized image ...
> >
> >Hi Dan,
> >
> >The image that Bert mentions is an updated version of your original
> >64-bit image, suitable for running on a current Squeak VM. I have
> >not tried tracing the latest Squeak trunk image (sounds like a good
> >project for this weekend though :)
> >
> >The quickest way to get a VM running is to start with an up to
> >date Squeak image, load latest VMMaker from www.squeaksource.com/VMMaker
> >and platform sources from Subversion. The "64-bit VM" button is
> >gone from the VMMaker tool, all that is needed to build the 64 bit
> >version is to set a macro either in ./build/config.h or in
> >./src/vm/interp.h:
> >
> >  #define SQ_VI_BYTES_PER_WORD 4
> >
> >I use Linux for running this stuff, so I can't speak to Windows or
> >OS X. On a unix platform, if you evaluate "(String new: 1000000000000) size"
> >in sq64-dtl.image, you will get a low space notifier. I remember adding
> >some checks to the VM to prevent address overflows for allocations
> >that are "unreasonably large), and I think this notifier reflects
> >hitting that limit (sorry I can't recall the details, I'll check later).
> >It would be fun to see how big "unreasonably large" could be though :)
> >
> >A gigabyte is no problem though. The following succeeds on a
> >64-bit image:
> >
> >  (String new: 1000000000) size ==> 1000000000
> >
> >For allocation requests that are within the current VM limits,
> >what you can expect to see on a unix box is that your VM will
> >cheerfully keep allocating memory from the OS until your system
> >starts swapping pages to disk, at which point everything on the
> >system slows to a crawl. It will be interesting to see what happens
> >on a really big box with lots of memory.
> >
> >Dave