-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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...) and we want to avoid massive duplication of all of the C code that really won't change.
- -- Tom