Re: 64-bit lossage

[Ken Raeburn <raeburn@raeburn.org>]

Dave Love <d.love@dl.ac.uk> writes:
>> Which OS are you using on the Alpha?
> Tru64 5.1a, but I doubt that matters.  Irix64 does just that same.

I don't think I've got access to an Irix64 system to test with; I'm
fairly sure all the ones I've got access to are 32-bit only.  But
you're probably using irix5-0.h (which gets included by irix6-5.h and
others), which also turns on the mmap code.

>> On the 5.1 machine I've got at work, with a source tree I've already
>> started banging on for some of the lisp implementation issues I was
>> complaining about recently,
> What issues?

Per-machine definitions of macros dependent on low-level details of
the lisp implementation.  It's cleaner if the lisp implementation is
based on information about the architecture, and not partially
rewritten for some architectures.

The macros as they stand in lisp.h do appear to be fairly clean for
64-bit support.  They assume that "long" will be 64 bits when pointers
are, and that "_LP64" is defined in that case, but switching to "long
long" if "long" isn't big enough should actually be quite easy.

> Yes -- I read this too late -- but what has changed in that area since
> 21.2?

I think the make_gap_smaller code is new on the trunk since the
current release branch was started; that's what caused mmap_realloc to
be called to unmap some pages.  I want to look a bit more closely,
though, and see if there are other cases that could cause similar
problems on the release branch.

> Yes, see etc/TODO.  See cc(1) for how to disable specific warnings,
> e.g. `-msg_disable ptrmismatch1,promotmatchw', which I have currently.

Thanks, I'll try those.

> I mostly used gcc to find such problems, though, and the result is the
> same as with cc currently.  [The Compaq compiler supports some gcc
> extensions, so testing __GNUC__ may not be optimal.]

>> My problem showed up in some buffer manipulation code, so maybe it's
>> not the same problem.  But like I said, I've already started making
>> other changes in my tree....  Could you try the patch below?
> What problem is it trying to solve?  I don't understand.  It doesn't
> fix Tru64 or affect Solaris, Irix.

It wasn't trying to fix one problem.  The patches I had in progress
made the problem disappear for me; I wanted to know if they were
sufficient for you or if you were seeing a different problem.

The other patch I sent, to fix the computed number of pages to unmap,
should've fixed this specific problem, and across multiple platforms.
The other Alpha-specific changes shouldn't have had any impact in this
area, but when I sent them to you I was still not quite certain of
that.

Ken