Porting to 64-bit

[GoogleCodeExporter]

This is probably a very large task.  

The primary reason for doing this would be the potential for supporting
64-bit (62-bit tagged) Doubles as immediates, so real number crunching
could be done in Smalltalk.  An investigation should be made first into
whether low-bit tagging will work for the IEEE 64-bit format.

Major areas this will affect:
    - object layout, header format
    - generated machine code
    - heap management

Original issue reported on code.google.com by David.Gr...@gmail.com on 22 Sep 2006 at 9:58

[GoogleCodeExporter]

Original comment by David.Gr...@gmail.com on 22 Sep 2006 at 10:00

• Added labels: Porting

[GoogleCodeExporter]

Original comment by David.Gr...@gmail.com on 22 Sep 2006 at 10:08

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Tagging IEEE-754 double precision floats (64 bit) is certainly possible
(see http://www.lcs.mit.edu/publications/pubs/ps/MIT-LCS-TM-396.ps)

However, it wouldn't solve the problem: quadwords (128 bits) are very common on 
SIMD
architectures (PPC altivec, x86 sseX, CBE SPE)

Wouldn't it be better to unbox data in recompiled nmethods instead ?

Moreover, it might open opportunities to write a vectorisation backend to the
compiler : Instrumentation, aggressive inlining and easy pointer analysis (no
aliasing) gives all the information needed to generate extremely efficient code 
on
modern architectures, running an order of magnitude faster than C code

Original comment by prunedt...@gmail.com on 19 Jan 2007 at 9:17