[Vm-dev] egg sucking alert

[Eliot Miranda]

On Thu, Dec 11, 2014 at 3:12 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> On 11.12.2014, at 03:01, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> 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.
>
>
Right.  But since the rationale for this VM is only to interface with
64-bit libraries, it depends on a 64-bit FFI, which we do not have.  So in
the absence of a 64-bit FFI it is pointless.  Instead running the 32-bit VM
on the 64-bit platform is a perfect replacement.  For me having a 64-bit
VM/image working is a higher priority than having a 32-bit image/64-bit
VM.  Both are dependent on the 64-bit FFI but the latter also lifts the
address space limit, so it kills more birds.


>
> This actually is *the* single most requested VM people want on Linux. It's
> just not quite stable because Dave has been working on it all on his own.
>
>   But on that config
>
>         sizeof(int) == 4
>         sizeof(long) == 8
>         sizeof(sqInt) == 4
>
> 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.
>
>
> Dear VM. You have *one* job. Be virtual. Make my image run no matter what
> actual platform we are on.
>

That's fine.  You break your back doing that.  My definition of a VM is
different.  Provide a performant, safe, interoperative platform on which to
run Smalltalk et al. I'm not interested in virtuality per se.  I'm
interested in being able to get work done.  I will choose popular platforms
and performance over slowness and portability.  I will choose FFI over
plugins.  We differ.  Let's accept that difference.



> Seriously, we need to be able to take an image from one platform and run
> it on another.
>

But that can be done with off-line tools.  It doesn't need to be done with
an all-in-one VM that is slow, complex and difficult to maintain.


> If your particular VM cannot cover all platform-image combos, fine. You
> trade performance for cross-platformness. That's cool. But please don't
> make it harder for those of us who *do* value cross-platformness in futzing
> around with sqInt. It is *defined* as being a type of the image's word
> size, not the machines's word size.
>

OK, so use long.


>
> Please do *not* use "long" in VM code.
>

Bollocks.  long is an integral type defined to be large enough to take a
pointer.  If sqInt is out, as you stipulate above, and the existing code is
written to take an integer parameter in which is passed a pointer then long
is the only choice.  Rewriting all the platform code to take pointers where
pointers are passed is work for the future, not busy work that advances
nothing.

But if th absurdity of sizeof(sqInt) == 8 when sizeof(void *) == 4 is
accepted then we can use sqInt.

Now, I don't ant to fight anymore.  I'm getting back to getting a 64-bit
Spur stack VM running on linux.  You do what pleases you.



> +1 to what Dave wrote. (*)
>
> - Bert -
>
> (*) The first word coming to my mind was the same one Dave used.
>
>

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