Enhance the VM to 64bit

[blairmcg]

From @objectarts on January 28, 2016 17:56

Copied from original issue: dolphinsmalltalk/DolphinVM#22

[blairmcg]

From @jgfoster on January 29, 2016 14:5

@objectarts, I'm interested in this task and it gives me the opportunity to raise a question about coding style and names.

For me there is a non-trivial cognitive load to translating all the integer types into signs and sizes. How big is int? Is it the same in 32-bit and in 64-bit? How is it different from long (see compiler.cpp:723)? What is DWORD? I know the size of BYTE but is it signed or unsigned? A certain number of the runtime errors (#18) are related to conversion to smaller types and I can't help but imagine that it would be useful to have these things more obvious.

In the past I've been involved in projects where typdefs were created for all integer types along the lines of the following: sintNN and uintNN where NN is 8, 16, 32, 64, or 128. This allows one to tell at a glance whether an item is signed or unsigned and its size.

I've assumed that most people with experience on a project get used to the existing names and would be reluctant to see things change, but I still think that it requires some cognitive load (and "brainpower is by far our scarcest resource").

This enhancement request has given me courage to at least ask your thoughts on such a change. Should I immerse myself in the environment and get used to the existing names (and create a cheat-sheet to help carry the cognitive load), or would you be receptive to considering some rather large-scale (but otherwise trivial) edits? I expect the answer to be that I should follow the existing conventions, but I thought I'd ask...

[blairmcg]

@jgfoster, this is a huge work item hiding behind a very short description. The VM contains large amounts of x86 assembly code which needs wholesale replacement one way or another.

I did make a start on it a few years ago, and you can see some of the residue of this in the FFI support in the image, e.g. the ExternalField type INT_PTRField which varies in size, and this and its unsigned equivalent, are used in various ExternalStructure definitions that contain pointers or integer values that vary in length on Win64 vs Win32. The VM passes in the actual value through the well known VMConstants pool, and it was set up so that the structures would recompile to match the actual pointer size (not sure if that still works). All the work I did on the VM, which would have started by removing 32/64 bit portability issues like the kind of issues you mention, has long since been lost.

BYTE, DWORD, etc are fixed size unsigned integers. BYTE is obvious, and DWORD is 32-bits. Where bit length matters, the code should not be using int, long, etc. I think it would be quite reasonable to adopt some consistent easy to understand form for the integer types of fixed and variable sizes, although preferably some existing one defined in the SDK headers (if there is one).

[blairmcg]

From @jgfoster on January 29, 2016 19:15

@blairmcg, I understand that a 64-bit port is likely to be huge. I should probably have been clearer in saying that "I'm interested in this task being done" (with no implication that I think I could easily do it!).

As I understand it, your last paragraph is supporting my idea of unifying the various integer types with explicit sign and size.

[blairmcg]

@jgfoster, yes, I support your suggestion.

I think it is one of Andy's little jokes to use 5 words to describe 5 months worth of full-time work.

[blairmcg]

From @fxgallego on January 30, 2016 19:23

I'd like to know how difficult would be increase the object table size and if there is a technical limit with the actual object memory implementation. Thanks!

[blairmcg]

Very easy. You just change a constant that specifies the max size to which the object table can grow (which it does on demand in 64Kb chunks). Note, however, that this is set at image creation time and stored in the image header (which you can patch). The default is currently 2^24 objects (about 17 million). However living within 32-bits will impose a limitation fairly quickly - an object table entry is 16 bytes, and then the minimum size of an object body with any data is 8 bytes (ignoring heap overhead), and the actual average size will be higher than that and depend on your application. I can't remember whether Dolphin is large address aware i.e. able to use the full 32-bits when running on a 64-bit machine, and therefore able to use 4Gb of RAM, or whether it is limited to 2GB - but I suspect the entire heap will need to fit in 2Gb.