|From:||Jon Masters <jcm-AT-redhat.com>|
|To:||Jan Engelhardt <jengelh-AT-inai.de>|
|Subject:||Re: [PATCH 00/36] AArch64 Linux kernel port|
|Date:||Sun, 08 Jul 2012 19:32:01 -0400|
|Cc:||Arnd Bergmann <arnd-AT-arndb.de>, Olof Johansson <olof-AT-lixom.net>, Catalin Marinas <catalin.marinas-AT-arm.com>, linux-kernel-AT-vger.kernel.org|
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. Jon.
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds