Last week during the Wild & Crazy Ideas session at ASPLOS, I mentioned floating point addresses, and several people asked me about it later. I partially incorrectly attributed it to Jim Kajiya; the CS Tech Report on the Caltech Object Machine (COM) is by Dally and Kajiya (in that order).
The basic premise is that segmented architectures with fixed-size segments are always a pain because the segments are never the right size -- either the segment is too small, or if they're large, you can't have enough of them to be useful. In COM, the exponent of a floating-point number can be considered the object identifier, and the mantissa can be considered the offset within the object. Since the boundary between the exponent and the mantissa is flexible, you can have lots of small objects, or a few large objects, under system & compiler control.
It's been a while since I looked at it; I think objects are limited to a power of two in size, so bounds checks on them will prevent gross memory allocation violations, but not necessarily subtle off-by-one bounds errors. Other obvious questions I don't recall the answers to include how memory fragmentation is avoided.
I'm curious how this concept could be melded with modern compiler array privatization techniques. COM seems, offhand, to be very good for arrays but less useful for heterogeneous objects, and privatization could certainly help there.
The link above is to a Caltech technical report, but I believe they also got an ISCA paper out of it; I don't know if the two are the same. The TR talks about a machine simulation; as far as I know, no prototype was actually built, but I could easily be wrong there.
No comments:
Post a Comment