O.T.: Reason for RISC cpus not having absolute mode?

[Aaendi]

Why was having an absolute address mode missing in the majority of RISC CPUs? If you have 4 bits for the register number, 24 bits for the address, you still have 4 bits left for the instruction field, which is perfectly fine as long as it's limited to loads and stores.

[BitWise]

The key reason is to allow the code to be position independent. This is especially important today when dynamically linked library code is placed at random memory locations to help defeat cyber attacks that attempt to over write program stacks with executable code. Fixed location make things too easy.

[White Flame]

Plus a more simple explanation is that the address width is usually equal or larger to the fixed instruction width. A 24 bit address on a 32-bit system (especially with virtual memory mapping even if the actual physical memory is smaller) wouldn't be able to specify all addresses.

[Aaendi]

Back in the 80s and 90s you'd think a 24-bit address is enough.

[commodorejohn]

24-bit addressing was enough for the average desktop user up through the early '90s, but even by the time Windows 95 came out 8-16 MB was getting a little cramped, at least for power users. And most RISC development was either aimed at high-end workstation systems (which had been shipping with support for 100MB+ since the early '90s anyway) or developed as a general forward-thinking architecture.

[Aaendi]

When I'm looking at hardware specs at old school game systems from the late 80s and early 90s it makes me scratch my head wondering there wasn't a cheaper alternative to the 68000 that also had a nice instruction set. I think the 68000 instruction set can be almost made into RISC cpu if they removed some of their more obscure instructions, removed mem-to-mem instructions, and anything with operands that won't fit in a 32-bit instruction word. Even having a 24-bit address space, but only 20-bit absolute addresses would be nice for a late 80's early 90's game system, because then can have 1MB of space for RAM and system registers, leaving the rest for cartridge memory.

[rpiguy2]

Aaendi wrote:

When I'm looking at hardware specs at old school game systems from the late 80s and early 90s it makes me scratch my head wondering there wasn't a cheaper alternative to the 68000 that also had a nice instruction set. I think the 68000 instruction set can be almost made into RISC cpu if they removed some of their more obscure instructions, removed mem-to-mem instructions, and anything with operands that won't fit in a 32-bit instruction word. Even having a 24-bit address space, but only 20-bit absolute addresses would be nice for a late 80's early 90's game system, because then can have 1MB of space for RAM and system registers, leaving the rest for cartridge memory.

The 68000 had a fast MOV instruction, everything else was dog slow. The next shortest instruction took 2 cycles to load and 4 cycles to execute. Most instructions took considerably longer, even if they weren't memory to memory!

You would really need to cut down the instruction encoding size to 16-bits to get good performance over a 16-bit bus.

To be fair if you required large memory and 32-bit math then the 68000 was the way to go for sure.

Check out the "OSBOURNE 16-bit Microprocessor Handbook". It is a wonderful text that includes tables of instruction timing for all 16-bit processors.

The only processors to achieve high IPC at the time were the fast 8-bit chips (6502, 6809), but they had their own issues with addressing large arrays, 16-bit math, multi-tasking, etc.

[Aaendi]

rpiguy2 wrote:

Aaendi wrote:

When I'm looking at hardware specs at old school game systems from the late 80s and early 90s it makes me scratch my head wondering there wasn't a cheaper alternative to the 68000 that also had a nice instruction set. I think the 68000 instruction set can be almost made into RISC cpu if they removed some of their more obscure instructions, removed mem-to-mem instructions, and anything with operands that won't fit in a 32-bit instruction word. Even having a 24-bit address space, but only 20-bit absolute addresses would be nice for a late 80's early 90's game system, because then can have 1MB of space for RAM and system registers, leaving the rest for cartridge memory.

The 68000 had a fast MOV instruction, everything else was dog slow. The next shortest instruction took 2 cycles to load and 4 cycles to execute. Most instructions took considerably longer, even if they weren't memory to memory!

You would really need to cut down the instruction encoding size to 16-bits to get good performance over a 16-bit bus.

To be fair if you required large memory and 32-bit math then the 68000 was the way to go for sure.

Check out the "OSBOURNE 16-bit Microprocessor Handbook". It is a wonderful text that includes tables of instruction timing for all 16-bit processors.

The only processors to achieve high IPC at the time were the fast 8-bit chips (6502, 6809), but they had their own issues with addressing large arrays, 16-bit math, multi-tasking, etc.

I thought 16-bit register to register adds were 4 cycles each?, but yeah the 68000 takes 4 cycles just to access memory once, so that bogs it down a lot.

[Chromatix]

Typical RISC CPUs deliberately cut down the number of addressing modes directly supported by the instruction set, in favour of providing facilities for the programmer to construct his own addressing modes, and generally speeding up the execution of each instruction. Part of the speedup actually comes from fixing the size of each instruction, so that it's easy to decode and execute several in parallel. In fact, usually there are only register-direct, register-offset, and register-offset-with-update modes, plus immediate-operand loads, adds and bitwise operations. Compare that with CISC CPUs' typical support for absolute and indirect addressing modes, and occasionally even pre-and-post-indexed-indirect-with-offset (which, IIRC, the later versions of the 68K do support).

RISC CPUs usually have far more registers than their CISC cousins, and single-cycle execution of simple instructions. So you can construct an absolute addressing mode by loading the desired address into a spare register (using load-immediate instructions) and then issue a normal register-direct memory operation, and that might actually take fewer cycles than a CISC CPU executing the equivalent absolute addressing mode. On the PowerPC, an arbitrary 32-bit absolute load might be:

Code: Select all

li r9,ADDRlo : oris r9,r9,ADDRhi : lwz r8,r9

taking a total of 5 cycles for a cache hit, during which other instructions can execute in parallel. Recent versions of ARM have 16-bit immediate MOV and MOVT which work similarly to li and oris; older ones may require four instructions to construct an arbitrary 32-bit constant in a register, or they can do a PC-relative load (r15 is the PC, so you can do an offset load from there with a normal load instruction) to bring in a constant packed in at assembly time. Similarly, you can construct indirect addressing modes using sequences of direct memory accesses, possibly interspersed with arithmetic.

The basic ARM cores use fewer transistors than typical 32-bit CISC CPUs. They can do that because they aren't stuffed with complex addressing modes. At the same time, they're considerably faster, even if you run the comparison at the same clock speed and run a benchmark that would theoretically benefit from complex addressing modes.

To illustrate this point concretely, the ARM3 of 1989 and the early versions of the 80386 both used a 1.5µm process, and are actually broadly similar in size; the ARM3 is about 20% larger in terms of transistor count. But the ARM3 includes a 4KB cache and associated tag RAMs on-die, which accounts for the great majority of those transistors, while the 80386 has none of that - it's *all* core. The 1.5µm 80386 was limited to 12MHz; the 1.5µm ARM3 runs up to 25MHz, and takes fewer cycles on average per instruction because it has an actual pipeline architecture, while the 386 is still basically a microcoded CPU.

[BigEd]

Nice points about the early ARM vs 386 situation. I have seen somewhere the specific point that transistors, as a resource, can be spent on complex machinery or on simple memory, and part of the RISC idea is to spend the transistors on cache, not on decode. Indeed, if it's instruction cache vs microcode, there's a sort of direct comparison, although ROM is always denser than RAM.

There's a couple more advantages, which helped machines like SPARC, MIPS, ARM: a simpler machine takes less time and effort to design and to verify. So smaller teams with less money could make a new CPU and still stand a chance of being competitive. Complex machines like x86, ns32k, and 68k take more design cycles to debug.

Of course the x86 had the great advantage in the market of low level backward compatibility, at a time when portable high level source wasn't so common. Hmm, maybe it's still not common... but more common than it was.