|| ||Jon Masters <jcm-AT-redhat.com> |
|| ||Jan Engelhardt <jengelh-AT-inai.de> |
|| ||Re: [PATCH 00/36] AArch64 Linux kernel port |
|| ||Sun, 08 Jul 2012 19:32:01 -0400|
|| ||Arnd Bergmann <arnd-AT-arndb.de>, Olof Johansson <olof-AT-lixom.net>,
Catalin Marinas <catalin.marinas-AT-arm.com>,
|| ||Article, Thread
On 07/08/2012 04:31 PM, Jan Engelhardt wrote:
> On Sunday 2012-07-08 09:54, Jon Masters wrote:
>> FWIW I actually really like the aarch64 name (but you know that already
>> :) ). I think it clearly spells out that this is not just a 64-bit
>> extension to the existing 32-bit ARM Architecture, it is a new (inspired
>> by ARM) architecture.
> IA64 also has a "arch" inside, and look where it took them.
> (The contemporary platform winner came to be x86_64 instead
> of what Intel had hoped back then.)
There is a difference here. Treading carefully to avoid upsetting
anyone, but IA64 was a complete departure in many ways from x86, whereas
AMD had something that was backward compatible more directly, and the
market reacted. In this case, it's different because of many different
things - an ARMv8 processor will also be a great ARMv7 processor (albeit
a few things nobody ever used are deprecated, but still supported), the
makeup of the existing market (ARM doesn't need a 30 year backward
compatibility story on the desktop or server and mobile platforms have
moved on to higher level stacks), the dynamics of the licensing model,
and the fact that compiled code is less relevant. I would say let's not
draw too many comparisons with x86/IA64/x86_64.
AArch64 is not a complete departure for ARM. It's a 32-bit wide RISC
instruction set that is very clean and draws on industry lessons from
the past several decades to fix (AFAICS) pretty much anything that was
really wrong with A32/T32 (ARM). They already did a lot in ARMv7 in
terms of deprecating older features, but it's nice (from an
implementation point of view) to have a chance to remove things that no
longer make sense - like many conditional instructions, modelling real
world software to optimize the encoding formats, etc. - and clean up
stuff like explicit knowledge of the pipeline depth of ten years ago.
I am very keen on the opportunity here for things like a single zImage
and a standardized platform on day one. By the time the first hardware
ships, I'm hoping that we've got a nice set of standards that everyone
can follow - all things that are needed to do AArch64 in bigger systems.
to post comments)