Hi Andreas, Thanks for the response. I'm using Metrowerks Codewarrior...I'll check to see if I can force signs off. If the case is, that all the address math is relative (which it would make sense for it to be so as you say), then I still need to figure out why I'm getting an exception on incCompBody() while doing an initial GC. The 'realHeader' variable is blowing out where fwdBlock2 = 2177852. Oh well guess I'll have to do more digging.

Thank you much for the response. S

---- On Sat Jan 24 23:19:07 1998, Andreas Raab said ------

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.

...

1. 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).

...

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 ;-)

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.

...

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?

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

-- Linear algebra is your friend - Trigonometry is your enemy. +===== Andreas Raab ============= (raab@isg.cs.uni-magdeburg.de) =====+ I Department of Simulation and Graphics Phone: +49 391 671 8065 I I University of Magdeburg, Germany Fax: +49 391 671 1164 I +=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+

------------------------------------------------- VisualNewt Software: http://www.VisualNewt.com/ Maker of Newt'sPaper(tm) the Premier Newton(R) MessagePad(tm) News Reader.

-----------Sent by BeOS--------------------------