On Sun, Jul 04, 2004 at 10:34:46AM -0700, tim Rowledge wrote:
> I have the problem on my Iyonix (www.iyonic.com) when using Aemulor 
> (www.aemulor.com) because the DAs (google Dynamic Areas RISC OS Acorn) 
> are placed in a high address range and  can start at just below 2Gb and 
> obviously wrap over 2Gb. The only problem I've seen it cause so far is 
> the failure of prim 99(?) that fiddles the oops in a loaded imagesegment.

It would be pretty surprising if this was that only thing that failed,
because there are memory address checks scattered all over the interpreter.
However, just on the off chance that it might help, I have attached a
hack for Interpreter>>oopHasOKclass: that coerces to unsigned arithmetic
for the memory checks. I have *not* tested this other than to make sure it
compiles cleanly.

> As previously suggested I suspect that the problem may be solved as a 
> side effect of the VM changes Ian has provided to support 64bit 
> machines. If not, then it will likely be some more work of a similar 
> nature to solve. The root cause is that assumption (remember, "assume 
> makes an ASS out of U and ME") that singed int is a good type for oops. 
> Actually, I suppose that the real root is the idea of types....

Certainly. I expect that declaring the data types for object memory
correctly was one of the first things that Ian had to address.

Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Prim99Hack-dtl.1.cs.gz
Type: application/x-gunzip
Size: 875 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040704/5d2097e1/Prim99Hack-dtl.1.cs.bin