<div dir="ltr">Hi David, Hi Bert,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 6:52 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Wed, Dec 10, 2014 at 06:01:02PM -0800, Eliot Miranda wrote:<br>
><br>
> On Wed, Dec 10, 2014 at 5:48 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> ><br>
> > On Wed, Dec 10, 2014 at 03:13:13PM -0800, Eliot Miranda wrote:<br>
> > ><br>
> > > Hi All,<br>
> > ><br>
> > > just a simple message about 64-bit code. Don't use int. Please use<br>
> > > long, unsigned long, sqInt or usqInt for variables that are of the<br>
> > > machine's natural word length (sqInt is a synonym for long and usqInt is<br>
> > a<br>
> > > synonym for unsigned long).<br>
> ><br>
> > No, sqInit is *NOT* a synonym for long.<br>
> ><br>
><br>
> Apart from on the weird "64-bit image on 32-bit platform" oddity that I see<br>
> no value in maintaining, sqInt == long.<br>
><br>
> On 32-bit C compilers<br>
><br>
> sizeof(int) == 4<br>
> sizeof(long) == 4<br>
> sizeof(sqInt) == 4<br>
><br>
> On 64-bit C compilers with a 64-bit image<br>
><br>
> sizeof(int) == 4<br>
> sizeof(long) == 8<br>
> sizeof(sqInt) == 8<br>
><br>
> There's an oddity of a 32-bit VM compiled in 64-bit mode on a 64-bit<br>
> machine. I don't know of anyone using it. But on that config<br>
><br>
> sizeof(int) == 4<br>
> sizeof(long) == 8<br>
> sizeof(sqInt) == 4<br>
<br>
</div></div>There is nothing odd about this at all. A sqInt corresponds to the size of a<br>
slot in the object memory, which only coincidentally has anything to do with<br>
the size of C integer data types on the host platform.<br></blockquote><div><br></div><div>I don't want to fight, but let me tell you what I really think. Having an oop be larger than the machine's pointer size is *absurd*. One wastes half the available address space representing a pointer by using twice the space one needs. That is insane. I'm not going to expend one iota of effort making this work.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> I'm in the process of providing a real 64-bit system with 61-bit<br>
> SmallIntegers, immediate floating point, a segmented memory, etc, etc. I<br>
> am /not/ going to be held up trying to maintain the old 64-bit VM<br>
> oddities. A 32-bit VM on a 32-bit platform and a 64-bit VM on a 64-bit<br>
> platform are enough, and expensive enough to maintain.<br>
<br>
</span>Nonsense. If you want a data type to represent object pointers, then define<br>
one, and give it a meaningful name such as "sqOop". This is very much needed,<br>
and would be a great improvement over the current state of affairs. Please<br>
do not continue the past practice of guessing at what "sqInt" should mean,<br>
particularly if your personal opinion as to what it should mean happens to<br>
be different from the opinion of the last person who made the same mistake.<br></blockquote><div><br></div><div>I agree. But that's much more effort than fixing the few places where int is used mistakenly and erroneously to define a paramter that can take an oop. I'm not rewriting all of platforms to move to a more elegant solution now. I don't have the time now. Now that 32-bt Spur is ready for deployment my priority is to get 64-bit Spur working.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would also be useful to explicitly define a data type that represents a<br>
location in the object memory, which might be 32 or 64 bits in size, independent<br>
of the size of object pointers, C pointers, and integer size on the host platform.<br></blockquote><div><br></div><div>Again, the issue is to get a 64-bit Spur VM to compile and run, not to revamp VMMaker to do things right. For that, using long and/or sqInt is a suitable solution.</div><div><br></div></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>