[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
