The ARM-1, an early 32-bit RISC CPU, was used in the Acorn Archimedes computers, released in 1987. Its rated speed was one 32-bit instruction per cycle at 8 MHz.

Typical RAM chips at that time would have been 41256 at 150 ns, and as I understand it from the answer to How long would a 41256 take to do 4 accesses in fast page mode? the actual random-access time to such chips is 260 ns, which means if every instruction involved a random access, the maximum speed would be less than 4 MHz. On the other hand, access in fast page mode is considerably faster; I get the impression ARM-1 took advantage of that.

What exactly did the ARM-1 do about accessing memory quickly enough?

  • 1
    It's also usually retold that Acorn's primary evaluation criteria for new chips was optimal use of memory bandwidth, and that the ARM was designed to excel at that measure. Which makes the question more interesting.
    – Tommy
    Feb 21, 2020 at 16:45
  • 5
    The Ultimate Acorn Archimedes Talk scheds some light on this.
    – fuz
    Feb 21, 2020 at 17:40
  • 3
    The Archimedes range initially used ARM2. Feb 25, 2020 at 14:05
  • 1
    Yep, the first computer to use an ARM processor was the BBC Micro running the ARM-1 based ARM Evaluation System as a co-processor. I think it could be purchased stand-a-lone, but I don't know what you could connect it to other than a BBC Micro. Mar 30, 2020 at 11:25
  • 2
    @Tommy - there's an interview with Wilson that talks about this. They were looking at high-end designs like the 68k and 32k and found 4 Mbps memory throughput @8 MHz, the same as a 6502 at 4 MHz (which were common by that point). They saw no point in using either, and made sure their own design was much more efficient with memory accesses. Oct 11, 2022 at 19:14

2 Answers 2


[Partial answer about how it supports FPM RAM - I still need to look up the manual for timing details]

Support for (Fast) Page Mode RAM (*1)

The CPU supports N and S-cycles (ARM lingo) or Non-Sequential and Sequential cycles. The first access to any memory is always an N-cycle, optionally followed by S-cycles.

To handle this, the original ARM provided a signal SEQ which would be pulled whenever the next instruction fetch was exactly one word ahead. Any memory controller could use this to keep the page open, enabling fast access. By being tied to only sequential fetches SEQ will not be pulled for any (random) data access, jumps/branches or exceptions.

To do so, the ARM featured a somewhat odd design around the address register (*2). It's not the PC that gets incremented with each cycle, but the incrementer is assigned to the address register. It does an automatic increment after each access, and then loads into the register file to update the PC as well. Thus, the next address is available as early as possible. Each load instruction of the address register (from PC or data access) will now suppress setting SEQ, resulting in a full addressing cycle.

It is safe to assume (*3) that the Load/Store Multiple instructions (LDM/STM) use the same addressing mechanic and so also benefit from S-cycles.

Basic Timing Structure for RAM Access

The ARM bus protocol is not designed around a fixed clock source, like 6502 or 8080/8086 style bus protocol, but requires clock signals (Phi1/Phi2) to be produced according to external requirements. Usually the memory controller handles this according to the detected cycle type (N or S), and the memory or I/O accessed.

This is done by extending PHI1/2, depending on the accessed memory (usually PHI1), to meet the device criteria. For third party access, like DMA or DRAM refresh, any conflicting CPU access was postponed by stopping the CPU until it was done. Of course stopping (on DRAM) was only possible during a N-cycle, as S-cycles require that no different address would be issued inbetween - as DMA or Refresh would do (*4).

It was also up to the memory controller to stretch PHI1 whenever an S-cycle crossed a page boundary and a new RAS cycle was needed. Outsourcing all memory handling was a great move to simplify the CPU design - after all, it's the memory subsystem as designed for each computer that knows best how to handle each memory or I/O type.

In addition the memory controller could terminate a memory cycle by pulling ABORT. AFAIR this was only used for memory protection.

As a result a classic ARM CPU does not run at constant speed. 4 MHz is rather the maximum possible speed, not the effective. While the effect is more or less the same as with wait states it does, in theory allow a very fine granuality of speed adjustment. In reality ARM's memory controller worked with a basic clock of 16 MHz, making it not much different from how it would have worked on an 8086/286.

*1 - Or, more generically, for all devices that allow a shortened sequential access, like nibble-ROMs.

*2 - It's easy to see that the idea is inspired by the way the 6502 works.

*3 - I couldn't find any reference supporting this. Still, it would be stupid not to use it as it comes for free.

*4 - This again could create a possible memory fault if a program would do only continuous instruction fetch (S-cycles) without any jump or data access inbetween, as now the memory controller would not be able to do any refresh at all. (It would as well kill any DMA based video generation) It seems as if that risk was seen rather exotic :)

  • 1
    Was it left up to the external controller to test for overflow from one row to another? Like, ignore SEQ if the column address is all 1s? Or the ARM itself make a row size assumption and not signal SEQ in appropriate cases?
    – Tommy
    Feb 21, 2020 at 18:13
  • 2
    It was the job of the memory controller to extend any S-cycle that would cross a page boundry long enough to open the page. I'll add this.
    – Raffzahn
    Feb 21, 2020 at 18:21
  • 4
    I imagine the LD/STM instructions also took advantage of the SEQ signal. They have been deprecated in recent ARM revisions and are no longer optimised for performance, but they would have been important in the early days for this reason.
    – Chromatix
    Feb 21, 2020 at 21:41
  • 1
    @Chromatix The "Ultimate Acorn Archimedes talk" linked in the question comments also implies that LDM/STM were invented to do burst read/writes in FPM. Feb 21, 2020 at 21:57
  • 1
    @Chromatix Sounds plausible. Using the incrementer here as well would come natural (Again much like the 6502 does when accessing a pointer). I just couldn't finde any source to veryfy. I'll add it as being likely.
    – Raffzahn
    Feb 21, 2020 at 22:09

The inverse perspective is to consider that ARMs were optimised for relatively slow memory (FPM DRAM), compared to contemporary pure RISC designs such as SPARC and MIPS which were designed for high frequency (40MHz or more) in "expensive" computers with caches.

As the target frequency was slower, ARM could afford more complex instructions than these RISCs (barrel shifter, conditional execution...). It also reduced power draw, allowed cheap plastic packaging of the CPU, etc...

  • 1
    Already the ARM3 (ARMv2) of 1989 featured a 4 KiB cache at 'only' 25 MHz.
    – Raffzahn
    Feb 21, 2020 at 22:20
  • 1
    @Raffzahn ARM made good choices, a bit by chance, and they decided to redesign the instruction set and break compatibilty several times. Early optimisations for simple pipelines in MIPS and SPARC such as delayed branches should have been quickly abandoned, but they needed to remain compatible.
    – Grabul
    Feb 21, 2020 at 23:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .