Re: pdumper on Solaris 10

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

>> If a Lisp_Object looks like this
>>
>>   0                 32                   64
>>   +------------------+-------------------+
>>   | tag | pointer    |  ...              |
>>   +------------------+-------------------+
>>
>> there is a chance it could be made to work, if ugly. That's USE_LSB_TAG
>> == 1.
>
> It does appear to work.  I'm not sure how it is "ugly", to be honest,
> since MPS only sees 32-bit words, and that's the tagged pointer and
> 0. No changes required.

I was just assuming it would end up ugly in some form. But I haven't
thought about it much. WIDE_INT and 32-bits are in an SEP field for
me :-).

>> If it looks like this
>>
>>   0                 32                   64
>>   +------------------+-------------------+
>>   |       pointer    |  ...         |tag |
>>   +------------------+-------------------+
>>
>> it gets a lot more ugly. That's USE_LSB_TAG == 0.
>
> Given that gcc likes storing the two 32-bit words of a 64-bit integer in
> non-adjacent places on the stack, it would be quite expensive to get
> this working.

Yeah, that's for sure. Nightmare.

> And if we decided to do that, it would become a lot more complicated to
> change our tagging scheme (which we should do, some time after merging
> MPS, to speed up EQ by having a "may be EQ to a different object" tag
> or, ideally, bit: EQ could then be simplified to
>
> if (x == y)
>   return true;
> else if (((x|y) & BIT) == 0)
>   return false;
>
> <expensive non-inlined code here>)

Hm, interesting idea. One would have to try it out of course to know,
but from a gut feeling, would you say one would notice a difference?
I don't have an "educated" gut feeling wrt EQ.