[Vm-dev] Re: [squeak-dev] Spur with Immediate Floating Point Support implies a break

[David T. Lewis]

On Thu, Dec 04, 2014 at 04:18:18AM +0100, Levente Uzonyi wrote:
> 
> Hi Eliot,
> 
> On Wed, 3 Dec 2014, Eliot Miranda wrote:
> 
> >SmallFloat64 is an immediate tagged representation, like SmallInteger, so
> >they fit within an object pointer and have no header.  In 64-bit Spur there
> >is a 3-bit tag, leaving 61 bits.  SmallFoat64 steals 3 bits from the 11-bit
> >exponent to donate to the tags, representing a full double precision
> >floating-point value that is restricted to the ~ +/-10^+/-38 range.
> >There's really no practical way to shoe-horn a usable range of 64-bit float
> >into a 30-bit value.  Its possible but so few values would fit that the
> >effort would be counter-productive.  DOes this make sense now?
> 
> I didn't mean to use 30-bit values. I meant to use the same 61-bit 
> representation as with the 64-bit Spur.
> The object header is 64 bits long in both 32-bit and 64-bit Spur, right?
> If yes, then why is it not possible to detect the tag of SmallFloat64 in a 
> 32-bit VM, and treat the object as immediate?

Our terminology is rather confusing here, particularly if you are accustomed
to pointers in the C language.

The class comment of ObjectMemory (written by Dan Ingalls) gives a very good
explanation, but you have to realize that the "pointers" are not pointers in
the sense of the C language. They are effectively indexes into a big array of
(32 bit or 64 bit) slots that make up the object memory. An object memory
pointer is an integer value that points to an object header. In Spur, the
object header is 64 bits in size, but the object pointer (or "oop") will be
either a 64 bit integer in the 64 bit Spur object memory, or a 32 bit integer
in the 32 bit Spur object memory.

Immediate values are encoded within the object pointer, not the object header.
The trick is that, if you know in advance that the locations of object headers
within the object memory will be placed on 32 bit or 64 bit boundaries, and
if the object pointers refer to byte (not word) addresses, then you know that
any object pointer with the low order bit set (or low order two bits in the
case of a 64 bit object memory) cannot refer to any valid location in the object
memory. That is why the low order bits are used to "tag" the immediate values.

The immediate values are thus hidden within the address space of object pointers,
not in the actual object headers. For a 32-bit object memory, where the object
pointers are 32 bits (even if the object headers are a different size), there
is no room to pack anything other than the immediate small integers.

In addition to the class comment in ObjectMemory, you can also look at class
MemoryAccess from the MemoryAccess package on the VMMaker repository. This
implements the mapping of object memory pointers to lower level C pointers.
It is written in Smalltalk rather than the traditional C preprocessor macros,
so it provides a few comments that hopefully make it easier to read (and to
execute in either the VM simulator or a C debugger).

Dave