<div dir="ltr"><br><div><div class="gmail_extra"><br><div class="gmail_quote">2016-11-08 16:08 GMT+01:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
On Tue, Nov 08, 2016 at 03:19:50PM +0100, Nicolas Cellier wrote:<br>
><br>
> Hi David,<br>
> Sorry, I've no linux/mac vm available currently to exhibit the problem.<br>
<br>
</span>Hi Nicolas,<br>
<br>
I was using this pre-built Spur VM:<br>
<br>
Virtual Machine<br>
---------------<br>
/usr/local/lib/squeak/5.0-<wbr>201607171247_64/squeak<br>
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1902]<br>
Unix built on Jul 17 2016 14:02:20 Compiler: 4.6.3<br>
platform sources revision VM: r201607171247 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm.git</a> $ Date: Sun Jul 17 14:47:17 2016 +0200 $ Plugins: r201607171247 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm.git</a> $<br>
CoInterpreter VMMaker.oscog-eem.1902 uuid: d5860bb5-b41c-4337-90d4-<wbr>c2abc979248d Jul 17 2016<br>
StackToRegisterMappingCogit VMMaker.oscog-eem.1902 uuid: d5860bb5-b41c-4337-90d4-<wbr>c2abc979248d Jul 17 2016<br>
<br>
<br>
Unfortunately I cannot compile Cog/Spur on my Ubuntu PC (build system issues),<br>
so I cannot be of much help beyond that.<br>
<br>
But just for my own understanding, is it the case that IntegerArray access<br>
does not work for you on a 64 bit image on Windows?<br>
<br>
Note, the #ifdef USE_INLINE_MEMORY_ACCESSORS is very old. I think that Ian<br>
wrote it (Tim might know better). The only memory access code that I wrote<br>
is the Smalltalk (slang) version in the VMMaker repository, but that is<br>
not relevant here.<br>
<br>
Dave<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>So this path is forced on macosx 32 & 64 bits via<br><a href="https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/build.macos64x64/common/Makefile.vm">https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/build.macos64x64/common/Makefile.vm</a><br><br>DEFS:=    $(COGDEFS) -DUSE_GLOBAL_STRUCT=0 -DNO_ISNAN=1 \<br>        -DUSE_INLINE_MEMORY_ACCESSORS -D'TZ="$(TZ)"' \<br>        $(INTERPFLAGS)<br><br></div><div>Linux does not have it set... That explains the difference, I tested 64bits spur on mac...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
<br>
> But if you look at github head revision<br>
><br>
> <a href="https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/spur64src/vm/gcc3x-cointerp.c" rel="noreferrer" target="_blank">https://raw.githubusercontent.<wbr>com/OpenSmalltalk/<wbr>opensmalltalk-vm/Cog/<wbr>spur64src/vm/gcc3x-cointerp.c</a><br>
><br>
> then you'll find this code:<br>
><br>
> primitiveIntegerAt(void)<br>
> {   DECL_MAYBE_SQ_GLOBAL_STRUCT<br>
>     sqInt addr;<br>
> ... snip declarations of no interest ...<br>
>     sqInt value;<br>
> ... snip long preamble to check parameter types ...<br>
><br>
>       /* for zero indexing */<br>
>       addr = (rcvr + BaseHeaderSize) + ((index - 1) * 4);<br>
>       value = intAt(addr);<br>
>       /* begin pop: */<br>
>       GIV(stackPointer) += 2 * BytesPerWord;<br>
>       if ((((((usqInt) value) >> 60) + 1) & 15) <= 1) {<br>
>               /* begin pushInteger: */<br>
>               longAtput((sp = GIV(stackPointer) - BytesPerWord), ((value << 3) | 1));<br>
>               GIV(stackPointer) = sp;<br>
>       }<br>
>       else {<br>
> ... snip this branch is never reached ...<br>
>       }<br>
> }<br>
><br>
> Above code clearly can't work if the 32bit contents of addr is not<br>
> sign-extended into the 64bits value...<br>
> So I don't know which version you used exactly,<br>
> ...UNLESS...<br>
> there might be another reason for the mismatch in:<br>
><br>
> <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Cross/vm/sqMemoryAccess.h" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/Cross/<wbr>vm/sqMemoryAccess.h</a><br>
><br>
> You can see that the two possible compiler branches don't agree and won't<br>
> behave the same sign-wise:<br>
><br>
> #ifdef USE_INLINE_MEMORY_ACCESSORS<br>
>   /* Use static inline functions when the compiler produces efficient<br>
> code for small accessors.<br>
>      These are preferred because static type checking will prevent<br>
> inadvertent confusion of pointers and oops. */<br>
> ... snip ...<br>
>   static inline sqInt intAtPointer(char *ptr)                 { return<br>
> (sqInt)(*((unsigned int *)ptr)); }<br>
>   static inline sqInt intAtPointerput(char *ptr, int val)     { return<br>
> (sqInt)(*((unsigned int *)ptr)= val); }<br>
> ... snip ...<br>
><br>
> #else /* USE_INLINE_MEMORY_ACCESSORS */<br>
>   /* Use macros when static inline functions aren't efficient. */<br>
> ... snip ...<br>
> # define intAtPointer(ptr)                    ((sqInt)(*((int *)(ptr))))<br>
> # define intAtPointerput(ptr,val)     ((sqInt)(*((int *)(ptr))= (int)(val)))<br>
> ... snip ...<br>
> #endif /* USE_INLINE_MEMORY_ACCESSORS */<br>
><br>
> I presume you (or someone else) arranged to not  USE_INLINE_MEMORY_ACCESSORS<br>
> Though it seems to be the default to use them on macosx (I'm just invoking<br>
> ./mvm).<br>
><br>
> The two branches should better adopt the same (sane) behavior, shouldn't<br>
> they?<br>
><br>
> 2016-11-08 14:23 GMT+01:00 David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>>:<br>
><br>
> ><br>
> > On Tue, Nov 08, 2016 at 03:29:05AM +0100, Nicolas Cellier wrote:<br>
> > ><br>
> > > In this code:<br>
> > ><br>
> > >   static inline sqInt intAtPointer(char *ptr)   { return<br>
> > > (sqInt)(*((unsigned int *)ptr)); }<br>
> > >   static inline sqInt intAtPointerput(char *ptr, int val)  { return<br>
> > > (sqInt)(*((unsigned int *)ptr)= val); }<br>
> > ><br>
> > > the usage of unsigned int is questionable...<br>
> > > It means that intAt and long32At won't perform sign extension in 64bits<br>
> > > Spur VM.<br>
> > > Since it returns a signed result (sqInt), that's troubling.<br>
> > ><br>
> > > The sole real sender of intAt seems to be primitiveIntegerAt: which fails<br>
> > > for this reason on 64bits spur when fed with negative integers.<br>
> ><br>
> ><br>
> > Can you give an example of the failure? I tried on 64-bit Spur and also<br>
> > on image format 68002 (64-bit V3) on Linux, and the accesses to elements<br>
> > of an IntegerArray work correctly in both cases.<br>
> ><br>
> ><br>
> > For example:<br>
> ><br>
> > { -1 . -2 . -3 . -4 . 7 . -9 } asIntegerArray ==> an IntegerArray(-1 -2 -3<br>
> > -4 7 -9)<br>
> ><br>
> > Accessing the elements of this IntegerArray works as expected, and I can<br>
> > see<br>
> > in an inspector that the first element is stored internally as 16rFFFFFFFF.<br>
> ><br>
> > Is there something else that is failing?<br>
> ><br>
> > Dave<br>
> ><br>
> ><br>
> > ><br>
> > > For long32At, it's difficult to analyze: many senders!<br>
> > ><br>
> > > IMO, if we don't want a signed quantity, we should better write<br>
> > > unsignedLong32At (or use lowcode uint32AtPointer which answers a 32 bits<br>
> > > result)<br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br></div></div></div>