[U-Boot] merge arm64 to arm

[Scott Wood]

On Mon, 2013-08-19 at 18:33 +0100, Måns Rullgård wrote:
> Scott Wood <scottwood at freescale.com> writes:
> 
> > On Mon, 2013-08-19 at 09:10 -0400, Tom Rini wrote:
> >> On 08/19/2013 09:01 AM, Måns Rullgård wrote:
> >> > Tom Rini <trini at ti.com> writes:
> >> > 
> >> >> On 08/19/2013 08:32 AM, Måns Rullgård wrote:
> >> >>> 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".
> >> > 
> >> > Why does it matter which company designed it?  By that reasoning,
> >> > you'd put i960 (were it supported) under arch/x86 because it's from
> >> > Intel.
> >> 
> >> Probably because I didn't get the "it's a whole new unrelated to
> >> everything before world over there!" memo.
> >
> > Probably because there is still quite a bit of similarity to older ARM.
> > There's more to it than just the ISA, and even that isn't *that* much
> > more different than x86 versus x86_64.
> 
> It is quite a bit more different.  32-bit x86 is a subset of x86_64

It is not completely a subset.  Various segmentation features, some
obscure instructions, vm86 mode, etc. were dropped.

> where as arm64 is entirely new, if somewhat inspired by 32-bit arm.

It appears heavily inspired to me.

> > i960 is a bad analogy.  It's often possible to turn arm32 asm into
> > arm64 asm with some search and replace and minor manual fixups.
> 
> Only if the original uses none of the distinguishing features of ARM
> like predicated instructions or variably shifted operands.

I'm referring specifically to the experience we had in doing this for
arm64 asm code in U-Boot, which uses these infrequently enough that it
falls under "minor manual fixups".

> Once you limit yourself to the remaining basic operations, every (RISC)
> architecture looks the same.

Some are more "the same" than others. :-P

Converting to sparc, ppc, or mips code would have been much more of a
manual process.

In any case, just how similar the asm is isn't really relevant - they're
different enough that we'd keep the 64-bit asm in separate files (this
is true of x86/x86-64 as well).

> >>   Seriously tho, our
> >> directory structure is different from the kernel and it seems like
> >> things might look cleaner this way.  If it doesn't, well, I'll admit
> >> to being wrong and we'll go back to a split arch directory.
> >
> > As I noted before, in Linux a bunch of other architectures started with
> > a separate arch for 64-bit (x86, sparc, ppc...), and all of them
> > eventually merged.
> 
> In those cases, the 64-bitness is merely an extension to the 32-bit
> instruction set.  Most of them don't even have a notion of 32-bit vs
> 64-bit mode of execution.
> 
> AArch64 of course shares certain non-ISA aspects with AArch32.  Page
> table formats and other architecturally defined system control features
> are the same, and code for managing these things should of course be
> shared.  Some other features, e.g. exception handling, are different
> enough that sharing code is probably difficult.

In the patches posted so far nothing is shared.  Using the same arch
directory will lead to these things being shared by default, and we only
need to fix up the places where things differ.  If some day we manage to
move enough stuff out of arch that it's really mostly just asm code,
with things like page table handling moved out to a place that is easily
shared between arches, then it might make sense to split.  We're a long
way from that, though.

-Scott