-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/19/2013 08:32 AM, Måns Rullgård wrote:
Tom Rini trini@ti.com writes:
On 08/18/2013 11:46 PM, Sharma Bhupesh-B45370 wrote:
[Re-posting as original msg was rejected due to HTML content..]
FengHua fenghua@phytium.com.cn writes:
> FengHua fenghua@phytium.com.cn writes: > >> hi tom, hi albert, yes, it's right. the u-boot could >> be more uniformly and maintainable if merging armv8 >> to arm architecture. I will try to migrate arm64 to >> armv8 subarchitecture of arm. do you have any other >> advice? > > Why? The architectures are vastly different, arm64 > (aarch64) being only loosely inspired by the 32-bit > arm. It is not like with x86/amd64 where a lot of code > can be shared.
Of course, with a seperated architecture the arm64 code will be clear and simple. when it merged with arm a few file should be duplicated with the name "_v8" appended and many macro switch should be added. but most of the code will be in armv8 directory which paralleled with armv7. it seems that this implementation are more nice.
ARMv8 defines both a 32-bit (aarch32) and a 64-bit (aarch64) instruction set. The naming you are suggesting would be misleading.
aarch32 state is compatible with armv7. armv8 directory only provide aarch64 state support. as you said, it would be a little misleading.
ARMv8 ARM (Architecture Reference Manual) mentions that the ARMv8 architecture has support for both AArch32 and AArch64 and the ARM can switch b/w the two instruction sets via exceptions.
So, whether choosing a naming convention similar to linux (arch/arm64) would be more suitable is something to consider (even though some of the files might be a copy of what is available in arch/arm/cpu/armv7)?
I think we'll see what happens with a single directory first. We aren't talking about a binary that has to work on all cases (right now...)
A single binary can obviously never work.
and we want to avoid massive duplication of all of the C code that really won't change.
If there's a lot of code shared between these architectures, why is it in an architecture-specific directory in the first place? Maybe the proper solution is to move it out of arch/arm rather than moving code for an entirely different architecture in there.
We are working in that direction (and one of the requests was to hook into that code, rather than duplicate things). Think of it as "all ARM Ltd licensed cores" not "all 32bit-only ARM cores".
And maybe it's a little bit of OSS thickheadedness, but looking over the parts of the code that aren't in the armv8 directory already we have a lot of "re-use asm-generic file" and "maybe slightly tweak the existing arm file slightly".
- -- Tom