On Thu, Aug 02, 2007 at 08:29:54AM +0200, Hans-Martin Mosner wrote:
Jecel Assumpcao Jr schrieb:
I am back from a nice vacation (my first since 1982...) and see that you have all been waiting patiently for me to return before starting any interesting discussions ;-)
Ok, now that you're back, I can finally ask the questions which have puzzled me ever since :-) When implementing Smalltalk hardware, what kind of object memory design would you prefer:
I will attempt to answer based on my current understanding:
- object table vs. direct pointer
Object table is more flexible as it maintains a mapping of objects -> memory locations. However, on traditional machines, this slows things down as it doubles the number of memmory acesses. However, it is possible to optimize this in hardware by changing the addressing scheme of the processor and the cache (this cannot be done in software at all). The idea was first tried in the Mushroom computer [1], and has been incorperated into Jecel's plurion architecture.
What happens is that the processor *only* knows about object hashes/id's/whatever, and knows nothing of the memory layout. When the processor needs to read from memory, it sends out the object id and an internal offset on the address line. If the cache knows the object, it is immediately returned. If not, then a software interupt is raised which is expected to populate the cache with the requested data (exactly like how a TLB interupt works in a virtual paging OS). In the simplest case, this would just mean dereferencing the object table and storing the object in the cache, but it could be more complex. After the interupt returns, the fetch is retried and is found in the cache.
- ref counting vs. generation scavenging cs -whatever-
Garbage collection strategies should probably be left up to the OS/language. Maybe you are talking about object data caches? [2]
- page-based virtual memory vs. object-based VM vs. none at all
Plurion uses an object memory, as I stated above. I think I don't understand your question.
- in-band tags vs. out-of-band tags
Let me explain the last one. Smalltalk Implementations have typically had in-bad tags, i.e. the tags have only meaning in a word which is known to be an oop. The Burroughs machines had out-of-band tags, that is, every memory word had an additional tag. That way, you could even know whether a memory word contained uninterpreted bytes, a float value, or an "oop" (descriptor).
RISC42 uses 32-bit memory with 4 tag bits per word [3]
[1]: Mushroom computer: - http://www.wolczko.com/mushroom/
[2]: An Object-aware memory architecture - http://research.sun.com/techrep/2005/abstract-143.html
[3]: Completely Out-of-date Plurion paper. Page 10 has the tag assignments: - http://www.merlintec.com/download/plurion.pdf