Re: 64-bit lossage

[Ken Raeburn <raeburn@raeburn.org>]

Dave Love <d.love@dl.ac.uk> writes:
>> I'll try to get some builds done on them more often, but I'll note one
>> thing right off -- the m/alpha.h file breaks the USE_LISP_UNION_TYPE
>> code because it unconditionally redefines some of the macros for
>> picking apart an integer used as a Lisp_Object.
>
> Yes.  Why is that a problem in practice?  (Also, lisp.h doesn't always
> undef such things before re-defining them, with possible warning
> storms as a consequence.)

I'm using the Lisp union type to ensure we've got reasonable type
handling, that we're not confusing Lisp objects and actual integer
values we want to use.  In the current representation the bit patterns
are the same for non-negative integers, but if we ever want to be able
to change the representation -- not necessarily switching to Guile,
but perhaps moving the tag bits to the low bits that are always zero
in a properly aligned struct pointer -- we still need to fix all those
cases.

A necessary early step in the Guile work I want to do is to get the
ability to make such changes.  Even if we never switch to Guile, I
believe that ability is important to have.

From what I've seen so far, on all the platforms where the Lisp object
manipulation macros were redefined, there are probably better ways to
do it.  And sometimes the reason for the redefinition is just bogus;
for example, MARKBIT was redefined on the alpha because of some
problem with an #if test that as far as I can see, doesn't exist now.
Generally the macros duplicate values that lisp.h or config.h would've
selected anyways.

I could work on these changes without changing m/alpha.h; I just
couldn't work on them on the Alpha.

As far as Joe Random downloading and building Emacs, it's not directly
causing any problem at all, aside from those redefinition warnings.

>> I'd say the macros in lisp.h need revising to better support 64-bit
>> architectures;
>
> As far as I know, they currently work, but there are probably more
> serious 64-bit problems elsewhere unless someone has re-done what
> eggert and I both started on.
>
> Adding long long support (per TODO) seems most useful in that area.

On most (all?) of the 64-bit configurations I've worked on, "long" is
64 bits; "long long" is mostly interesting only if "long" isn't as big
as a pointer, or we really really want to store more information than
a pointer.  If we hit a platform where only "long long" is pointer
sized, yes, we'll need to use it.  But if the lisp-union code compiles
without complaint, I bet "long long" can be made to work quite easily.

Ken

P.S.  I'm running an Emacs binary right now that was built to use a
union for a Lisp_Object, compiled for x86.  Most of what I'm doing is
interactive, but I haven't noticed any performance issues.  I did one
timing test with "make autoloads", and out of about four minutes of
CPU time, the "union" version was slower by about five seconds.
That's probably doing lots of searching in the regexp code;
byte-compiling might be a better test case to look for worst-case
results, but I haven't tried it yet.