Date: Tue, 27 Nov 2012 22:39:48 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: musl 0.9.8 released On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote: > All very good, and I don't think I've got any more to add... > > So I guess that leaves the subarches like so: > x86: i486, x86_64 i386 and x86_64 aren't subarchs of a common arch. They're completely independent ISAs and cannot share any code. > arm: arm(eb), armel > mips: mips(32), mipsel(32) > microblaze: microblaze > (What's the status of microblazeel/microblazele? configure looks not > to recognize it...) It should work aside from configure not recognizing it. But I don't think it's been tested. > ppc: powerpc(32) > > Total arches: > 6 > Total subarches (distinct ABIs): > 8-10 (depending on status of microblazeel and ABI compatability of > armhf with armel) > > -planned subarches: mipsel32-sf, mips32-sf My idea for the names would be something like: mips, mipsel, mips-sf, mipsel-sf, ... Basically, the full arch name would be something along the lines of: arch[el|eb][-abivariant] which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for asm files. But additional considerations need to be made for how the main arch dir with bits headers and internal headers would be selected. I don't think we want to duplicate entire arch trees for subarchs, but I also don't see how subarchs can get by with using the same set of headers unless we rely on the compiler to predefine macros that distinguish them. This is rather ugly but we're already partially relying on it for endianness varants. In the end, it might simply be the cleanest to just duplicate the trees, but use symlinks to eliminate most of the duplicate files. However, the interaction of that with install rules would have to be considered and the install rules might need revision. > -planned arches: x32 Yes. I think x32 (and mipsn32) probably need to be considered as separate archs, despite being the same ISAs as x86_64 (and mips64). > -distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got > these working, but they haven't been merged) Well, for a very limited definition of working. A majority of the actual *code* is done, but the headers were basically all just copies of the arm headers, meaning not much actually works. > -unsupported subarches: i386 ?? > It seems Debian's using aarch64-* for ARMv8. Yes, 64-bit arm is a new arch and it seems they used the name aarch64 instead of arm64 due to arm* being interpreted as 32-bit arm by many things.. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.