Hacker News Reader

Comment by HarHarVeryFunny | Hacker News Reader

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.

View on HN

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...

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.

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.

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.

Sure, but RISC vs CISC is at heart just a design trade off. Once you've decided (or been forced by pragmatisim) to go with a "simple but fast" instruction set then design choices like large register set and load-store architecture (to keep instruction set small and orthogonal) are all obvious choices, and don't need to have come from some rulebook of RISC design principles.

All I'm saying is that I heard at the time that the well-liked 6502 was a source of inspiration for the design (and someone else has noted Hermann also remembering something similar), notwithstanding that there was no doubt much borrowing from the contemporary (UC Berkeley, Stanford) RISC designs as well.

As a 6502 programmer the utility of zero page variables is pretty obvious and there is a parallel there to a large register bank.. Maybe the 6502 wasn't "RISC like" in sense of incorporating what would become RISC design principles (it was too primitive for that), but it certainly validated a KISS design approach, just as contemporary next-gen CISC designs did nothing in Acorn's eyes to sell that approach. Back at that time we were all just seeing/discovering what was possible, and I'd have to guess that the ARM instruction set was more pragmatic than dogmatic - a combination of what seemed desireable, appeared reasonable to implement, and performed well in simulation.

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.

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!

> 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 ?

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

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.

Thanks so much for coming back. I wondered if I was missing something in what Hermann was saying!

It must have been interesting to work with Sophie. I remember looking at some disassembly of the BBC Basic 6502 code and being fascinated by how she got such good performance out of it.

Does your 16032 still work? Must be fairly rare if it does!

I was at the Uni at the time ARM was launched. Remember going to a University Computer Society meeting where I think (my memory is a bit vague at this point) Steve Furber presented the first Arm. No one could quite believe what they'd done.

I'm working on a series of articles for my blog on the early days of RISC. Comparing with the other RISC architectures it's really interesting how they differ. I think Sophie / Steve did a fantastic job of turning RISC into a practical and cost effective reality. I've just had a twitter conversation with Ben Finn (of Sibelius music software fame) who was saying how pleasant writing ARM assembly was!

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.

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?

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...

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.

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).

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.

Don't they still have to handle that for the remaining "load 2" instructions?

No, a single 128bit load/store even if it addresses two registers is way easier to handle than dumping a variable amount of your whole register file in a single instruction.

That's why the ARM1 had a microcode engine for LDM/STM despite having 'RISC' as the center letter in it's initialism.

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.

"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.

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-ar...

> 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.

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.

Reply on news.ycombinator.com