svn commit: r217147 - in head/sys: amd64/include arm/include i386/include ia64/include mips/include powerpc/include sparc64/include sun4v/include

[Warner Losh]

On 01/09/2011 07:45, Tijl Coosemans wrote:
> My main goal is to compile 32 bit code on amd64. To do that i386 and
> amd64 headers need to be merged as much as possible and I'm looking at
> mips and powerpc headers as examples. As I'm going through each of the
> machine headers however and as people review my patches several issues
> have come up. These are mostly generic in nature and spread over all
> architectures, not just mips. There are more problems in the mips and
> powerpc headers however because of the complexity of supporting both 32
> bit and 64 bit ABIs. If you consider the mips headers too delicate to
> be changed without approval from mips@ I'll make sure to send patches
> there before committing from now on.

Please do so.  Mips' ABIs are complex enough for the experts to 
understand the subtle implications of, let alone someone who thinks they 
behave exactly like all the other APIs out there.  While the assumption 
that they are the same is generally true, it isn't universally true 
since n32 makes a hash of a lot of assumptions around the edges.

> As for 64 bit longs on 32 bit ABIs I would advise against spending your
> time on that. It's something that sounds nice in theory, but it's just
> not practical. You don't gain anything from it because there's another
> 64 bit type already (long long) and there's too much code out there
> that relies on long and pointer types having the same size or that
> assumes long is different between 32 bit and 64 bit ABIs, also in our
> own tree. So yes, in practice there's only ILP32 and LP64 and nothing
> in between.

Except n32 is only mostly ILP32, not totally ILP32.  ILP32 tends to 
imply, for example, 32-bit registers.  I've had to fix some code in the 
tree that assumed ILP32 meant 32-bit registers and LP64 meant 64-bit 
registers.  Hence my comments above about n32 being an oddball.  Same 
goes for stack alignment: n32 has 64-bit stack alignment, while o32 (and 
most other ILP32 ABIs) have only 32-bit stack alignment requirements.

> About the use of __LP64__. It's essentially cosmetic and can easily be
> changed back. However, if you can agree with me on mlong64 I would like
> to keep it (for type definitions). What the patches (committed +
> upcoming) show is that _inttypes.h, _limits.h and _stdint.h (_types.h
> needs more work) are exactly the same for mips, powerpc and x86
> indicating that they aren't architecture specific. Changing __LP64__
> back to __mips_n64 would introduce a difference that isn't any.

Please change it back for now.  The n32 support in the tree is mostly 
complete, but still has a few issues that I'm trying to iron out with 
Juli.  Having more churn in this area makes it more difficult to sort 
things out (and patch if things are actually wrong).


> Moreover, those headers would also work on pure ILP32 (arm) and LP64
> (ia64, sparc64) architectures, so personally I would like to move them
> to sys/, because as the patches show, duplicated code starts to
> diverge, bugs creep in and are subsequently copy-pasted. Whenever I
> suggested this to someone however I never really got a positive
> response so the headers will stay under machine/ for now. I would still
> like to get a clear yes or no on this though.

Create a sys/_foo.h.  Have all those architectures include it.  That 
gives you the best of both worlds: for those that can use the standard 
foo.h, we provide one.  For the oddballs, or ones where the standard one 
doesn't match the warts of history or current innovation, they can be 
overriden to cope.

Warner