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

David T. Lewis lewis at mail.msen.com
Fri Dec 5 01:12:42 UTC 2014


On Thu, Dec 04, 2014 at 06:50:05PM -0500, Chris Cunnington wrote:
> 
> And it's still pretty confusing. The fact that it can confuse Levente Uzonyi
>is both liberating and a salutary lesson. And as I've opened my big mouth,
> I may as well put my head on the chopping block. 
> 

I find it very confusing also. After all, we are dealing with address space
in memory, virtual address space in the OS process that maps to that memory,
a big array of object memory that got allocated somewhere within that process
virtual address space, a system of byte-addressable object pointers that refer
to locations within the object memory, and a bit of tricky object pointer
decoding that involves checking each pointer value to see if it points at a
4 or 8 byte boundary, and if not, then decode the pointer as an immediate value.
And of course, the thing that that object pointer points to is an object header
word, which might be either 32-bits or 64-bits, and which might be one of
up to three header words, unless is it Spur, in which case it always has one
header word.

You are entitled to be confused. If you were not confused the first few
times you looked at this, you probably were not paying attention.


> - the heap readdresses 32-bit locations, so they are not the same as the addresses in memory, the numbers on the metal 
> - a 32-bit address can be an immediate object, because the address can be a 30-bit number. (i.e. @00000007) 
> - a 32-bit address can be a reference to 96-bit object somewhere. The 32-bit address leads to a header that describes the object pursuant of the ObjectMemory comment [1]
> 
> If these things are true, then doesn't that mean every time a number is used, then that 32-bit space, which could have been an address, is now invalid as an address to an object? If that's right, then it's a tad odd, right? The more math you do then the more @00000007 and @00000008 numbers are consumed leaving fewer, of the possible 4.3 billion 32-bit words to address objects with headers. And if that's true, then some intelligence in the VM somewhere is saying: "No, that address is working as an 'immediate object' for math. You'll have to use another 32-bit address to lead you to the 96-bits that come complete with a header". 
> 

You are exactly right. The address space is "wasteful". The object pointers are
pointers to byte locations within the object memory space. But the positions in
the object memory are either 32-bit words (in the current object memory) or 64-bit
words (in the Squeak "format 68002" object memory or in 64 bit Spur).

So it is indeed wasteful to use byte-addressable pointers to point to 32-bit or
64-bit locations in the object memory. But there is a hidden advantage to this
waste of address space. Any object pointer that points to a byte that is not
on a 32-bit (or 64-bit) boundary is pointing at something that cannot
possibly be an object header. In a 32-bit object memory, only one of every
four addresses can be a valid location in the object memory. All the rest of
those "wasted" addresses can be used for something else.

So what should the wasted addresses be used for? Immediate objects.

Dave



More information about the Squeak-dev mailing list