Andrew Gaylard wrote:

What would be neat would be a page, either at squeakvm.org http://squeakvm.org or on the wiki, which would answer some of the common 64-bit questions that come up from time to time. For instance, here are some of mine:

• For which hardware/OS combinations is there a 64-bit VM?
• Does this VM run both 32-bit and 64-bit images?
• How do I convert a 32-bit image to a 64-bit one?
• 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?
• What are the advantages/disadvantages to using 64-bits?
• Why isn't there an officially-released 64-bit image?

I suspect that if this basic information was available, there'd be rather more interest, which would lead to more testing, more bug reports, more fixes, etc.

This is great information. Feel like writing it up? I'm sure Ian can be convinced to put it into the right place.

Cheers, - Andreas

On Oct 16, 2007, at 10:36 , Andrew Gaylard wrote:

5. What are the advantages/disadvantages to using 64-bits?

• The first advantage is that your image size can be enormous.

If you need the size of your VM code + in-memory image to exceed 4 GB, then 64-bits 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.

However, the garbage collector really is not up to the task of collecting multiple gigabytes of garbage.

• 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 important example: the old i386 ABI offered few registers, used i387 floating-point, and passed parameters on the stack. The x86-64 ABI has may 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 this makes for a VM that runs faster if the compiler is able to make use of it (and is told to at compile-time).

I doubt that, you need to profile. I have not heard anyone reporting the 64 bit VM to be faster than the 32 bit version, on any machine.

• A disadvantage to 64-bit code is that pointers are 8 bytes

instead of 4; this means that (a) pointers take more space in RAM, (b) take more memory bandwidth when the CPU loads and stores them, and (c) take up valuable space in on-chip-caches. For many users, the upper 32 bits will always be zero, so it makes little sense to load, process and store pointers that are double the size but only half- used. For these users, 32-bits is a good choice.

• Another disadvantage is that most users use the 32-bit VM and a

32-bit image. This combination is therefore widely tested, and therefore more stable as a consequence.

6. Why isn't there an officially-released 64-bit image?

Watch this space!

Because nobody needs it (yet), and therefore nobody feels an urge to provide and maintain one.

Anyway, writing this up for future reference is needed, thanks for doing this. One thing you should watch out for though is to distinguish between a 64 bit VM and a 64 bit image, which are independent.

- Bert -

On Tue, Oct 16, 2007 at 01:04:45PM +0200, Andrew Gaylard wrote:

On 10/16/07, Bert Freudenberg bert@freudenbergs.de wrote:

...

Anyway, writing this up for future reference is needed, thanks for doing this. One thing you should watch out for though is to distinguish between a 64 bit VM and a 64 bit image, which are independent.

Ah. Yes. Good that you pointed this out. So would it be correct to say "a 64-bit VM is needed only if you have an architecture which can't run 32-bit apps, or if you have a need for an enormous number of objects, in which case you'll also need a 64-bit image"?

To clarify some terminology:

When Ian and Dan did the 64 bit port, they used the term "64 bit image" to refer to an image in which all of the object pointers had been converted from 32 bit values to 64 bit values, and the term "64 bit host" to refer to a platform with 64 bit machine pointer size. Any combination of 32/64 bit host and 32/64 bit image is possible, but note that all currently available Squeak images are still in 32 bit format.

So for the FAQ:

- 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. The format of object memory and object pointers is 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.

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

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

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

- 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. (Note: 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.)

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

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

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

Dave

On Tue, Oct 16, 2007 at 06:04:29PM -0700, Andreas Raab wrote:

David T. Lewis wrote:

...

So for the FAQ:

• 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. The format of object memory and object pointers is 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.

This is very good already. How about also pointing out the difference in max. image size, e.g.:

"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."

...

• What is a 64 bit VM?

A 64 bit image is an image in which the object memory uses 64 bit word size for object pointers. Squeak now supports a 64 bit image format that is sufficient to produce a working system, but which is intentionally simple, and is expected to be modified and extended to take advantage of additional 64 bit capabilities in the future.

And here:

"A 64 bit image is an image in which the object memory uses 64 bit word size for object pointers, allowing the size of the image to grow beyond 4GB of memory. Etc."

Yes, that's better.

Andrew, thanks for for putting this together and for motivating the discussion. If you wordsmith this a bit it would be good to put the result on the swiki (wiki.squeak.org/squeak).

Dave

On Wed, Oct 17, 2007 at 09:26:35AM +0200, Andrew Gaylard wrote:

On 10/17/07, David T. Lewis lewis@mail.msen.com wrote:[snip]

...

• What is a 64 bit VM?

A 64 bit image is an image in which the object memory uses 64 bit word size for object pointers. Squeak now supports a 64 bit image format that is sufficient to produce a working system, but which is intentionally simple, and is expected to be modified and extended to take advantage of additional 64 bit capabilities in the future.

Considering the answer you gave, did you mean this question to be "What is a 64-bit image?"?

Yes, that's what I meant, sorry.

Here's a pass at answering the "what is a 64-bit VM?" question: 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.

Good.

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

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". However, some (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 can only run a 64-bit VM, since there's no way of compiling a 32-bit application.

Good.

• How does a 32-bit VM manage to run a 64-bit image if pointers are 32-bits?

(I'm guessing here!) It relies on the image size being smaller than 4GB. Code in the VM converts the 64-bit object pointers to 32-bit ones that the VM can use.

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.

• What sizes and alignment does the new 64-bit image format use for

pointers and integers? (Again, I'm guessing here) In the 64-bit image format, 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 that must be 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.

• how do I tell if a given image file is 32-bit or 64-bit?

The first four bytes of the image 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)).

Dave

On Oct 17, 2007, at 12:26 AM, Andrew Gaylard wrote:

Here's a pass at answering the "what is a 64-bit VM?" question: A 64-bit VM is one which is compiled with the LP64 or ILP64 data model.

I doubt that ILP64 could be made to work. 8-, 16-, 32- and 64-bit 'int's are all important in some place or another. I think all popular 64-bit architectures come with C compilers that implement LP64 by default, Cray/UNICOS weirdness notwithstanding (but there the C compiler is one of the lesser of your worries ;-).

This is great stuff! Does someone (or some wiki page) have a final version of the '64-FAQ' with all the deltas applied that I can copy to squeakvm.org?

Thanks! Ian

Andrew's latest update is here, ready to be moved to squeakvm.org:

http://squeakvm.org/squeak64/faq.html

Linked (twice) from the squeak64 front page. I hope I didn't break anything while adding the internal links.

Cheers, and THANKS!

Ian

On Nov 3, 2007, at 4:22 , Ian Piumarta wrote:

...

Andrew's latest update is here, ready to be moved to squeakvm.org:

http://squeakvm.org/squeak64/faq.html

Linked (twice) from the squeak64 front page. I hope I didn't break anything while adding the internal links.

Cheers, and THANKS!

This is excellent info, thanks to Andrew and all contributors.

One thing that is odd not about the FAQ but about our beloved VMMaker tool is that the "64-bit VM?" check box in VMMaker actually governs building support for a 64-bit image, to use the FAQ's terms:

"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"

"What is a 64-bit VM? A 64-bit VM is one which is compiled with the LP64 or ILP64 data model"

So IMHO we should change that check box label to something indicating "64-bit image support" to reduce a major confusion point. Putting a link to the FAQ (or even a copy of the FAQ) into the tool itself might be an extra bonus.

- Bert -

On Mon, Nov 05, 2007 at 09:02:01AM +0200, Andrew Gaylard wrote:

While still on the topic of 64 bits, ...

• Is there a list of which plugins still need to be fixed to work in a

64-bit VM?

No there is not, but it would be good to have one. It should be kept separate from the FAQ, because if we actually start working on making the plugins 64-bit clean the list will need to be updated as progress it made. The list would probably need to track the status of each plugin of all four combinations of 32/64 bit image and VM, as well as the operating system. This is because many plugins rely on external support code and libraries that are different on different platforms.

The following plugins currently work on Linux for all combinations of 32/64 bit image and VM:

BalloonEnginePlugin BitBitSimulation FilePlugin SocketPlugin AioPlugin OSProcessPlugin XDisplayControlPlugin

• Is there a (programmatic) way to find out if a given plugin will work

in a 64-bit VM? (e.g. compile-time errors, or the absence of them?)

No. Compiler warnings can give a clue of where to look for problems, but are not sufficient to indicate whether or not a plugin will work at runtime.

• Is there a set of guidelines on what to fix when porting a plugin?

Yes, there is a good set of guidelines on the http://www.squeakvm.org/squeak64/ page. See the "Hacking the VM" section, which explains the issues.

Dave