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 '20 at 16:45
  • 4
    The Ultimate Acorn Archimedes Talk scheds some light on this. – fuz Feb 21 '20 at 17:40
  • 2
    The Archimedes range initially used ARM2. – David Thomas Feb 25 '20 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. – Richard Broadhurst Mar 30 '20 at 11:25

[Partitial 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 optional 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, jump/branch or exception.

To do so, the ARM featured a somewhat odd design around the address register (*2). Not the PC gets incremented each cycle, but the incrementer is assigned to the address register, doing an automatic increment after each access and then loaded 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 instruction (LDM/STM) use the same addressing mechanic and thus as well benefits due 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 does, but reqiures clock signals (Phi1/Phi2) to be produced according to external requirements. Usually the memory controller does handle this according to the cycle detected (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 generic 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 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 seams 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 '20 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 '20 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 '20 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. – Michael Karcher Feb 21 '20 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 '20 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 '20 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. – TEMLIB Feb 21 '20 at 23:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.