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). Inspecting the variables I found following:
(gdb) print memory $22 = (unsigned char *) 0xc0151008 "À\026\030I\r"" (gdb) print endOfMemory $11 = -1068549284
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.
So...shouldn´t all variables that hold addresses (OOPs) be declared as unsigned instead of int (or am I barking up the wrong tree) ?
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
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). Inspecting the variables I found following:
(gdb) print memory $22 = (unsigned char *) 0xc0151008 "À\026\030I\r"" (gdb) print endOfMemory $11 = -1068549284
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.
So...shouldn´t all variables that hold addresses (OOPs) be declared as unsigned instead of int (or am I barking up the wrong tree) ?
Yes, or (void *) perhaps. But I'd hate to have to put all those type declarations into the Smalltalk code that is used to generate the C code for the VM...
It might be easier to figure out how to force allocation in the lower half of the address space.
-- John
John Maloney wrote:
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.
So...shouldn´t all variables that hold addresses (OOPs) be declared as unsigned instead of int (or am I barking up the wrong tree) ?
Yes, or (void *) perhaps. But I'd hate to have to put all those type declarations into the Smalltalk code that is used to generate the C code for the VM...
This highlights a strange issue I found when looking at the interpreter simulator: the simulator code treats everything in memory as unsigned whereas the generated C-code treats it, with a few explicit exceptions, as signed. Perhaps the best solution is to make the default declaration in the C-code unsigned and fix the places where signed is essential. Could still be a lot of work though...
Using void* carries a risk. Nothing in the C standard prevents a compiler from generating signed comparisons between pointers. And yes, I have learned this the hard way; it's not entirely hypothetical.
Wim Boot
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
While I still hope that future versions of Squeak will be 32bit clean I have concocted a quick and dirty hack to make it run (crawl?) on my old Mac IIsi under Linux/m68k (Debian 2.0). See: http://macos.tuwien.ac.at/Squeak/Linux%2Fm68k/
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
squeak-dev@lists.squeakfoundation.org
-
Georg Gollmann -
Maloney -
wimb＠bart.nl