64-bit FAQ

 
Hello VM developers,

I've taken the detailed input on this subject that's been
posted to the list so far, and turned it into a FAQ for
posting either to squeakvm.org or the swiki.

Please check my facts (and grammar, and wording, ...)
one last time.

Thanks,
Andrew

Squeak 64-bit VM and image FAQ

1. What is a 32-bit image?

2. What is a 64-bit image?

3. Can I run a 32-bit image on my 64-bit computer?

4. Can I run a 64-bit image on my 32-bit computer?

5. Can a single VM run both 32-bit and 64-bit images?

6. What is a 64-bit VM?

7. Can I run a 32- or 64-bit VM on my computer?

8. For which hardware/OS combinations is there a 64-bit VM?

9. Does this VM run both 32-bit and 64-bit images?

10. I have a 64-bit computer;  should I use a 64-bit VM to run my 32-bit Squeak
images?

11. What are the advantages of using 64-bits?

12. What are the disadvantages of using 64-bits?
 
13. My OS allows a single process to grow to 3.75GB;  if I need a lot of objects
can I use a 32-bit image / VM, or must I use a 64-bit one?
 
14. Where can I find a 64-bit image?
 
15. Why isn't there an officially-released 64-bit image?
 
16. How can I make a 64-bit image from a 32-bit image?
 
17. How does a 32-bit VM manage to run a 64-bit image if pointers are only
32-bits wide?
 
18. What sizes and alignment does the new 64-bit image format use for pointers
and integers?

19. How do I tell if a given image file is 32-bit or 64-bit?


1/
What is a 32-bit image?
- A 32-bit image is an image in which the object memory uses a 32-bit word size
  for object pointers,  limiting its total size to a maximum amount of 4GB of
  memory.  The formats of object memory and object pointers are defined in class
  ObjectMemory (see the class comment for a basic explanation).  As of this
  writing,  all Squeak images of practical interest are 32-bit images.

2/
What is a 64-bit image?
- A 64-bit image is an image in which the object memory uses a 64-bit word size
  for object pointers,  allowing the size of the image to grow beyond 4GB of
  memory.  Squeak now supports a 64-bit image format that is sufficient to
  produce a working system, but which is intentionally simple.  It is expected
  to be modified and extended to take advantage of additional 64-bit
  capabilities in the future.

3/
Can I run a 32-bit image on my 64-bit computer?
- Yes.  A 32-bit image can be run on either a 32-bit VM or a 64-bit VM. Some
  computer platforms (e.g. 64-bit Linux) can run both the 32-bit VM and 64-bit
  VM on the same system.

4/
Can I run a 64-bit image on my 32-bit computer?
- Yes. If you build a VM with the "64-bit VM?" check box selected, you will
  create a VM that runs 64-bit images.  This will work on 32-bit host systems
  as well as on 64-bit host systems.

5/
Can a single VM run both 32-bit and 64-bit images?
- No.  For any given computer platform,  two different VMs are required to run
  32-bit and 64-bit images.  The type of VM that you build is governed by the
  "64-bit VM?" check box in VMMaker,  and is independent of the word size of
  your computer.  While it would be possible to create a VM that is
  "smart" enough to run both 32-bit and 64-bit images,  this is currently of
  little practical value due to Squeak's reliance on plugins that are linked to
  32-bit or 64 external library code.

  Any combination of 32/64 bit VM and 32/64-bit image is possible, but note
  that all currently available Squeak images are still in 32-bit format, and
  most (perhaps all) pre-built VMs are 32-bit applications.

6/
What is a 64-bit VM?
- A 64-bit VM is one which is compiled with the LP64 or ILP64 data model.  This
  means, in C terms, that pointers and longs are 64-bits wide.

7/
Can I run a 32- or 64-bit VM on my computer?
- It depends.  Some current architectures,  such as the x86-64 and the
  UltraSPARC,  can run 32-bit as well as 64-bit applications;  these are known
  as "bi-arch" systems.  However,  some systems,  such as the Alpha,  can only
  run 64-bit applications.  For bi-arch systems,  you can choose whether to run
  a 32-bit or 64-bit VM.  For 64-bit-only systems,  you don't have that choice;
  you can only run a 64-bit VM,  since there's no way of compiling a 32-bit
  application.

8/
For which hardware/OS combinations is there a 64-bit VM?
- Linux on 64-bit architectures: x86-64, SPARC64, Alpha, Power64, etc.
- Solaris on x86-64 and SPARC64
- MacOS on Power64
- Windows on x86-64

9/
Does my 64-bit VM run both 32-bit and 64-bit images?
- All VMs can run both 32-bit and 64-bit images, but this selection needs to be
  made at compile time.  See question 5.

10/
I have a 64-bit computer; should I use a 64-bit VM to run my 32-bit Squeak images?
- It depends.  Either one will work,  but if your image depends on plugins that
  are only available for 32-bit systems,  use the 32-bit VM.  Otherwise,  if
  you are building your own VM,  go ahead and use the 64-bit version.

11/
What are the advantages of using 64-bits?
- The first advantage is that your image size can be enormous.  If you need the
  size of your VM code plus in-memory image to exceed 4 GB, then a 64-bit image
  running on a 64-bit VM is for you.  Note that it will take ages to write out
  an image that's this big to disk.  The sort of applications that need this
  are those which load a small(ish) image, and run code that creates millions
  of objects, but don't save them back to disk in the image.  Keep in mind that
  the garbage collector is probably not up to the task of collecting multiple
  gigabytes.
- Another advantage is that certain architectures ( e.g. the Alpha) don't offer
  a 32-bit mode; they are 64-bit only.  For such machines, a 64-bit VM is
  required;  the image may be 32- or 64-bit.
- Another advantage is that when the 64-bit-VM is built, the C compiler knows
  the ABI is different from the 32-bit ABI.  The x86-64 case is an interesting
  example: the old i386 ABI offered few registers, used i387 floating-point,
  and passed parameters on the stack (remember, memory writes are slower than
  register moves).  The x86-64 ABI and architecture, on the other hand, has
  many more registers, has SSE, SSE2, etc.  for FP, and passes parameters in
  registers where possible.  It also has additional instructions (MMX et al).
  All of these CPU and ABI features may make for a VM that runs faster, but
  only if (a) the compiler is able to make use of them and (b) is told to do so
  at compile-time.  However, the gains are unlikely to be much, and will also
  be offset by the cost of large pointers (see below).  If you're looking for
  performance, it's important to measure a 32-bit VM with a 32-bit image versus
  a 64-bit VM with a 64-bit image before assuming anything.

12/
What are the disadvantages to using 64-bits?
- A disadvantage to 64-bit code is that pointers are 8 bytes instead of 4;
  they are also aligned on 8-byte boundaries, meaning that some space around
  them, known as `padding',  is wasted.  This means that (a) pointers take more
  space in RAM,  (b) take more memory bandwidth when the CPU loads and stores
  them,  (c) take up valuable space in on-chip caches,  and (d) will have
  greater wastage due to padding compared to 32-bit pointers aligned on 4-byte
  boundaries.  For most users,  the upper 32-bits of each pointer will always
  be zero,  so it makes little sense to load,  process and store pointers that
  are double the size but only half-used.  So for these users,  a 32-bit VM and
  image is a good choice.
- Another disadvantage is that most users use the 32-bit VM and a 32-bit image.
  This combination is therefore the most tested,  and therefore most stable,
  combination.
- A third disadvantage is that code for many of the plugins is not yet ported
  to a 64-bit VM.

13/
My OS allows a single process to grow to 3.75GB;  if I need a lot of objects
can I use a 32-bit image / VM, or must I use a 64-bit one?
- There have in the past been problems related to the so-called "2-GB limit".
  This is due to conversion to and from signed 32-bit integers to 32-bit
  pointers in the VM code.  These problems appeared when the operating system
  loaded the image into memory at addresses above the 2GB mark, and could occur
  with normal-sized images,  not only images larger than 2GB.  These issues
  should be a thing of the past.  Use the most recently-released VM for your
  platform, and report any problems that you see.  You should only *need* a
  64-bit VM and 64-bit image if your image size will exceed 4GB.

14/
Where can I find a 64-bit image?
- These are scarce. The original 64-bit port project (from Ian and Dan)
  includes a 64-bit image that worked with the VM distributed at that time. A
  current VM cannot execute the original 64-bit image due to changes in the
  interpreter since that time.  It is possible to update that original image
  using a modified VM, and the resulting image is executable using a current
  unmodified VM.  However, there are no official or supported releases of 64-bit
  images at this time.

15/
Why isn't there an officially-released 64-bit image?
- Lack of interest:  most people don't need a 64-bit image.
- There may yet be some changes to the 64-bit image format to take advantage of
  features of 64-bit CPUs.  For instance,  63-bit tagged integers might be
  possible.

16/
How can I make a 64-bit image from a 32-bit image?
- Use the SystemTracer (SystemTracerV2 on SqueakMap).  The original 64-bit
  Squeak image was created using this tool,  and a sufficiently motivated
  person should be able to reproduce the job.  However,  the SystemTracer does
  not currently work on little-endian computers (including Intel),  so some
  work should be expected in order to enhance SystemTracer before a successful
  conversion will be possible.

17/
How does a 32-bit VM manage to run a 64-bit image if pointers are 32-bits?
- The short answer:  It relies on the image size being smaller than 4GB.
- The long answer:  Object pointers within the object memory are not pointers in
  the C sense of the word.  The VM needs to be able to convert the object
  pointers into C pointers,  and this can be done on either a 32-bit host or a
  64 bit host.  The only caveat would be that if a 64-bit image grew to a size
  large enough to use object pointers larger than the 32-bit limit (i.e. an
  image approaching 4GB in size),  then a 64-bit VM would be required.

18/
What sizes and alignment does the new 64-bit image format use for
pointers and integers?
- Object pointers are 64-bits wide,  allowing for memory up to 2^64 bytes to be
  directly addressable.  They are aligned on 8-byte boundaries.  Integers are
  still implemented as tagged 31-bit values.  They are aligned to 4-byte
  boundaries.  These alignments were chosen as most 64-bit CPUs require them.

- The object header and pointer formats for both 32-bit and 64-bit images are
  documented in the class comment of ObjectMemory (in the VMMaker package).
  The conversions to and from host data types are done in
  platforms/Cross/vm/sqMemoryAccess.h using either macros or inline functions.
  The actual conversions vary from host to host,  and are controlled by macros
  such as SQ_HOST64 and SQ_IMAGE32 which must be set for that host.  In the
  case of a Unix VM,  the configure utility is used to specify the
  characteristics of the host platform.

- The word size to be used in the object memory is specified by the
  SQ_VI_BYTES_PER_WORD macro on src/vm/interp.h.  This file is created in the
  VMMaker code generation process,  and the value of SQ_VI_BYTES_PER_WORD is
  determined by the "64-bit VM?" check box in the VMMaker tool.

- In summary,  the object word format is described in class ObjectMemory,  the
  host data type conversions are specified in sqMemoryAccess.h,  and the image
  word size is specified in interp.h.


19/
How do I tell if a given image file is 32-bit or 64-bit?
- The first four bytes in the image file are a "magic" value that indicates the
  image word size.  This is specified in Interpreter>>imageFormatVersion.  For
  most images,  this will be the first four bytes of the image file,  although
  in some cases the image data may be offset by 512 bytes in order to permit an
  image file to be treated as an executable program on Unix platforms (see
  http://en.wikipedia.org/wiki/Shebang_(Unix)).

  For instance, if I load VMMaker-3.8b6 into a stock Squeak3.9a-7024.image
  file,  I see this:

        imageFormatVersion
                "Return a magic constant that changes when the image format
                changes. Since the image reading code uses this to detect byte
                ordering, one must avoid version numbers that are invariant
                under byte reversal."

                BytesPerWord == 4
                        ifTrue: [^6502]
                        ifFalse: [^68000]

  Examining the file itself gives this:

        apg@breakfast: ~/squeak xxd Squeak3.9a-7024.image | head -1
        0000000: 0000 1966 0000 0040 011c 7ee0 0427 b000  ...f...@..~..'..

  Looking at the first four bytes gives this:

          apg@breakfast: ~/squeak perl -e 'print 0x1966'
          6502

  (or do "16r1966 <Alt-P>" in a workspace; it also returns 6502.)

  So Squeak3.9a-7024.image is a 32-bit image file (since BytesPerWord == 4).

 
On Wed, Oct 17, 2007 at 10:35:19PM +0200, Andrew Gaylard wrote:
>
> I've taken the detailed input on this subject that's been
> posted to the list so far, and turned it into a FAQ for
> posting either to squeakvm.org or the swiki.

Looks good!

I've provided a couple of edits below.

> 9/
> Does my 64-bit VM run both 32-bit and 64-bit images?
> - All VMs can run both 32-bit and 64-bit images, but this selection needs to
> be made at compile time.  See question 5.

Better answer:

Does my 64-bit VM run both 32-bit and 64-bit images?
- No. Any VM will run either 32-bit or 64-bit images, but not both. You
can select one or the other when you generate sources with VMMaker,
and you can install both flavors of VM on your system (one each for
32-bit images and 64-bit images).

If try to run a 64-bit image with a VM built for 32-bit images, you will
get an error message such as this:

  This interpreter (vers. 6502) cannot read image file (vers. 68000).

If you try to run a 32-bit image using a VM built for 64-bit images,
you will get an error message such as this:

  This interpreter (vers. 68000) cannot read image file (vers. 6502).

Delete the line "They are aligned to 4-byte boundaries." This is incorrect.
(Explanation: In the current 64-bit object memory, integers are encoded as
if they were 32-bit words, but are sign-extended to use the full 64-bit
object word size and therefore are aligned on 8-byte boundaries. Future
enhancements to 64-bit Squeak will probably make use of the larger word
size to increase the range of SmallInteger values, which will require
changes to both the VM and the image in order to be effective.)

Dave

 
In the 3.10 date and time code It seems I wrongly assumed that the
millisecond clock would wrap-around at SmallInteger maxVal.

Is there a way to know this exactly for every platform?

Keith

 

On 19-Oct-07, at 1:17 PM, Keith Hodges wrote:

>
> In the 3.10 date and time code It seems I wrongly assumed that the
> millisecond clock would wrap-around at SmallInteger maxVal.
>
> Is there a way to know this exactly for every platform?
In the current VM code the timer is wrapped at SmallInteger maxVal //
2 because it was a simple hack fix to setting long delays - ie if the  
max tick value was 1B and the max delay interval 1B then it wouldn't  
overflow. I proposed a much better fix ages ago that I think was  
incorporated.
It's not a platform issue so far as I know.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Manual Writer's Creed:  Garbage in, gospel out.

 
That is the short answer.

primitiveMillisecondClock
        "Return the value of the millisecond clock as an integer. Note that  
the millisecond clock wraps around periodically. On some platforms it  
can wrap daily. The range is limited to SmallInteger maxVal / 2 to  
allow delays of up to that length without overflowing a SmallInteger."

        self pop: 1 thenPush: (self integerObjectOf: (self ioMSecs bitAnd:  
MillisecondClockMask)).


        MillisecondClockMask := 16r1FFFFFFF.


Note the comment about how

ioMSecs

might return values that wrap daily....

 From the historical perspective Dan discovered a number of issues  
with wrapping when OS-9 ish came out and macintosh computers were  
able to run
his weather station software for 24 days straight without crashing  
which was the magic point when the pre os-x operating system  
millisecond clock timer rolled over.
Of course that might still apply today, how many days is a billion  
milliseconds?  12.427 so days?  so rollover is in 6 & 1/4 days?



On Oct 19, 2007, at 1:45 PM, tim Rowledge wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

 
Is this issue currently solveable from the image?  i.e., is it
possible to simulate a millisecond clock that never wraps?

On 10/19/07, John M McIntosh <[hidden email]> wrote:

 
Chris Muller wrote:
> Is this issue currently solveable from the image?  i.e., is it
> possible to simulate a millisecond clock that never wraps?

Time class>>neverWrappingMSecsClock
        ^(self totalSeconds * 1000) + (self millisecondsClock \\ 1000)

Cheers,
   - Andreas

 

On 19-Oct-07, at 8:16 PM, Andreas Raab wrote:

> Chris Muller wrote:
>> Is this issue currently solveable from the image?  i.e., is it
>> possible to simulate a millisecond clock that never wraps?
>
> Time class>>neverWrappingMSecsClock
> ^(self totalSeconds * 1000) + (self millisecondsClock \\ 1000)

I *think* we demonstrated some time ago that the two values are not  
necessarily aligned on the same 0, which caused some problems in some  
date/time code IIRC.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
AAAAAA - American Association Against Acronym Abuse Anonymous

 
Chris Muller wrote:
>  
> Is this issue currently solveable from the image?  i.e., is it
> possible to simulate a millisecond clock that never wraps?
>
>  
The code in 3.10 attempts to do this however it fails due to my mistaken
assumption. I can be fixed quite easily I think


Keith

 
After waiting more than a week, and seeing no further
feedback, here's the 64-bit FAQ as it currently stands.
I'd be grateful if someone (Ian?) could park it safely on
squeakvm.org .

Thanks,
Andrew.

1. What is a 32-bit image?

2. What is a 64-bit image?

3. Can I run a 32-bit image on my 64-bit computer?

4. Can I run a 64-bit image on my 32-bit computer?

5. Can a single VM run both 32-bit and 64-bit images?

6. What is a 64-bit VM?

7. Can I run a 32- or 64-bit VM on my computer?

8. For which hardware/OS combinations is there a 64-bit VM?

9. Does this VM run both 32-bit and 64-bit images?

10. I have a 64-bit computer;  should I use a 64-bit VM to run my 32-bit Squeak
images?

11. What are the advantages of using 64-bits?

12. What are the disadvantages of using 64-bits?
 
13. My OS allows a single process to grow to 3.75GB;  if I need a lot of objects
can I use a 32-bit image / VM, or must I use a 64-bit one?
 
14. Where can I find a 64-bit image?
 
15. Why isn't there an officially-released 64-bit image?
 
16. How can I make a 64-bit image from a 32-bit image?
 
17. How does a 32-bit VM manage to run a 64-bit image if pointers are only
32-bits wide?
 
18. What sizes and alignment does the new 64-bit image format use for pointers
and integers?

19. How do I tell if a given image file is 32-bit or 64-bit?


1/
What is a 32-bit image?
- A 32-bit image is an image in which the object memory uses a 32-bit word size
  for object pointers,  limiting its total size to a maximum amount of 4GB of
  memory.  The formats of object memory and object pointers are defined in class
  ObjectMemory (see the class comment for a basic explanation).  As of this
  writing,  all Squeak images of practical interest are 32-bit images.

2/
What is a 64-bit image?
- A 64-bit image is an image in which the object memory uses a 64-bit word size
  for object pointers,  allowing the size of the image to grow beyond 4GB of
  memory.  Squeak now supports a 64-bit image format that is sufficient to
  produce a working system, but which is intentionally simple.  It is expected
  to be modified and extended to take advantage of additional 64-bit
  capabilities in the future.

3/
Can I run a 32-bit image on my 64-bit computer?
- Yes.  A 32-bit image can be run on either a 32-bit VM or a 64-bit VM. Some
  computer platforms (e.g. 64-bit Linux) can run both the 32-bit VM and 64-bit
  VM on the same system.

4/
Can I run a 64-bit image on my 32-bit computer?
- Yes. If you build a VM with the "64-bit VM?" check box selected, you will
  create a VM that runs 64-bit images.  This will work on 32-bit host systems
  as well as on 64-bit host systems.

5/
Can a single VM run both 32-bit and 64-bit images?
- No.  For any given computer platform,  two different VMs are required to run
  32-bit and 64-bit images.  The type of VM that you build is governed by the
  "64-bit VM?" check box in VMMaker,  and is independent of the word size of
  your computer.  While it would be possible to create a VM that is
  "smart" enough to run both 32-bit and 64-bit images,  this is currently of
  little practical value due to Squeak's reliance on plugins that are linked to
  32-bit or 64 external library code.

  Any combination of 32/64 bit VM and 32/64-bit image is possible, but note
  that all currently available Squeak images are still in 32-bit format, and
  most (perhaps all) pre-built VMs are 32-bit applications.

6/
What is a 64-bit VM?
- A 64-bit VM is one which is compiled with the LP64 or ILP64 data model.  This
  means, in C terms, that pointers and longs are 64-bits wide.

7/
Can I run a 32- or 64-bit VM on my computer?
- It depends.  Some current architectures,  such as the x86-64 and the
  UltraSPARC,  can run 32-bit as well as 64-bit applications;  these are known
  as "bi-arch" systems.  However,  some systems,  such as the Alpha,  can only
  run 64-bit applications.  For bi-arch systems,  you can choose whether to run
  a 32-bit or 64-bit VM.  For 64-bit-only systems,  you don't have that choice;
  you can only run a 64-bit VM,  since there's no way of compiling a 32-bit
  application.

8/
For which hardware/OS combinations is there a 64-bit VM?
- Linux on 64-bit architectures: x86-64, SPARC64, Alpha, Power64, etc.
- Solaris on x86-64 and SPARC64
- MacOS on Power64
- Windows on x86-64

9/
Does my 64-bit VM run both 32-bit and 64-bit images?
- No. Any VM will run either 32-bit or 64-bit images, but not both. You can
  select one or the other when you generate sources with VMMaker, and you can
  install both flavors of VM on your system (one each for 32-bit images and
  64-bit images).

  If try to run a 64-bit image with a VM built for 32-bit images, you will get
  an error message such as this:

    This interpreter (vers. 6502) cannot read image file (vers. 68000).

  If you try to run a 32-bit image using a VM built for 64-bit images, you will
  get an error message such as this:

    This interpreter (vers. 68000) cannot read image file (vers. 6502).


10/
I have a 64-bit computer; should I use a 64-bit VM to run my 32-bit Squeak images?
- It depends.  Either one will work,  but if your image depends on plugins that
  are only available for 32-bit systems,  use the 32-bit VM.  Otherwise,  if
  you are building your own VM,  go ahead and use the 64-bit version.

11/
What are the advantages of using 64-bits?
- The first advantage is that your image size can be enormous.  If you need the
  size of your VM code plus in-memory image to exceed 4 GB, then a 64-bit image
  running on a 64-bit VM is for you.  Note that it will take ages to write out
  an image that's this big to disk.  The sort of applications that need this
  are those which load a small(ish) image, and run code that creates millions
  of objects, but don't save them back to disk in the image.  Keep in mind that
  the garbage collector is probably not up to the task of collecting multiple
  gigabytes.
- Another advantage is that certain architectures ( e.g. the Alpha) don't offer
  a 32-bit mode; they are 64-bit only.  For such machines, a 64-bit VM is
  required;  the image may be 32- or 64-bit.
- Another advantage is that when the 64-bit-VM is built, the C compiler knows
  the ABI is different from the 32-bit ABI.  The x86-64 case is an interesting
  example: the old i386 ABI offered few registers, used i387 floating-point,
  and passed parameters on the stack (remember, memory writes are slower than
  register moves).  The x86-64 ABI and architecture, on the other hand, has
  many more registers, has SSE, SSE2, etc.  for FP, and passes parameters in
  registers where possible.  It also has additional instructions (MMX et al).
  All of these CPU and ABI features may make for a VM that runs faster, but
  only if (a) the compiler is able to make use of them and (b) is told to do so
  at compile-time.  However, the gains are unlikely to be much, and will also
  be offset by the cost of large pointers (see below).  If you're looking for
  performance, it's important to measure a 32-bit VM with a 32-bit image versus
  a 64-bit VM with a 64-bit image before assuming anything.

12/
What are the disadvantages to using 64-bits?
- A disadvantage to 64-bit code is that pointers are 8 bytes instead of 4;
  they are also aligned on 8-byte boundaries, meaning that some space around
  them, known as `padding',  is wasted.  This means that (a) pointers take more
  space in RAM,  (b) take more memory bandwidth when the CPU loads and stores
  them,  (c) take up valuable space in on-chip caches,  and (d) will have
  greater wastage due to padding compared to 32-bit pointers aligned on 4-byte
  boundaries.  For most users,  the upper 32-bits of each pointer will always
  be zero,  so it makes little sense to load,  process and store pointers that
  are double the size but only half-used.  So for these users,  a 32-bit VM and
  image is a good choice.
- Another disadvantage is that most users use the 32-bit VM and a 32-bit image.
  This combination is therefore the most tested,  and therefore most stable,
  combination.
- A third disadvantage is that code for many of the plugins is not yet ported
  to a 64-bit VM.

13/
My OS allows a single process to grow to 3.75GB;  if I need a lot of objects
can I use a 32-bit image / VM, or must I use a 64-bit one?
- There have in the past been problems related to the so-called "2-GB limit".
  This is due to conversion to and from signed 32-bit integers to 32-bit
  pointers in the VM code.  These problems appeared when the operating system
  loaded the image into memory at addresses above the 2GB mark, and could occur
  with normal-sized images,  not only images larger than 2GB.  These issues
  should be a thing of the past.  Use the most recently-released VM for your
  platform, and report any problems that you see.  You should only *need* a
  64-bit VM and 64-bit image if your image size will exceed 4GB.

14/
Where can I find a 64-bit image?
- These are scarce. The original 64-bit port project (from Ian and Dan)
  includes a 64-bit image that worked with the VM distributed at that time. A
  current VM cannot execute the original 64-bit image due to changes in the
  interpreter since that time.  It is possible to update that original image
  using a modified VM, and the resulting image is executable using a current
  unmodified VM.  However, there are no official or supported releases of 64-bit
  images at this time.

15/
Why isn't there an officially-released 64-bit image?
- Lack of interest:  most people don't need a 64-bit image.
- There may yet be some changes to the 64-bit image format to take advantage of
  features of 64-bit CPUs.  For instance,  63-bit tagged integers might be
  possible.

16/
How can I make a 64-bit image from a 32-bit image?
- Use the SystemTracer (SystemTracerV2 on SqueakMap).  The original 64-bit
  Squeak image was created using this tool,  and a sufficiently motivated
  person should be able to reproduce the job.  However,  the SystemTracer does
  not currently work on little-endian computers (including Intel),  so some
  work should be expected in order to enhance SystemTracer before a successful
  conversion will be possible.

17/
How does a 32-bit VM manage to run a 64-bit image if pointers are 32-bits?
- The short answer:  It relies on the image size being smaller than 4GB.
- The long answer:  Object pointers within the object memory are not pointers in
  the C sense of the word.  The VM needs to be able to convert the object
  pointers into C pointers,  and this can be done on either a 32-bit host or a
  64 bit host.  The only caveat would be that if a 64-bit image grew to a size
  large enough to use object pointers larger than the 32-bit limit (i.e. an
  image approaching 4GB in size),  then a 64-bit VM would be required.

18/
What sizes and alignment does the new 64-bit image format use for
pointers and integers?
- Object pointers are 64-bits wide,  allowing for memory up to 2^64 bytes to be
  directly addressable.  They are aligned on 8-byte boundaries.  Integers are
  still implemented as tagged 31-bit values, but are sign-extended to use the
  full 64-bit object word size and therefore are aligned on 8-byte boundaries.
  Future enhancements to 64-bit Squeak will probably make use of the larger
  word size to increase the range of SmallInteger values, which will require
  further changes to both the VM and the image in order to be effective.  These
  alignments were chosen as most 64-bit CPUs require them.

- The object header and pointer formats for both 32-bit and 64-bit images are
  documented in the class comment of ObjectMemory (in the VMMaker package).
  The conversions to and from host data types are done in
  platforms/Cross/vm/sqMemoryAccess.h using either macros or inline functions.
  The actual conversions vary from host to host,  and are controlled by macros
  such as SQ_HOST64 and SQ_IMAGE32 which must be set for that host.  In the
  case of a Unix VM,  the configure utility is used to specify the
  characteristics of the host platform.

- The word size to be used in the object memory is specified by the
  SQ_VI_BYTES_PER_WORD macro on src/vm/interp.h.  This file is created in the
  VMMaker code generation process,  and the value of SQ_VI_BYTES_PER_WORD is
  determined by the "64-bit VM?" check box in the VMMaker tool.

- In summary,  the object word format is described in class ObjectMemory,  the
  host data type conversions are specified in sqMemoryAccess.h ,  and the image
  word size is specified in interp.h.

19/
How do I tell if a given image file is 32-bit or 64-bit?
- The first four bytes in the image file are a "magic" value that indicates the
  image word size.  This is specified in Interpreter>>imageFormatVersion.  For
  most images,  this will be the first four bytes of the image file,  although
  in some cases the image data may be offset by 512 bytes in order to permit an
  image file to be treated as an executable program on Unix platforms (see
  http://en.wikipedia.org/wiki/Shebang_(Unix)).

  For instance, if I load VMMaker-3.8b6 into a stock Squeak3.9a-7024.image
  file,  I see this:

        imageFormatVersion
                "Return a magic constant that changes when the image format
                changes. Since the image reading code uses this to detect byte
                ordering, one must avoid version numbers that are invariant
                under byte reversal."

                BytesPerWord == 4
                        ifTrue: [^6502]
                        ifFalse: [^68000]

  Examining the file itself gives this:

        apg@breakfast: ~/squeak xxd Squeak3.9a-7024.image | head -1
        0000000: 0000 1966 0000 0040 011c 7ee0 0427 b000  ...f...@..~..'..

  Looking at the first four bytes gives this:

          apg@breakfast: ~/squeak perl -e 'print 0x1966'
          6502

  (or do "16r1966 <Alt-P>" in a workspace; it also returns 6502.)

  So Squeak3.9a-7024.image is a 32-bit image file (since BytesPerWord == 4).