Tom Rini <tr...@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 <feng...@phytium.com.cn> writes: >>>> >>>>>> FengHua <feng...@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. -- Måns Rullgård m...@mansr.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot