[Vm-dev] egg sucking alert

[Eliot Miranda]

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

>
> Eliot,
>
> maybe this came across as if we wanted to somehow interfere with your 64
> bit work. On the contrary! We simply think it wise to use clearly defined
> type declarations that allow all sorts of implementations, even ones you
> would consider silly. Nobody is expecting you to make the silly stuff work
> :)
>
> On 11.12.2014, at 19:28, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> 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.
>>
>> 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.
>
>
> 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.
>
>
> Not for people who can't easily run a 32 bit VM on their 64 bit system.
> I'm with you that the Linux folks got it wrong, that their zealous goal of
> making a 64-bit-only system is misguided. Nevertheless, it is legitimate to
> want to compile a VM on these crippled 64-bit-only systems and have it run
> a normal (32-bit) image.
>
>
>>   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.
>
>
> Sure. That does not imply we need to make our respective goals harder to
> achieve, if that is simple to avoid. And using "sqInt" throughout is pretty
> simple IMHO.
>
>
> 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.
>
>
> As I said, I don't particularly care how we make this work. If a child
> takes their image from the school computer and wants to run it at home, and
> one machine happens to be 64 bits and the other does not, then it would be
> dreadful if it had to run it through a converter. But we may be able to
> hide that in the VM startup script.
>
> 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.
>
>
> No. Maybe I miswrote, or you misread. We do want to use sqInt for oops,
> because that is defined by us, not by the compiler.
>
>
>> Please do *not* use "long" in VM code.
>>
>
> Bollocks.
>
>
> I meant "do *not* use 'long' for oops", with which I think you actually
> agree.
>
>  long is an integral type defined to be large enough to take a pointer.
> If sqInt is out, as you stipulate above,
>
>
> I didn't. I advocated using sqInt.
>
> 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.
>
>
> That would only be the case for a 64-bit image running on a 32-bit
> platform. Which is very expensive, sure, and not something we would advise
> anyone to use in production.
>
> Much more relevant is the case of sizeof(sqInt) == 4 when sizeof(void *)
> == 8, as I wrote above.
>
> Now, I don't ant to fight anymore.
>
>
> Yeah, fights are no fun if you can't scream at each other and have a beer
> after. But then again, apart from use of the n-word (for which there was an
> apology), we're not even really fighting :)
>
> The only thing we questioned was that you said "long" was a fine
> replacement for "sqInt" in general. But as I understood it that was just an
> off-hand remark and not an actual advice to go and replace every use of
> "sqInt" with "long".
>

Right.  I suggest using long to declare parameters that take pointers
encoded as integers.  As in the fileNamePtr argument in

int asyncFileOpen(AsyncFile *f, int fileNamePtr, int fileNameSize, int
writeFlag, int semaIndex);

The simplest fix to this code is

int asyncFileOpen(AsyncFile *f, long fileNamePtr, int fileNameSize, int
writeFlag, int semaIndex);

Of course it should be written

int asyncFileOpen(AsyncFile *f, char * fileNamePtr, int fileNameSize, int
writeFlag, int semaIndex);

or void *, but that requires modification of the body of asyncFileOpen
which is more work than I want to put in on this.

Of course it should /really/ be written

long asyncFileOpen(AsyncFile *f, char * fileNamePtr, long
fileNameSize, long writeFlag, long semaIndex);

because on 64-bits there may actually be code generated to convert to the
32-bits tat int defines, whereas long is natural and requires no nonsense
by the compiler to pass as a parameter, put in a register etc.

Hence my advice, don't use int.




> So we just wanted to clarify that the right type to use for oops was in
> fact sqInt (or as David said a yet-to-be introduced "oop" type).
>
> Peace?
>

Peace.

- Bert -
>

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