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 at 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--------------------------