5 ms·

One of the interesting things about the ARM instruction set (at least in the Acorn era - not sure if this is still true of more recent ARM iterations) is that A

One of the interesting things about the ARM instruction set (at least in the Acorn era - not sure if this is still true of more recent ARM iterations) is that ALL instructions, not just branch, were conditional, which meant that you could avoid the need for branch instructions in some cases - rather than conditionally branch past some instructions, just make them conditional and "execute" them regardless. Smaller code and faster execution! The article cites Hermann pushing IBM's RISC approach, but as I recall (I worked at Acorn at the time) the inherently RISC-like simplicity of the 6502 that Acorn was using was itself part of the inspiration.

tadfisher 4y ago
I found this article that goes into a bit more detail about ARMv1's conditional instructions. http://www.righto.com/2016/01/conditional-instructions-in-arm1.html http://www.righto.com/2016/01/conditional-instructions-in-ar...
joezydeco 4y ago
The conditional execution was the key to making pipelining work back in those days. Modern processors do way way more to try and predict where branches will go and minimize breaking the pipeline flow.
rrss 4y ago
this (and the barrel shifter being available in all instructions) was at least partially due to the limitation mentioned in the article that the processor had no data or instruction cache. If single instructions could have these extra capabilities, the processor could do more work between stalling waiting to read the next instruction from memory.
fulafel 4y ago
It seems there was a reboot in the AAarch64 (aka 64-bit ARM), and the general predication was jettisoned. Along with some other traditional ARM characteristic features like loading / storing multiple registers with one instruction.
- TazeTSchnitzel 4y ago
  Loading and storing multiple registers is maybe most useful for loading a 64-bit value (e.g. double-precision floating-point) as two 32-bit pieces. Once you have direct 64-bit support it might be less useful?
  - borodi 4y ago
    LDP(load 2 registers) was switched in place of LDM, it seems that instructions that could touch so many registers at once made out of order/superscalar harder. source: https://community.arm.com/support-forums/f/architectures-and-processors-forum/3412/ldm-to-ltp-reason https://community.arm.com/support-forums/f/architectures-and...
  - adrian_b 4y ago
    Loading and storing multiple registers was mainly used in function prologues and epilogues, for saving and restoring the registers. If you have to save e.g. 10 registers, using 40 bytes of instructions on function entry and another 40 bytes of instructions on function exit is a lot of wasted code space. On Intel/AMD CPUs, the deprecation of the loading and storing of multiple registers (POPA and PUSHA) had less impact, because for pushing or popping a single register the length of an instruction is only 1 byte or 2 bytes, vs. 4 bytes on ARM. To alleviate somewhat the removal of the instructions that could load and store up to all registers, in AArch64 double load and double store instructions have been added to the ISA, which can load or store a pair of distinct registers.
    - PopePompus 4y ago
      Loading/storing multiple registers was also more important for the early ARM processors, because they had no cache at all, so storing or loading registers one at a time required multiple instructions to be fetched from off-chip RAM, tying up bus bandwidth and stalling the pipeline (such as it was).
  - monocasa 4y ago
    It's that it's a pain for precise exceptions. Handling how you get a page fault for ldm/stm and then restart them once the relevant page is loaded is non trivial.
chasil 4y ago
Conditional execution was explicitly removed from AArch64 to improve pipelining and branch prediction. It does decrease code density. The register had a much longer set of articles on the history of Acorn and ARM. I was hoping for new information in this Ars Technia piece, but it was scant. https://www.theregister.com/2012/05/03/unsung_heroes_of_tech_arm_creators_sophie_wilson_and_steve_furber/ https://www.theregister.com/2012/05/03/unsung_heroes_of_tech...
Turing_Machine 4y ago
"RISC-like" is a good term. The way the 6502 used Page 0 RAM effectively gave it 256 extra "registers". Not as fast as the real on-CPU registers, of course, but definitely faster than accessing a random byte of memory. Accessing arbitrary memory required a two byte address, but some instructions had a "page 0" form that let you access those addresses with only a one byte address, with page 0 assumed.
mijoharas 4y ago
I was speaking with Hermann about this article so asked him and he confirmed what you said: > I do not remember IBM featuring so prominently in our deliberations. Our starting point was a 16 bit version of the 6502.
- klelatti 4y ago
  I think it might have been Andy Hopper who pushed the RISC papers forward (IBM / Berkeley etc). There is an interesting interview with Hermann where he says that Acorn asked Intel for a special version of the 80286. I've always been puzzled by that given how weak the 286 was!
  - HarHarVeryFunny 4y ago
    > There is an interesting interview with Hermann where he says that Acorn asked Intel for a special version of the 80286 First I've heard of that. Did he give any details of what it was being considered for, or what special features were being asked for ?
    - klelatti 4y ago
      Said the team liked it but wanted address and data bus demultiplexed - but the 286 already has demultiplexed buses unlike the 8086. Maybe I misunderstood! It’s here I think: https://m.youtube.com/watch?v=w1HODsDGMzI https://m.youtube.com/watch?v=w1HODsDGMzI
      - HarHarVeryFunny 4y ago
        Thanks. Yeah, that doesn't sound quite right. There must have been some approach to Intel, but that particular complaint applies to the 8086 not the 286. There was certainly a big emphasis on memory bandwidth at Acorn. There's a video by Sophie Wilson (who I knew pre-Sophie - worked with her to reuse BBC BASIC floating point libary for ISO Pascal) describing how Acorn found that, across various process architectures being evaluated, performance was directly related to instruction fetch speed regardless of how that broke down in terms of clock speed, bus width or cycles per instruction. Acorn had of course been experimenting with most of the next-gen processors at the time, and put out a few in "2nd processor" form before a bit later repackaging them as the Acorn Business Computer series. There was actually a prototype 286-based version of the business computer, but by then the ARM was already being developed. I don't recall hearing anything about the 286 being evaluated by Acorn the time (I was there from 82-85). It's interesting that the 286 and Nat Semi 16032 both came out in '82, and Acorn chose to go with the 16032 as a 2nd processor (I still have one - did some work on PANOS) rather than the 286. Perhaps this is the time frame Hermann is talking about? The "If Intel hadn't rejected us, there'd have been no ARM" story it cute to make Intel look foolish, but it's not obvious that a 286 2nd processor would have curtailed ARM development anymore than the 16032 had.
shadowofneptune 4y ago
I struggle to see what is RISC-like about the 6502. 8-bit processors are usually too quirky to put into one of the categories. RISC hallmarks are: - Fixed-width encoding: No. It varies from one to three bytes. - Large register set: No, it's an accumulator architecture. I don't count the zero page because every program that ran on the computer had to use the same zero page. IIRC, user programs on some late-era 6502 OSes would have only a handful of those 256 bytes to work with, rest being claimed by the system software. - Pipelining: There's some optimization with prefetching of instructions. It is not the multi-step pipeline of RISC, nor does it need to be. - Load/store architecture: Plenty of instructions work directly on memory.
- HarHarVeryFunny 4y ago
  RISC wasn't even a thing when the 6502 was designed, but in terms of complexity it was definitely at the reduced/simple instruction set end of the spectrum, as evidenced by it's transistor count. I never had the conversation with Wilson/Furber, but I'm assuming that CISC was essentially off the table in the first place. Both had zero CPU design experience, so to have any hope for success it had to be simple. The 6502 provided plenty of validation that simple could be fast, and no-one at Acorn had been impressed with next-gen 16/32-bit CISC designs anyway. No doubt other early RISC designs were an influence, but I don't believe there was any RISC vs CISC religion involved. It's amusing how today's worldwide domination of the processor market by ARM is really based on design decisions that were born of necessity for a chip that was really targeted for desktop use. It had to be simple, hence the die was small and cheap. It had to use low cost plastic packaging, so it had to be low power to avoid overheating. Low cost and low power is what led to ARM's mobile success.
  - shadowofneptune 4y ago
    Just being simple in electronic design doesn't make it RISC, that makes the term useless. The PDP-8 shares a lot of similarities with the 6502, and in one implementation comes in at only 1409 transistors. If you look at what you need to do to write a program in it, it's anything but RISC in concept. A small set of operations is the least useful marker, the ones I gave above are common criteria.
Someone 4y ago
> One of the interesting things about the ARM instruction set […] is that ALL instructions, not just branch, were conditional, which meant that you could avoid the need for branch instructions in some cases - rather than conditionally branch past some instructions, just make them conditional and "execute" them regardless. Smaller code and faster execution! I think both can be debated. It took 4 bits out of each 32-bit instruction to specify those condition flags. That’s 12.5% of the bits in each instruction that could have been used for other stuff such as supporting more registers and larger immediate constants, both of which could speed up code. It was an interesting idea, though. Simple to implement and useful at times.

tadfisher 4y ago

I found this article that goes into a bit more detail about ARMv1's conditional instructions. http://www.righto.com/2016/01/conditional-instructions-in-arm1.html http://www.righto.com/2016/01/conditional-instructions-in-ar...

joezydeco 4y ago

The conditional execution was the key to making pipelining work back in those days. Modern processors do way way more to try and predict where branches will go and minimize breaking the pipeline flow.

rrss 4y ago

this (and the barrel shifter being available in all instructions) was at least partially due to the limitation mentioned in the article that the processor had no data or instruction cache. If single instructions could have these extra capabilities, the processor could do more work between stalling waiting to read the next instruction from memory.

fulafel 4y ago

It seems there was a reboot in the AAarch64 (aka 64-bit ARM), and the general predication was jettisoned. Along with some other traditional ARM characteristic features like loading / storing multiple registers with one instruction.

TazeTSchnitzel 4y ago
Loading and storing multiple registers is maybe most useful for loading a 64-bit value (e.g. double-precision floating-point) as two 32-bit pieces. Once you have direct 64-bit support it might be less useful?
- borodi 4y ago
  LDP(load 2 registers) was switched in place of LDM, it seems that instructions that could touch so many registers at once made out of order/superscalar harder. source: https://community.arm.com/support-forums/f/architectures-and-processors-forum/3412/ldm-to-ltp-reason https://community.arm.com/support-forums/f/architectures-and...
- adrian_b 4y ago
  Loading and storing multiple registers was mainly used in function prologues and epilogues, for saving and restoring the registers. If you have to save e.g. 10 registers, using 40 bytes of instructions on function entry and another 40 bytes of instructions on function exit is a lot of wasted code space. On Intel/AMD CPUs, the deprecation of the loading and storing of multiple registers (POPA and PUSHA) had less impact, because for pushing or popping a single register the length of an instruction is only 1 byte or 2 bytes, vs. 4 bytes on ARM. To alleviate somewhat the removal of the instructions that could load and store up to all registers, in AArch64 double load and double store instructions have been added to the ISA, which can load or store a pair of distinct registers.
  - PopePompus 4y ago
    Loading/storing multiple registers was also more important for the early ARM processors, because they had no cache at all, so storing or loading registers one at a time required multiple instructions to be fetched from off-chip RAM, tying up bus bandwidth and stalling the pipeline (such as it was).
- monocasa 4y ago
  It's that it's a pain for precise exceptions. Handling how you get a page fault for ldm/stm and then restart them once the relevant page is loaded is non trivial.

chasil 4y ago

Conditional execution was explicitly removed from AArch64 to improve pipelining and branch prediction. It does decrease code density. The register had a much longer set of articles on the history of Acorn and ARM. I was hoping for new information in this Ars Technia piece, but it was scant. https://www.theregister.com/2012/05/03/unsung_heroes_of_tech_arm_creators_sophie_wilson_and_steve_furber/ https://www.theregister.com/2012/05/03/unsung_heroes_of_tech...

Turing_Machine 4y ago

"RISC-like" is a good term. The way the 6502 used Page 0 RAM effectively gave it 256 extra "registers". Not as fast as the real on-CPU registers, of course, but definitely faster than accessing a random byte of memory. Accessing arbitrary memory required a two byte address, but some instructions had a "page 0" form that let you access those addresses with only a one byte address, with page 0 assumed.

mijoharas 4y ago

I was speaking with Hermann about this article so asked him and he confirmed what you said: > I do not remember IBM featuring so prominently in our deliberations. Our starting point was a 16 bit version of the 6502.

klelatti 4y ago
I think it might have been Andy Hopper who pushed the RISC papers forward (IBM / Berkeley etc). There is an interesting interview with Hermann where he says that Acorn asked Intel for a special version of the 80286. I've always been puzzled by that given how weak the 286 was!
- HarHarVeryFunny 4y ago
  > There is an interesting interview with Hermann where he says that Acorn asked Intel for a special version of the 80286 First I've heard of that. Did he give any details of what it was being considered for, or what special features were being asked for ?
  - klelatti 4y ago
    Said the team liked it but wanted address and data bus demultiplexed - but the 286 already has demultiplexed buses unlike the 8086. Maybe I misunderstood! It’s here I think: https://m.youtube.com/watch?v=w1HODsDGMzI https://m.youtube.com/watch?v=w1HODsDGMzI
    - HarHarVeryFunny 4y ago
      Thanks. Yeah, that doesn't sound quite right. There must have been some approach to Intel, but that particular complaint applies to the 8086 not the 286. There was certainly a big emphasis on memory bandwidth at Acorn. There's a video by Sophie Wilson (who I knew pre-Sophie - worked with her to reuse BBC BASIC floating point libary for ISO Pascal) describing how Acorn found that, across various process architectures being evaluated, performance was directly related to instruction fetch speed regardless of how that broke down in terms of clock speed, bus width or cycles per instruction. Acorn had of course been experimenting with most of the next-gen processors at the time, and put out a few in "2nd processor" form before a bit later repackaging them as the Acorn Business Computer series. There was actually a prototype 286-based version of the business computer, but by then the ARM was already being developed. I don't recall hearing anything about the 286 being evaluated by Acorn the time (I was there from 82-85). It's interesting that the 286 and Nat Semi 16032 both came out in '82, and Acorn chose to go with the 16032 as a 2nd processor (I still have one - did some work on PANOS) rather than the 286. Perhaps this is the time frame Hermann is talking about? The "If Intel hadn't rejected us, there'd have been no ARM" story it cute to make Intel look foolish, but it's not obvious that a 286 2nd processor would have curtailed ARM development anymore than the 16032 had.

shadowofneptune 4y ago

I struggle to see what is RISC-like about the 6502. 8-bit processors are usually too quirky to put into one of the categories. RISC hallmarks are: - Fixed-width encoding: No. It varies from one to three bytes. - Large register set: No, it's an accumulator architecture. I don't count the zero page because every program that ran on the computer had to use the same zero page. IIRC, user programs on some late-era 6502 OSes would have only a handful of those 256 bytes to work with, rest being claimed by the system software. - Pipelining: There's some optimization with prefetching of instructions. It is not the multi-step pipeline of RISC, nor does it need to be. - Load/store architecture: Plenty of instructions work directly on memory.

HarHarVeryFunny 4y ago
RISC wasn't even a thing when the 6502 was designed, but in terms of complexity it was definitely at the reduced/simple instruction set end of the spectrum, as evidenced by it's transistor count. I never had the conversation with Wilson/Furber, but I'm assuming that CISC was essentially off the table in the first place. Both had zero CPU design experience, so to have any hope for success it had to be simple. The 6502 provided plenty of validation that simple could be fast, and no-one at Acorn had been impressed with next-gen 16/32-bit CISC designs anyway. No doubt other early RISC designs were an influence, but I don't believe there was any RISC vs CISC religion involved. It's amusing how today's worldwide domination of the processor market by ARM is really based on design decisions that were born of necessity for a chip that was really targeted for desktop use. It had to be simple, hence the die was small and cheap. It had to use low cost plastic packaging, so it had to be low power to avoid overheating. Low cost and low power is what led to ARM's mobile success.
- shadowofneptune 4y ago
  Just being simple in electronic design doesn't make it RISC, that makes the term useless. The PDP-8 shares a lot of similarities with the 6502, and in one implementation comes in at only 1409 transistors. If you look at what you need to do to write a program in it, it's anything but RISC in concept. A small set of operations is the least useful marker, the ones I gave above are common criteria.

Someone 4y ago

> One of the interesting things about the ARM instruction set […] is that ALL instructions, not just branch, were conditional, which meant that you could avoid the need for branch instructions in some cases - rather than conditionally branch past some instructions, just make them conditional and "execute" them regardless. Smaller code and faster execution! I think both can be debated. It took 4 bits out of each 32-bit instruction to specify those condition flags. That’s 12.5% of the bits in each instruction that could have been used for other stuff such as supporting more registers and larger immediate constants, both of which could speed up code. It was an interesting idea, though. Simple to implement and useful at times.