I wrote:
As a learning experience I have tried porting Squeak to Linux/m68k (Debian 2.0beta). While the make process ran without a problem (thanks Ian!) I quickly faced a segmentation fault when running Squeak (in the incrementalGC when the lowSpaceWatcher is installed, to be precise).
....
As I read it the memory has been malloced high up and all those ints that represent addresses have become negative, breaking the pointer arithmetic.
Some further investigations showed that the real problem is clearly stated in ObjectMemory>fwdTableInit: .... (checkAssertions and: [(fwdTableLast bitAnd: MarkBit) ~= 0]) ifTrue: [ "Note: Address bits must not interfere with the mark bit in header of an object, which shows that the object is forwarded." self error: 'fwd table must be in low half of the 32-bit address space'. ]. ....
The object header of a forwarded object looks like this Bit 0-1 TypeMask Bit 2-30 OOP of forward block minus the two low order bits which are always zero Bit 31 MaskBit
To make Squeak 32 bit clean I see a couple of solutions:
1) Use type code 2 which is currently unused (outside the mark phase) to signify "forwarded" and adjust methods that need the type code to look at the forwarding block. This would cost some(?) performance.
2) Ensure that forwarding blocks are quadword aligned (by adding 4 to fwdTableNext in ObjectMemory>fwdTableInit if it isnĀ“t). There are two substrategies here: 2a) Keep the header fields and shift the forwarding OOP to convert between stored and real OOP. This will cost some(?) performance. 2b) Move the MarkBit to bit 2 (adjacent to the type mask). This requires an image format change.
My preference would be 2b. What do the VM gurus say ?
Georg
---- Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(+43-1) 58801 - 5848 fax: (+43-1) 587 42 11 mail:gollmann@edvz.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html