[Vm-dev] egg sucking alert

Eliot Miranda eliot.miranda at gmail.com
Thu Dec 11 18:18:20 UTC 2014


Hi David, Hi Bert,

On Wed, Dec 10, 2014 at 6:52 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Wed, Dec 10, 2014 at 06:01:02PM -0800, Eliot Miranda wrote:
> >
> > On Wed, Dec 10, 2014 at 5:48 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > >
> > > On Wed, Dec 10, 2014 at 03:13:13PM -0800, Eliot Miranda wrote:
> > > >
> > > > Hi All,
> > > >
> > > >     just a simple message about 64-bit code.  Don't use int.  Please
> use
> > > > long, unsigned long, sqInt or usqInt for variables that are of the
> > > > machine's natural word length (sqInt is a synonym for long and
> usqInt is
> > > a
> > > > synonym for unsigned long).
> > >
> > > No, sqInit is *NOT* a synonym for long.
> > >
> >
> > Apart from on the weird "64-bit image on 32-bit platform" oddity that I
> see
> > no value in maintaining, sqInt == long.
> >
> > On 32-bit C compilers
> >
> >         sizeof(int) == 4
> >         sizeof(long) == 4
> >         sizeof(sqInt) == 4
> >
> > On 64-bit C compilers with a 64-bit image
> >
> >         sizeof(int) == 4
> >         sizeof(long) == 8
> >         sizeof(sqInt) == 8
> >
> > There's an oddity of a 32-bit VM compiled in 64-bit mode on a 64-bit
> > machine.  I don't know of anyone using it.  But on that config
> >
> >         sizeof(int) == 4
> >         sizeof(long) == 8
> >         sizeof(sqInt) == 4
>
> There is nothing odd about this at all. A sqInt corresponds to the size of
> a
> slot in the object memory, which only coincidentally has anything to do
> with
> the size of C integer data types on the host platform.
>

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.


>
> > I'm in the process of providing a real 64-bit system with 61-bit
> > SmallIntegers, immediate floating point, a segmented memory, etc, etc.  I
> > am /not/ going to be held up trying to maintain the old 64-bit VM
> > oddities.  A 32-bit VM on a 32-bit platform and a 64-bit VM on a 64-bit
> > platform are enough, and expensive enough to maintain.
>
> Nonsense. If you want a data type to represent object pointers, then define
> one, and give it a meaningful name such as "sqOop". This is very much
> needed,
> and would be a great improvement over the current state of affairs. Please
> do not continue the past practice of guessing at what "sqInt" should mean,
> particularly if your personal opinion as to what it should mean happens to
> be different from the opinion of the last person who made the same mistake.
>

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.


It would also be useful to explicitly define a data type that represents a
> location in the object memory, which might be 32 or 64 bits in size,
> independent
> of the size of object pointers, C pointers, and integer size on the host
> platform.
>

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.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141211/16036dfe/attachment.htm


More information about the Vm-dev mailing list