8 ms·

ARM Goes 64-bit

123 points by enos_feedler 14y ago

ajross 14y ago
It's interesting to see a very x86_64-like attempt to shake off the weirdness of the ancestral architecture here. The PC is no longer an addressable register. Thumb has been dropped. The predication bits are no more. The weird register aliasing thing done by NEON is gone too. The register banking (and it seems most of the interrupt architecture) is entirely different. And, just like in the Intel world, market pressures have introduced all new CISC quirks: AES and SHA256 instructions, for example. But of course an architecture document does not a circuit make. All the weirdness (old and new) needs to be supported for compatibility (OK, maybe they can drop Jazelle), so the fact that they no longer talk about some things doesn't really save them any transistors in practice. Honestly, this is sounding more like an Intel or AMD part, not less.
- enos_feedler 14y ago
  Yes, its too bad cleaning up the architecture doesn't necessarily cleanup the physical design. As GPUs have been more recent entrants to the general purpose space it is clear they are trying to avoid the same mistakes. The only place you will find a a true GPU binary is buried deep in the memory of the runtime stack (for NVIDIA at least, not sure about AMD).
  - ajross 14y ago
    Right. My understanding is that NVIDIA has mucked around with their low level instructions at every iteration. I remember reading somewhere that with Kepler the hardware doesn't even have dependency interlocks -- the compiler is responsible for scheduling instructions such that they don't use results that aren't ready yet. But at the same time the lack of a clear specification and backwards compatibility means that the software stack needs to deal with all new bugs (both hardware and software) at every iteration. That puts a IMHO pretty firm cap on the "asymptotic quality" of the stack -- you're constantly chasing bugs until the new version comes out. So you'll never see a GPU toolchain of the quality we expect from gcc (or LLVM, though that isn't quite as mature).
- pjscott 14y ago
  Is having hardware acceleration for AES and SHA256 really a "CISC quirk", or just a really specialized set of arithmetic instructions? The classic RISC idea of making the core simple and fast doesn't really apply here; internally, it's all simple micro-operations driving special-purpose hardware. It seems similar to having a fused multiply-accumulate operation: they've figured out how to accelerate the core of a common task, and this is the API they've decided to give it.
  - enos_feedler 14y ago
    most likely for energy-efficiency reasons.
  - simcop2387 14y ago
    That's actually an almost reasonable definition of CISC for laypeople. Take a look at the definition on wikipedia. A complex instruction set computer (CISC, play /ˈsɪsk/) is a computer where single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) and/or are capable of multi-step operations or addressing modes within single instructions. Now the reality is that on the whole things are not quite as cut and dry. In this case they're doing it to give access to dedicated hardware for power gains most likely, which is why something that's typically close to RISC would add something like that. As time has gone on, both CISC and RISC systems have moved more toward a blend of both in-order to get the best of both worlds, from what i've heard interally most x86 chips actually work like a risc chip they just translate between things in the instruction decoder.
    - anamax 14y ago
      > A complex instruction set computer (CISC, play /ˈsɪsk/) > is a computer where single instructions ... and/or are > capable of multi-step operations ... within single > instructions. What's a "multi-step operation"? I ask because I worked on the microarchitecture (read "implementation") of a microprocessor that had what was generally regarded as a very RISC instruction set. Yet, almost every instruction had multiple steps. Yes, including integer add. Were we doing something wrong? And no, "one cycle fundamental operations" doesn't change things. Dividing things into cycles is a design choice. For example, one might reasonably do integer adds in two steps.
- deleted 14y ago
  [deleted]
klodolph 14y ago
> The one surprise in ARMv8, is the omission of any explicit support for multi-threading. Nearly every other major architecture, x86, MIPS, SPARC, and Power has support for multi-threading and at least one or two multi-threaded implementations. What does this even mean? Are they talking about atomic operations? Hyperthreading?
- enos_feedler 14y ago
  I think they are talking in the hardware sense: hyperthreading/SMT
  - duaneb 14y ago
    How much does that actually help? In my extremely fuzzy memory, it only worked out to around a 30% increase in ideal situations. I'd rather see them work on features that can be exploited with less voodoo.... like hardware 64-bit support, or SIMD support, or HTM, or hell, clock rate.
    - tedunangst 14y ago
      But it's 30% you get for basically free. I kind of thought HT was mostly a gimmick (look, now with 256 virtual CPUs), but changed my mind since it doesn't cost anything (in terms of die space) to add it to a chip. 30% more performance for 1% more cost is a better deal than 100% more performance for 100% more cost, assuming you can live with only 30% more performance. I should add I think what AMD is doing with Bulldozer (claiming two virtual cores are actually full cores) is bullshit.
      - duaneb 14y ago
        > I should add I think what AMD is doing with Bulldozer (claiming two virtual cores are actually full cores) is bullshit. I think AMD is doing whatever it can to get people to buy its CPUs. If it weren't for their ATI purchase, I think they'd be basically dead by now. It still amazes me how far they've fallen: I built my first computer with an AMD X2 when I was 15 (6 years ago now) - they looked like they were going to upset Intel as deciding the future of x86 chips. They did for a while - we got a sane 64-bit architecture out of it. I'm not sure where they went wrong: was it marketing, was it manufacturing tech, was it profit margins, was it Apple? I don't even know if their current processors are competitive or not in the performance market - things like "Bulldozer" make me think not. Anyway, could SMT be implemented on top of ARM v8? My knowledge of hardware doesn't include multithreading. However, from my limited understanding of it, I don't see SMT making much difference in tight RISC code, which is designed to have a high instruction throughput per cycle, leaving little for instruction reordering to optimize.
rblackwater 14y ago
It looks like an interesting article, so it is a shame that it was split into 5 pages with no way to view everything on one page. I have no recourse but to not read the article at all.
- smashing 14y ago
  The article is hyperthreaded so you can read all five pages at once if your brain supports that kind of instruction set.
  - rblackwater 14y ago
    If only :/ I don't even have an FPU.
  - raverbashing 14y ago
    Yes too bad there's a 'fence' missing between each page Or you'll just reread every page until everything makes sense since you can read things very fast for marketing purposes
- dangrossman 14y ago
  > I have no recourse but to not read the article at all You could click the next button 4 times and read the full article. There's lots of content on each page. It would've taken 100% less typing than this complaint, and you would've spent that time learning instead of grumbling. It's a real shame you can't read books either. Whole libraries of documents split into pages with no "view all" button.
  - rblackwater 14y ago
    There's a big difference in turning a page the size of your hand when you are already holding the book and trying to click a micro button the size of a word when you use the arrow keys to move the browser window. I'll just wait until the exact same information appears on a single page. I was expressing sincere regret because I liked the first page, but I absolutely will not read paginated articles. Also: you're obviously irritated by my grumbling, but grumbling about it is just a massive load of hypocrisy, so please realize I'm not going to be taking any of your comments all that seriously.
rogerbinns 14y ago
I wonder if it is possible to make the CPU be 64 bit only, and how much die space/power it would save by not including the 32 but cruft. I'd also be curious if it was possible to software translate 32 bit arm binaries into 64 bit while retaining comparable performance.
lunarscape 14y ago
Honest question since I'm confused about terminology: Why is ARMv8 described in places as "backwards compatibility for existing 32-bit software" when some existing instructions will be removed in AArch64?
- Symmetry 14y ago
  Because the ARM front end is so simple, it isn't hard to have multiple ones. One of these will be able to run existing 32-bit software.
Symmetry 14y ago
A question about how HN works. I'd submitted the same article to HN at a much less opertune time so it fell off the "new" page before it got its first upvotes. [1] Normally when somebody then resubmits the same article at a better time I thought they had to add a '~' at the end of the URL or something, but I don't see anything like that in this case. So how'd they do it? (And I should say I'm glad that you all get to see this article, so thank you enos_feedler). [1]http://news.ycombinator.com/item?id=4380604 http://news.ycombinator.com/item?id=4380604
- parenthesis 14y ago
  This submission has url http://www.realworldtech.com/arm64 http://www.realworldtech.com/arm64, yours has http://www.realworldtech.com/arm64/ http://www.realworldtech.com/arm64/.
- vdondeti 14y ago
  Note that the article you submitted has a trailing /, this submission doesn't and so was not detected by HN as a duplicate story - or so it seems.

123 points by enos_feedler 14y ago

It's interesting to see a very x86_64-like attempt to shake off the weirdness of the ancestral architecture here. The PC is no longer an addressable register. Thumb has been dropped. The predication bits are no more. The weird register aliasing thing done by NEON is gone too. The register banking (and it seems most of the interrupt architecture) is entirely different. And, just like in the Intel world, market pressures have introduced all new CISC quirks: AES and SHA256 instructions, for example. But of course an architecture document does not a circuit make. All the weirdness (old and new) needs to be supported for compatibility (OK, maybe they can drop Jazelle), so the fact that they no longer talk about some things doesn't really save them any transistors in practice. Honestly, this is sounding more like an Intel or AMD part, not less.

enos_feedler 14y ago
Yes, its too bad cleaning up the architecture doesn't necessarily cleanup the physical design. As GPUs have been more recent entrants to the general purpose space it is clear they are trying to avoid the same mistakes. The only place you will find a a true GPU binary is buried deep in the memory of the runtime stack (for NVIDIA at least, not sure about AMD).
- ajross 14y ago
  Right. My understanding is that NVIDIA has mucked around with their low level instructions at every iteration. I remember reading somewhere that with Kepler the hardware doesn't even have dependency interlocks -- the compiler is responsible for scheduling instructions such that they don't use results that aren't ready yet. But at the same time the lack of a clear specification and backwards compatibility means that the software stack needs to deal with all new bugs (both hardware and software) at every iteration. That puts a IMHO pretty firm cap on the "asymptotic quality" of the stack -- you're constantly chasing bugs until the new version comes out. So you'll never see a GPU toolchain of the quality we expect from gcc (or LLVM, though that isn't quite as mature).
pjscott 14y ago
Is having hardware acceleration for AES and SHA256 really a "CISC quirk", or just a really specialized set of arithmetic instructions? The classic RISC idea of making the core simple and fast doesn't really apply here; internally, it's all simple micro-operations driving special-purpose hardware. It seems similar to having a fused multiply-accumulate operation: they've figured out how to accelerate the core of a common task, and this is the API they've decided to give it.
- enos_feedler 14y ago
  most likely for energy-efficiency reasons.
- simcop2387 14y ago
  That's actually an almost reasonable definition of CISC for laypeople. Take a look at the definition on wikipedia. A complex instruction set computer (CISC, play /ˈsɪsk/) is a computer where single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) and/or are capable of multi-step operations or addressing modes within single instructions. Now the reality is that on the whole things are not quite as cut and dry. In this case they're doing it to give access to dedicated hardware for power gains most likely, which is why something that's typically close to RISC would add something like that. As time has gone on, both CISC and RISC systems have moved more toward a blend of both in-order to get the best of both worlds, from what i've heard interally most x86 chips actually work like a risc chip they just translate between things in the instruction decoder.
  - anamax 14y ago
    > A complex instruction set computer (CISC, play /ˈsɪsk/) > is a computer where single instructions ... and/or are > capable of multi-step operations ... within single > instructions. What's a "multi-step operation"? I ask because I worked on the microarchitecture (read "implementation") of a microprocessor that had what was generally regarded as a very RISC instruction set. Yet, almost every instruction had multiple steps. Yes, including integer add. Were we doing something wrong? And no, "one cycle fundamental operations" doesn't change things. Dividing things into cycles is a design choice. For example, one might reasonably do integer adds in two steps.
deleted 14y ago
[deleted]

klodolph 14y ago

> The one surprise in ARMv8, is the omission of any explicit support for multi-threading. Nearly every other major architecture, x86, MIPS, SPARC, and Power has support for multi-threading and at least one or two multi-threaded implementations. What does this even mean? Are they talking about atomic operations? Hyperthreading?

enos_feedler 14y ago
I think they are talking in the hardware sense: hyperthreading/SMT
- duaneb 14y ago
  How much does that actually help? In my extremely fuzzy memory, it only worked out to around a 30% increase in ideal situations. I'd rather see them work on features that can be exploited with less voodoo.... like hardware 64-bit support, or SIMD support, or HTM, or hell, clock rate.
  - tedunangst 14y ago
    But it's 30% you get for basically free. I kind of thought HT was mostly a gimmick (look, now with 256 virtual CPUs), but changed my mind since it doesn't cost anything (in terms of die space) to add it to a chip. 30% more performance for 1% more cost is a better deal than 100% more performance for 100% more cost, assuming you can live with only 30% more performance. I should add I think what AMD is doing with Bulldozer (claiming two virtual cores are actually full cores) is bullshit.
    - duaneb 14y ago
      > I should add I think what AMD is doing with Bulldozer (claiming two virtual cores are actually full cores) is bullshit. I think AMD is doing whatever it can to get people to buy its CPUs. If it weren't for their ATI purchase, I think they'd be basically dead by now. It still amazes me how far they've fallen: I built my first computer with an AMD X2 when I was 15 (6 years ago now) - they looked like they were going to upset Intel as deciding the future of x86 chips. They did for a while - we got a sane 64-bit architecture out of it. I'm not sure where they went wrong: was it marketing, was it manufacturing tech, was it profit margins, was it Apple? I don't even know if their current processors are competitive or not in the performance market - things like "Bulldozer" make me think not. Anyway, could SMT be implemented on top of ARM v8? My knowledge of hardware doesn't include multithreading. However, from my limited understanding of it, I don't see SMT making much difference in tight RISC code, which is designed to have a high instruction throughput per cycle, leaving little for instruction reordering to optimize.

rblackwater 14y ago

It looks like an interesting article, so it is a shame that it was split into 5 pages with no way to view everything on one page. I have no recourse but to not read the article at all.

smashing 14y ago
The article is hyperthreaded so you can read all five pages at once if your brain supports that kind of instruction set.
- rblackwater 14y ago
  If only :/ I don't even have an FPU.
- raverbashing 14y ago
  Yes too bad there's a 'fence' missing between each page Or you'll just reread every page until everything makes sense since you can read things very fast for marketing purposes
dangrossman 14y ago
> I have no recourse but to not read the article at all You could click the next button 4 times and read the full article. There's lots of content on each page. It would've taken 100% less typing than this complaint, and you would've spent that time learning instead of grumbling. It's a real shame you can't read books either. Whole libraries of documents split into pages with no "view all" button.
- rblackwater 14y ago
  There's a big difference in turning a page the size of your hand when you are already holding the book and trying to click a micro button the size of a word when you use the arrow keys to move the browser window. I'll just wait until the exact same information appears on a single page. I was expressing sincere regret because I liked the first page, but I absolutely will not read paginated articles. Also: you're obviously irritated by my grumbling, but grumbling about it is just a massive load of hypocrisy, so please realize I'm not going to be taking any of your comments all that seriously.

rogerbinns 14y ago

I wonder if it is possible to make the CPU be 64 bit only, and how much die space/power it would save by not including the 32 but cruft. I'd also be curious if it was possible to software translate 32 bit arm binaries into 64 bit while retaining comparable performance.

lunarscape 14y ago

Honest question since I'm confused about terminology: Why is ARMv8 described in places as "backwards compatibility for existing 32-bit software" when some existing instructions will be removed in AArch64?

Symmetry 14y ago
Because the ARM front end is so simple, it isn't hard to have multiple ones. One of these will be able to run existing 32-bit software.

Symmetry 14y ago

A question about how HN works. I'd submitted the same article to HN at a much less opertune time so it fell off the "new" page before it got its first upvotes. [1] Normally when somebody then resubmits the same article at a better time I thought they had to add a '~' at the end of the URL or something, but I don't see anything like that in this case. So how'd they do it? (And I should say I'm glad that you all get to see this article, so thank you enos_feedler). [1]http://news.ycombinator.com/item?id=4380604 http://news.ycombinator.com/item?id=4380604

parenthesis 14y ago
This submission has url http://www.realworldtech.com/arm64 http://www.realworldtech.com/arm64, yours has http://www.realworldtech.com/arm64/ http://www.realworldtech.com/arm64/.
vdondeti 14y ago
Note that the article you submitted has a trailing /, this submission doesn't and so was not detected by HN as a duplicate story - or so it seems.