[Vm-dev] egg sucking alert

[John McIntosh]

Recall at the time Apple didn't have 64bit support for a program to run
under Cocoa, plus only a limited number of machines support 64 bit kernels.
The fact you could go with a a 64 bit image on an 32bit machine allowed us
to debug the base VM.

I agree the 32/64 64/32 is nice and symmetric, but I'm afraid it's a nice
to have versus need now. If it's not seamless to write software and plugins
that honour that agreement, then it's a world of trouble and hassle that
it's not worth pursuing further.

On Thu, Dec 11, 2014 at 10:18 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

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


-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
https://www.linkedin.com/in/smalltalk
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141211/e40f9771/attachment-0001.htm