Hi Dan, Andreas, et.al.
In my attempts at porting Squeak to BeOS I've run into a problem/issue that you may be able to shed some light on. During the course of my initial attempts to read in the Squeak image into the interpreter, I got a PPC exception. Looking into it I've discovered that the initial malloc was succeeding but the conversion of the unsigned char* to int was failing due to BeOS's using 32bit addresses, with application memory starting at 0x80000000...the type conversion was failing with a negative value, which messed up all the succeeding memory calculations.
Relevant code: unsigned char *memory; int memStart; int desiredHeapSize; memory = (unsigned char *) malloc(desiredHeapSize); memStart = (int) memory;
memStart would be negative. My question(s) are: 1) Shouldn't the typecast be uint? Memory addresses should never be negative. 2) Under BeOS I'll probably have to use: uint32 memStart = (uint32) memory; What else will this affect off the top of your head(s) so I don't have to debug line by line ;-) 3) I'm assuming the Smalltalk->c conversion code needs to take into account 32 bit addresses. Any hints on what I need to change? And if I change this, this will break the portability issues dealing with the inner interpreter; how best should I handle this? Is this something you should be worried about in your versions?
Thanks for any suggestions, hints, and your patience, Serg
------------------------------------------------- VisualNewt Software: http://www.VisualNewt.com/ Maker of Newt'sPaper(tm) the Premier Newton(R) MessagePad(tm) News Reader.
-----------Sent by BeOS--------------------------
Serg,
In my attempts at porting Squeak to BeOS I've run into a problem/issue that you may be able to shed some light on. During the course of my initial attempts to read in the Squeak image into the interpreter, I got a PPC exception. Looking into it I've discovered that the initial malloc was succeeding but the conversion of the unsigned char* to int was failing due to BeOS's using 32bit addresses, with application memory starting at 0x80000000...the type conversion was failing with a negative value, which messed up all the succeeding memory calculations.
Actually, this should not be a problem. Even if the memory address is negative, the computations should be done correctly (since number1 + number2 will be greater than number1 even if it is negative). I'd think that there should be some way to turn the sign check off, so that all is running correctly.
- Shouldn't the typecast be uint? Memory addresses should never be negative.
You're right. Unfortunately, this would force a number of warnings at other locations (which don't matter as long as you can turn the sign check off).
- Under BeOS I'll probably have to use:
uint32 memStart = (uint32) memory; What else will this affect off the top of your head(s) so I don't have to debug line by line ;-)
Provided that your C compiler _does_ sign checking you'll run into a number of problems. All of the memory stuff is done in relation to memStart so the best way is probably to assure your C compiler to forget about sign checking.
- I'm assuming the Smalltalk->c conversion code needs to take into account
32 bit addresses. Any hints on what I need to change? And if I change this, this will break the portability issues dealing with the inner interpreter; how best should I handle this? Is this something you should be worried about in your versions?
As long as everything is done with the right data types (see those checks in the main() function of sqMacWindow.c, sqXWindow.c, and sqWin32Window.c) everything should work as expected. These basic assumptions are: * sizeof(int) = 4 * sizeof(double) = 8 * sizeof(time_t) = 4
Hope this helps, Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Serg Koren