svn commit: r217147 - in head/sys: amd64/include arm/include
i386/include ia64/include mips/include powerpc/include sparc64/include
imp at bsdimp.com
Mon Jan 10 16:23:34 UTC 2011
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.
More information about the svn-src-head