â €
â €
⠀⠀
â €
â €
â €
â €
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀������ �������

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀���� ������ ��� ������� ��� ������'� ��� ��������� (�������������, ������, ���������)
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀����� ������ �� ��������� ��� ������ ���
â €
⠀⠀
â €
â €
â €
â €

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL

Oh com on, let matthey have his code density playground, before he is doing this in threads about phones or game consoles.

Last edited by OneTimer1 on 26-Jun-2026 at 12:53 PM.

@OneTimer1

Ha.. you've got a point there

/m!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@matthey

Don't drool too much...

https://github.com/LinuxMD/linuxmd

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

Licensing for one, there are many levels of "open".

True but there were 3 open RISC choices available. OpenRISC at least was very open and even included an open source and royalty free OpenRISC 1200 CPU core which was hosted at OpenCores.org. OpenRISC was the original flagship project of the OpenCores community. There were later SoC designs using OpenRISC including minSoC, OpTiMSoC and MiSoC.

https://en.wikipedia.org/wiki/OpenRISC
https://en.wikipedia.org/wiki/OpenRISC_1200

OpenRISC was generic RISC like MIPS and used a classic 32-bit fixed length encoding. The RISC-V developers decided they could do better with their own Redone Instruction Set Computer (RISC). The major "innovations" were compare and branch instructions and a 16-bit VLE like Thumb-2 and microMIPS as there were initially only 16-bit and 32-bit instruction lengths, but leaving lots of encoding space for the future. This was after research that indicated code density was important.

RISC-V Compressed ISA V1.9 Quote:

Variable-length instruction sets have long been used to improve code density. For example, the IBM Stretch, developed in the late 1950s, had an ISA with 32-bit and 64-bit instructions, where some of the 32-bit instructions were compressed versions of the full 64-bit instructions. Stretch also employed the concept of limiting the set of registers that were addressable in some of the shorter instruction formats, with short branch instructions that could only refer to one of the index registers. The later IBM 360 architecture supported a simple variable-length instruction encoding with 16-bit, 32-bit, or 48-bit instruction formats. In 1963, CDC introduced the Cray-designed CDC 6600, a precursor to RISC architectures, that introduced a register-rich load-store architecture with instructions of two lengths, 15-bits and 30-bits. The later Cray-1 design used a very similar instruction format, with 16-bit and 32-bit instruction lengths. The initial RISC ISAs from the 1980s all picked performance over code size, which was reasonable for a workstation environment, but not for embedded systems. Hence, both ARM and MIPS subsequently made versions of the ISAs that offered smaller code size by offering an alternative 16-bit wide instruction set instead of the standard 32-bit wide instructions. The compressed RISC ISAs reduced code size relative to their starting points by about 25-30%, yielding code that was significantly smaller than 80x86. This result surprised some, as their intuition was that the variable-length CISC ISA should be smaller than RISC ISAs that offered only 16-bit and 32-bit formats. Since the original RISC ISAs did not leave sufficient opcode space free to include these unplanned compressed instructions, they were instead developed as complete new ISAs. This meant compilers needed different code generators for the separate compressed ISAs. The first compressed RISC ISA extensions (e.g., ARM Thumb and MIPS16) used only a fixed 16-bit instruction size, which gave good reductions in static code size but caused an increase in dynamic instruction count, which led to lower performance compared to the original fixed-width 32-bit instruction size. This led to the development of a second generation of compressed RISC ISA designs with mixed 16-bit and 32-bit instruction lengths (e.g., ARM Thumb2, microMIPS, PowerPC VLE), so that performance was similar to pure 32-bit instructions but with significant code size savings. Unfortunately, these different generations of compressed ISAs are incompatible with each other and with the original uncompressed ISA, leading to significant complexity in documentation, implementations, and software tools support. Of the commonly used 64-bit ISAs, only PowerPC and microMIPS currently supports a compressed instruction format. It is surprising that the most popular 64-bit ISA for mobile platforms (ARM v8) does not include a compressed instruction format given that static code size and dynamic instruction fetch bandwidth are important metrics. Although static code size is not a major concern in larger systems, instruction fetch bandwidth can be a major bottleneck in servers running commercial workloads, which often have a large instruction working set. Benefiting from 25 years of hindsight, RISC-V was designed to support compressed instructions from the outset, leaving enough opcode space for RVC to be added as a simple extension on top of the base ISA (along with many other extensions). The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.

They studied their VLE history and did some good research to find that a 20%-25% code density improvement provides similar performance to doubling the instruction cache size, which I have often quoted. The first generation of 16-bit fixed length RISC ISAs like SuperH, Thumb and MIPS16 were indeed handicapped by "an increase in dynamic instruction count, which led to lower performance".

Profile Guided Selection of ARM and Thumb Instructions Quote:

The data in Table 5 compares the number of instructions executed by the Thumb and ARM codes. As we can see, the number of instructions executed by Thumb code are significantly higher. The increase ranges from around 9% to around 41%. This substantial increase in the number of instructions executed by the Thumb code more than offsets the improved I-cache behavior of the Thumb code. Therefore the net result is higher cycle counts for the Thumb code in comparison to the ARM code. More importantly we can conclude that while Thumb code is smaller and typically expends lesser amount of I-cache energy, these improvements are at the cost of net performance loss as the corresponding ARM code gives lower cycle counts.

I calculated a ~22% dynamic instruction increase on average for Thumb from their benchmarks. This caused a performance drop with high performance memory but a performance gain for cheaper hardware often used in the embedded market and by Commodore. RISC CPUs with 32-bit fixed length encodings required expensive 32-bit memory, large instruction caches, large instruction fetches and wide instruction busses for good performance.

Thumb Squeezes ARM Code Size (Microprocessor Report, March 27, 1995)
https://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/090401.pdf Quote:

The presence of a Thumb preprocessor has a neutral effect on the performance of cached code. Because Thumb instructions are cached while still in their compressed form, twice as many Thumb instructions as ARM instructions fit in the cache. Although more instructions are needed, they are only half as long, so the overall size of most programs is reduced. This results in a larger proportion of program code in the cache. This benefit is neutralized, however, by the greater number of instructions required and by the addition of conditional branches, which cause extra pipeline breaks. The net performance is equal, to within about 5%, between ARM code and Thumb code when both are cached. The effect of memory latency on Thumb performance is particularly intriguing. Given an ideal system with a 32-bit memory bus and no wait states, and ignoring the effects of cache, Thumb code runs about 20% slower due to the increased number of instructions required to perform routine tasks. However, after adding just one wait state to external bus cycles, ARM and Thumb run neck and neck. Adding more wait states gives Thumb an increasing edge. Thumb has a leg up after only a few wait states because the processor can fetch two instructions during every 32-bit bus access. Although the latency affects both ARM and Thumb equally for the first instruction, a processor fetching Thumb code effectively gets every second instruction for free. The minimum ARM7 bus transaction lasts only one clock cycle, so one wait state equates to a half-speed bus—the point at which ARM and Thumb cores perform almost equally. Additional latency penalizes ARM code more severely. The same advantage accrues to other microprocessors that have buses wider than their instruction size. The R4650, for example, has a 64-bit bus, allowing it to perform the same trick as Thumb but on a double-wide scale. Hitachi’s SH7604 and new SH7708 (see090302.PDF) are similar to Thumb in that they fetch 16-bit code over a 32-bit bus. The effect is even more pronounced in lower-cost configurations. In systems with a 16-bit bus, Thumb processors can fetch an instruction in a single cycle. As Figure 2 shows, Thumb code actually runs faster than equivalent ARM code over an 8-bit or 16-bit bus.

Fixed length 16-bit encodings are not general purpose because of the increased number of instructions executed, many of which are dependent and can not be superscalar executed. Without an increase in dynamic number of instructions executed, good code density provides a performance increase everywhere. This was the motivation for ARM Thumb-2 with a VLE using 16-bit and 32-bit instruction lengths. The 16-bit instructions can be used most of the time to improve code density while 32-bit instructions can be used when larger immediates, larger displacements, more registers, better addressing modes or 3 op instructions can replace multiple 16-bit instructions. It is possible to choose more performance with fewer instructions or better code density with more 16-bit instructions. Most popular CISC ISAs were already upgraded with VLEs so had good coded density and could use cheaper 16-bit memory. Table 2 of the Microprocessor Report above has code densities of 6 ISAs from SPECint given by ARM. Intel was not the only one with Operation Crush like propaganda against the 68k as the 68020 has similar code density to Thumb. The 386 benchmarked well, probably due to good x86 compiler support everywhere, including in the ARM compiler. Despite RISC-V propaganda against x86, when compiled for size, I have RVC and x86 code density about the same. There is more RISC-V propaganda from other sources.

Improving Energy Efficiency and Reducing Code Size with RISC-V Compressed
https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf Quote:

Program binaries compiled for fixed-length RISC ISAs are large relative to their CISC counter-parts. But x86 code is substantially larger than that of the short-instruction-word and variable-length RISC ISAs. For embedded systems with severe constraints on instruction memory size, these ISAs are likely to be the most cost-effective. Of the compressed RISCs, MIPS16 and RVC code are about the same size, while Thumb is about 6% smaller. Even so, RVC code is likely to outperform both. MIPS16 and Thumb suffer from lack of floating-point instructions and from access to only eight registers, increasing register spills. Static and dynamic instruction counts are thereby increased. MIPS16 and Thumb programs are composed almost exclusively of 16-bit instructions, whereas only about half of static RVC instructions are 16 bits. Consequently, RVC programs are encoded in vastly fewer static instructions than either MIPS16 or Thumb programs. Most RVC programs thus comprise fewer dynamic instructions than either MIPS16 or Thumb programs, likely improving performance over both. Thumb-2 is a variable-length RISC ISA similar to RVC. Like ARM and Thumb, Thumb-2 has several ISA features that improve code size over RISC-V and RVC code. A PC-relative addressing mode enables many global variable accesses to be encoded as a single 16-bit instruction, whereas global variable accesses in RVC require two 32-bit instructions. Conditional execution shortens some code paths. Load Multiple and Store Multiple instructions shorten function prologues and epilogues in particular. Finally, some arithmetic code sequences can be expressed by fewer Thumb-2 instructions than RVC instructions. Although these features serve to make Thumb-2 code about 7% smaller than RVC code, it is worth noting that some of them significantly complicate certain implementation styles (e.g. conditional execution in a dynamically scheduled pipeline with register renaming).

The first thing to notice is that this is research at Berkeley under Professor David Patterson. Not only do I have RVC at roughly the same code density as x86 when optimized for size but I have Thumb-2 at ~20% better code density than RVC. Besides the bad data, the other points are true. RVC executes fewer instructions than Thumb and is likely competitive with Thumb-2. Thumb-2 uses Thumb instructions so Thumb instructions are not a complete waste but could have been better encoded if 16-bit and 32-bit instructions lengths were planned from inception. Thumb-2 and RVC are both limited to 8 registers in some 16-bit instructions but RVC is better off in the GP register department. The big difference though is in addressing modes. Thumb-2 has CISC like addressing modes and RISC-V has MIPS like addressing modes. PC-relative addressing modes are super valuable for position independent code and a specialty of the 68k. Thumb-2 does not make as good of use of the barrel shifter for addressing modes index and scaled registers in addition to most instructions as the original ARM ISA, but it is still much better than RVC. HP research found MIPS with similar addressing modes as RISC-V to execute 38% more integer computation instructions most of which are likely to repeat the shift and add instructions of indexed and scaled addressing modes.

https://www.researchgate.net/publication/3556351_Pathlengths_of_SPEC_benchmarks_for_PA-RISC_MIPS_and_SPARC Quote:

MIPS executed 38% more integer computation instructions than PA-RISC, while SPARC executed 79% more integer computation instructions, based on the total geometric means for this class of instructions. Looking at the detailed instruction counts, of the architectural features which could cause the reduction in integer computation instructions, scaled indexed loads was the most heavily used, followed by address updates, extract and deposit instructions, compute and branch, and shift and add instructions. However, PA-RISC's small static displacements for floating-point load and store instructions also increased the number of LDO instructions which were counted as integer computation instructions. The high percentage of PA-RISC load and store instructions which use addressing modes beyond the vanilla "base plus displacement" addressing mode in MIPS indicates the usefulness of indexed and update addressing modes.

More recently, RISC-V added an embedded extension which combines shift and add into complex sh1add/sh2add/sh3add instructions in violation of the RISC philosophy of only simple instructions while still requiring twice as many instructions as RISC ISAs with index and scale addressing modes and three times as many instructions as CISC ISAs, not even considering the sometimes increased code size.

RVC does not use complex load/store multiple reg instructions either which also were added less optimally in a later extension in violation of RISC philosophy. Some research found a 12% code density savings from these instructions which Thumb-2 and the 68k use.

Improving Code Density Using Compression Techniques
https://www.eecs.umich.edu/techreports/cse/97/CSE-TR-342-97.pdf Quote:

There are several ways that our compression method can be improved. First, the compiler could attempt to produce instructions with similar byte sequences so they could be more easily compressed. One way to accomplish this is by allocating registers so that common sequences of instructions use the same registers. Another way is to generate more generalized STDS code sequences. These would be less efficient, but would be semantically correct in a larger variety of circumstances. For example, in most optimizing compilers, the function prologue sequence might save only those registers which are modified within the body of the function. If the prologue sequence were standardized to always save all registers, then all instructions of the sequence could be compressed to a single codeword. This space saving optimization would decrease code size at the expense of execution time. Table 3 shows that the prologue and epilogue combined typically account for 12% of the program size, so this type of compression would provide significant size reduction.

Load/store multiple reg instructions would have put RVC within striking distance of Thumb-2 or surpassed if the earlier propaganda was to be believed. RVC was not the only RISC ISA saying no to these as some embedded PPC SoCs running PPC AmigaOS 4 removed them from hardware. At least RISC-V developers finally admitted Thumb-2 like code density is important, they have a ways to go despite earlier false claims and are trying to do something about their mistakes by wasting most of the encoding space they reserved on 16-bit embedded instructions after "Benefiting from 25 years of hindsight".

RISC-V copied off Thumb-2 which has good code density for a 2nd generation compressed ISA but there are higher tech 3rd gen compressed ISAs with better code density and fewer instructions executed.

1st gen compressed ISAs (16-bit fixed length encoding)
SuperH, Thumb, MIPS16

2nd gen compressed ISAs (VLE with 16-bit & 32-bit instruction lengths)
Thumb-2, MicroMIPS

3rd gen compressed ISAs (VLE with 3 or more instruction lengths)
ColdFire, nanoMIPS, BA2

The 3rd gen compressed ISAs further reduce the number of instructions executed by encoding larger immediates and displacements in longer instruction lengths. A 32-bit instruction length can not hold a 32-bit immediate or displacement so multiple instructions are needed instead. All 3 of the 3rd gen ISAs above can place a 32-bit immediate or displacement in a larger instruction.


https://www.chipestimate.com/Extreme-Code-Density-Energy-Savings-and-Methods/CAST/Technical-Article/2013/04/02



That's what the nanoMIPS "48b instructions efficiently encode 32b constants" means too. ColdFire reduced the 68k number of VLE instructions to 3 with 16-bit, 32-bit and 48-bit instruction lengths which is enough for 32-bit immediate and displacement integer constants. With 4 instruction lengths of 16-bit, 32-bit, 48-bit and 64-bit instructions, the most common (d16,An) addressing mode can be used or single precision floating point immediates all in one instruction. Gunnar proposed this for CF on the Freescale/NXP forum claiming that it did not affect the max clock timing. Oddly, he did not keep my sign extended 16-bit immediate addressing mode suggestion which would allow the 68k equivalent of the 2nd BA example to reduce in size from 48-bits to 32-bits, making this general purpose case much more competitive as the 68k matches BA2 in the other 2 cases. BA2 still beats the 68k slightly overall in code density here but the 68k/CF makes it up when accessing memory. Load/store architecture like BA2 require 2 instructions to match a 68k op mem-reg instruction and 3 instructions to match an op reg-mem instruction. The 68k with 16 GP regs does not seem to suffer from elevated instruction counts like most RISC compressed ISAs and a few ISA additions would both improve code density and reduce the number of instructions executed.

Did the RISC-V developers perform cost benefit analysis on CISC tech or discount it out of hand as not simple enough, choosing to rely on simple antiquated RISC tech and RISC propaganda instead? Would the RISC-V developers ever consider CISC tech before ARM implements it? Will the ARM-V ISA return to a VLE and abandon load/store to go full CISC?

@matthey

Quote:

matthey wrote: If an open RISC ISA was the primary goal, why not use earlier open RISC ISAs?

Because that would be boring and you wouldn't learn anything.

Quote:

The problem is that RVC was not competitive enough partially due to the goal of trying to remain simple with instructions and addressing modes.

Why is that a problem?

Quote:

This is the RISC philosophy on performance which David doubles down on with RISC-V. The result is that RISC-V is not competitive in code density or performance. Simple is really only useful for tiny cheap MCUs but a 6502 MCU is smaller and cheaper. Open and customizable is a draw for RISC-V but these advantages only go so far

Simple is also useful for understanding and implementing it.

Quote:

MIPS is a simple and clean RISC ISA, except for branch delay slots and early lack of hardware interlocks, which is easy to learn. The many instructions needed make it tedious to program in assembly though.

Nobody programs in assembly - except for a few diehards like me. I do it on small PIC and AVR MCUs because they are very deterministic with each instruction taking an exact amount of time to execute. I treat them as programmable hardware. For example I created a programmable character ROM using an ATmega1280 and nothing else. The program loop has 10 instructions that accept commands and data on the control port and read the ROM address and output the data all in just 1.12us. No stack, all parameters held in registers and all code paths adjusted to operate in that 1.12us. This includes adding an extra cycle when it gets ahead of the (asynchronous) bus timing in the computer.

Completely insane, but I loved doing it - and it worked better than the discrete logic design it replaced while being smaller than a CPLD + SRAM. Anyone else would use a much faster MCU with fast I/O port and DMA etc., then the program could be written in C.

PIC32MX is harder to work with because the timing isn't deterministic. So it runs at 50MHz but has less precise timing than an AVR running at 25MHz.

matthey Quote:

If an open RISC ISA was the primary goal, why not use earlier open RISC ISAs?

bhabbott Quote:

Because that would be boring and you wouldn't learn anything.

RISC is simple and boring. The philosophy is to simplify the RISC ISA and hardware which is why OpenRISC resembles so many other RISC ISAs. This was the learning tool similar to MIPS, SPARC and DLX which David Patterson and John Hennessy may have expanded to 64-bit for RISC-V (OpenRISC already supported 64-bit).

https://en.wikipedia.org/wiki/DLX Quote:

The DLX (pronounced "Deluxe") is a RISC processor architecture designed by John L. Hennessy and David A. Patterson, the principal designers of the Stanford MIPS and the Berkeley RISC designs (respectively), the two benchmark examples of RISC design (named after the Berkeley design). The DLX is essentially a cleaned up (and modernized) simplified Stanford MIPS CPU. The DLX has a simple 32-bit load/store architecture, somewhat unlike the modern MIPS architecture CPU. As the DLX was intended primarily for teaching purposes, the DLX design is widely used in university-level computer architecture courses.

David Patterson, who coined the RISC name and who is vice chair of the board of directors of the RISC-V Foundation, abandoned the RISC philosophy of simple and decided it was necessary to add complexity with a VLE for RISC survival outside of academic circles. RISC philosophy was to ignore code density as memory was cheap, memory capacities were growing quickly and the simple hardware savings could be used for larger caches. This RISC philosophy failed for Alpha, PA-RISC, MIPS, SPARC and PPC as the importance of code density was grossly underestimated, as discovered in RISC-V research, and the hardware cost of larger caches grows exponentially. RISC-V developers thought adding complexity with a VLE in this one location only was enough to save RISC so they kept everything else as simple as possible. Sorry loyal OpenRISC RISC philosophy followers.

matthey Quote:

The problem is that RVC was not competitive enough partially due to the goal of trying to remain simple with instructions and addressing modes.

bhabbott Quote:

Why is that a problem?

Simple solutions are good where possible but cost benefit analysis of solutions is required to stay competitive. The RISC philosophy had some good ideas and wisdom for limited hardware at the time but some of it has become outdated and some of it was wrong to begin with. Most importantly, the RISC philosophy has not evolved with exponential computer hardware changes due to Moore's Law. If car engineering used a similar philosophy to RISC, our cars would still resemble a Ford Model T. Too simple of engineering discounts tech advances, stifles innovation and leaves no room for convenience and niceties.

I looked at the performance and convenience benefits of a more complex ISA in my last post and now I will look a little more at the hardware cost. "Benefiting from 25 years of hindsight", RISC-V developers finally decided to add a more complex VLE to improve code density for RISC survival. Should they have resisted so long?

Thumb Squeezes ARM Code Size (Microprocessor Report, March 27, 1995)
https://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/090401.pdf Quote:

Hardware Translation Adds No Delays The Thumb module works by reconstituting incoming Thumb opcodes into their matching ARM instructions. It does this through a simple hardwired lookup table. Because there are so few Thumb opcodes, and because they all map one-to-one to ARM instructions, the lookup PLA is fairly small. Thumb adds approximately 3,000 transistors to an ARM7 core, representing about 5% of the total core area, or less than 1 mm2 in a 0.8 micron three-layer-metal process. The Thumb-to-ARM conversion happens on the fly as part of the second pipeline stage. At current clock speeds, enough time is available in the decode stage to add the extra logic without impacting pipeline throughput or latency. After the opcode bits are converted, register references are extracted from the Thumb instruction and placed in their proper positions in the ARM instruction, as shown in Figure 1. Most Thumb instructions accept two operands, while ARM instructions generally take three; the missing source register is created by duplicating the destination operand, creating a destructive two-operand operation—a classic CISC feature. If an immediate value is present, it is zero-extended to fill the larger instruction field. When the fully reconstituted 32-bit instruction makes its way through the pipeline, the standard ARM instruction decoder is none the wiser.

The ~3,000 transistors for the original Thumb ISA with VLE support would have been significant in the 8-bit MPU days and was still 5% of the total core area for an ARM7 core. A 6502 CPU is ~3500 transistors and ARM2 was ~30,000 transistors. The code density improvement of Thumb was ~30% so by RISC-V research, an instruction cache could be half of the size with similar performance.

cache reduction | transistor savings
32kiB_to_16kiB 786,432
16kiB_to_8kiB 393,216
8kiB_to_4kiB 196,608
4kiB_to_2kiB 98,304 (ARM3 originally had 4kiB cache)

A 2 kiB instruction cache instead of 4 kiB instruction cache for ARM3 saves 98,304 transistors using 6T SRAM. The cost of Thumb and the VLE was ~3,000 transistors with no performance loss while the benefit was already a typical 98,304+ transistor savings in caches, at least for cheaper and slower 16-bit memory which can now be used. Thumb-2 likely used a few thousand more transistors but using 16-bit and 32-bit instruction lengths together allowed Thumb-2 to effectively replace the original ARM ISA with poor code density in all cases, taking advantage of the cache savings even on high performance hardware.

https://linuxdevices.org/ldfiles/article078/Experiment_with_Linux_and_ARM_Thumb-2_ISA.pdf Quote:

Thumb-2 Compiled Code Size Thumb-2 Performance Optimized 26% smaller than ARM Thumb-2 Space Optimized 32% smaller than ARM Thumb-2 Performance Analysis of the performance of code for EEMBC* benchmarks on ARM11 like cores Thumb-2 code achieves 125% of Thumb performance Thumb-2 performance is 98% of ARM performance

ARM's cost benefit analysis resulted in the original and simple 32-bit fixed length encoded ARM ISA being deprecated and/or removed in later ARM CPU cores. The simple regular fixed length encoded 32-bit instructions like Alpha, PA-RISC, MIPS, SPARC, PPC and ARM ISAs used or fixed length encoded 16-bit instructions like SuperH, Thumb and MIPS16 ISAs used which work so nicely for simple classic RISC pipelines were looking antiquated. A VLE with good code density and which minimized the number of executed instructions and number of dependent instructions which were common in many early compressed ISAs was looking better all the time.

Another paper looks at the cost of CISC design choices including supporting 2 instruction lengths.

And Now a Case for More Complex Instruction Sets
https://web.cs.ucla.edu/~lixia/papers/1987Case4CISC.pdf Quote:

The cost of half-size instructions If the base processor design were intended to include 16b instructions the following hardware might be added: (1) a two-word instruction buffer (IB) 2x32b (2) Multiplexors from the IB into the instruction decoder (3) Finite-state machine for IB control (4) Modified program counter to allow both 16b increment (for instruction control) and 32b increment (for IB control)

Most CPU cores today use an instruction buffer, including the cores using fixed length instructions. Most cores today are superscalar which destroys the regular instruction fetch of the scalar classic RISC pipeline. Also, a separate instruction fetch pipeline (IFP) can be used to reduce the instruction fetch requirements, reducing power and saving energy. The superscalar 68060 only fetches 4B/cycle yet can multi-issue instructions ~50% of the time. The decoupled IFP was used on later ColdFire designs as well, including for small scalar cores with as few as 19k gates for a 2+2 IFP+OEP.

https://silvaco.com/wp-content/uploads/product/ip/pdf/70008_ColdFireV1Core_Brief.pdf Quote:

Overview The synthesizable 32-bit RISC ColdFire V1 Core (CFV1CORE) is the smallest and lowest power processor in the ColdFire family, using as few as 19K gates. The CFV1CORE small size and 32-bit performance make it ideal for a wide variety of consumer, healthcare, and other embedded systems applications. The CFV1CORE provides up to 230 DMIPS of performance at 200 MHz in a typical 90-nm technology. The ColdFire V1 CPU is based on a variable-length RISC architecture that allows instructions to be 16, 32, or 48 bits in length. The result is more efficiently packed code in memory, reducing memory requirements and lowering overall system cost. For DSP operations, the CFV1CORE includes (optional) dedicated hardware multiplier-accumulator (MAC) and divider (DIV) units. Debug support is through a single-wire Background Debug Mode (BDM) interface and includes an on-chip trace buffer. All ColdFire cores (V1, V2, V3, and V4) share the same architecture and instruction set. Upward compatibility from V1 to V2, V3, and ColdFire V4 processors provides a smooth roadmap to higher performance designs. ColdFire architecture has been deployed in over half a billion production devices making it one of the most widely used embedded microprocessors in the world. With the CFV1CORE, you get production-proven processor IP, plus support from the extensive ecosystem of development tools, operating systems, drivers, and libraries supporting the ColdFire architecture. Features • 32-bit microprocessor core with 24-bit address bus • AMBA 2 AHB unified instruction/data bus • Single-wire debug interface • Variable-length RISC architecture with 16, 32, and 48-bit instructions • Independent, decoupled instruction and execution pipelines • 2-stage Instruction Fetch Pipeline (IFP) • 2-stage Operand Execution Pipeline (OEP) • Static branch prediction to minimize change-of-flow execution time • Execute engines include ALU, barrel shifter, and optional MAC and DIV units • ColdFire Instruction Set Architecture Rev. C (ISA_C) • Standard ColdFire programming model with 16 general-purpose, 32-bit registers ...

ColdFire was competitive in code density and performance but mistakes were made. The biggest mistake was the loss of 68k compatibility as ColdFire could have been a compatible subset of the 68k. CF initially removed too many 68k instructions resulting in decreased code density, an increase of instructions executed and more difficult compiler support but this 19k gate ColdFire V1 core has the most advanced ISA_C support including ISA_B support which brought back the most needed 68k support and includes valuable enhancements to code density and functionality with instructions like MVS (like x86 MOVSX), MVZ (like x86 MOVZX), MOV3Q, BYTEREV, BITREV, FF1 and SATS.

• ISA_A: The original ColdFire ISA with much 68k functionality removed
• ISA_A+: Brought back supervisor stack register
• ISA_B: Added improved data movement instructions, byte- and word-sized compares, misc enhancements
• ISA_C: Added instructions for improved bit manipulation

ColdFire was removing 68k functionality to scale lower while ARM was adding functionality to scale higher. PPC was the AIM alliance politically designated architecture and the 68k and CF were banned from competing with PPC except below where PPC could scale with bad code density. Despite the initial castration of the 68k into CF, CF kept a variable-length RISC architecture encoding using 16-bit, 32-bit and 48-bit instructions, removing any longer 68k instruction encodings than 6 bytes and then calling this a variable-length RISC architecture. CF developers likely performed cost benefit analysis of 68k CPU core designs before deciding that VLE are worthwhile, although CF added a VLE length and likely should have added two. CF developers also kept the CISC reg-mem accesses which is unusual as load/store architectures remain more common.

The paper from above also looks at the hardware cost of reg-mem accesses.

And Now a Case for More Complex Instruction Sets
https://web.cs.ucla.edu/~lixia/papers/1987Case4CISC.pdf Quote:

The effects of memory-to-register (RX) instructions If no change is made to the pipeline, there is no reduction in the number of cycles executed, only reduction in instruction bandwidth. Basically the sequence Load R1, R2, Mem Disp Add R3, R1 is replaced by Add R3, R2, Mem Disp In both cases above, the sum is placed in R3 in the same cycle. With the RX format, the pipeline is available one cycle early to admit a new instruction. However, if the pipeline uses the ALU for both address generation and execution, an RX instruction sequence will be limited to the same performance as before due to ALU contention. If the processor is extended to include a separate added for address generation and appropriate pipeline control (much but not all) of this contention is avoided and performance enhancement can be realized. As a rough estimate, suppose conditional branches represented 20% of instructions executed (and Fix32 load instructions, 30%) Now Fix32-RX reduces the frequency of load instructions to 20% (combining the load with an operation). However, the RX operation completes execution at the same time as the load-operate instruction pair. Thus, when the RX instruction immediately precedes a branch instruction that tests its results, no time is saved; otherwise a cycle is saved. Thus if a branch occupies every fifth position, a cycle is saved when the RX is located in any but the fourth position, or immediately preceding the branch. In the other three cases, the cycle is saved, giving a performance improvement potential (without register/ALU usage conflicts) of 7.5% rather than 10%.

The Fix32 design mentioned is a classic load/store RISC design with 16 GP registers and 32-bit fixed length encoding. The CISC OBI360 design considered is based on the IBM System/360 with 16 GP registers and a VLE with 16-bit, 32-bit and 48-bit instruction lengths but with an ISA simplification to only allow one address generation per instruction. This is the most common case of mem-reg loads that is considered with different frequencies of instruction types considered and the percentages look reasonable.

SPECINT2000 25% loads, 10% stores, 13% branches, and 52% ALU instructions
SPECINT2006 26% loads, 10% stores, 19% branches, and 45% ALU instructions
SPECINT2017 24% loads, 10% stores, 19% branches, and 47% ALU instructions

The simplest CPU core designs have a single ALU and the pipeline iterates over it multiple times for both address generation and instruction execution. The cheap MIPS R4200 even performs FPU calculations by iterating over the same ALU but this give poor integer and FPU performance. Most higher performance RISC cores have separate load/store pipelines with a separate ALU for address calculation, integer execution pipelines with separate ALUs for ALU instruction execution and FPU execution pipelines with ALUs for FPU instruction execution, if they support hardware floating point. Multiple ALUs in separate pipelines increases instruction level parallelism (ILP) at the cost of reduced simplicity but this design worked well for shallow pipelines. Early CISC shallow pipelines also had a single ALU and iterated over it as needed. A separate load/store pipeline/unit with ALU address calculation and generation did not work as well for CISC reg-mem designs. Instead, moving the address generation ALU before the general instruction execution ALU in the same pipeline allows the performance benefit described above but there is another benefit with longer pipelines which is the elimination of load-to-use bubbles/stalls which increase with longer high performance RISC pipelines. The MIPS R3000 5-stage pipeline was increased to 8-stage for MIPS R4000 which increased the load-to-use penalty from 1 to 2 cycles along with the branch penalty which was bad considering the R4000 did not have dynamic branch prediction. These penalties are more detrimental to superscalar performance which probably explains why the PS2 2-way superscalar R3000/R4000 hybrid returned to a 6-stage pipeline with a 1 cycle load-to-use penalty and added dynamic branch prediction. The PPC604(e) also stopped at a 6-stage pipeline and used a deeper pipeline than later popular PPC G3/G4 CPUs. Shallow instruction pipelines with reduced ILP and max clock speeds were a major RISC disadvantage which contributed to Steve Jobs switching from PPC to x86. PPC limited OoO designs can sometimes remove some of the load-to-use latency but code is still scheduled to avoid load-to-use stalls. More aggressive OoO RISC cores are more complex than in-order CISC cores and use more power to remove bubbles CISC code does not have. The RISC-V SiFive series 7 CPU design uses a CISC like design with two ALUs in each integer pipeline like the 68060 design and it is still worthwhile to reduce load-to-use stalls of a 2-way superscalar 8-stage pipeline even though it does not gain the performance benefit of CISC mem-reg instructions as described above which grows with deeper pipelines or the larger benefit of using CISC reg-mem instructions or the code density benefits of using them. The comparable 2-way superscalar 8-stage in-order Cortex-A53 design which is the most popular CPU design ever by volume has a load-to-use penalty of 3 cycles requiring 6 independent instructions between a load and use of the loaded data in order to avoid all bubbles. RISC is fine for cheap and simple shallow pipeline scalar designs but simple is not good for performance.

And Now a Case for More Complex Instruction Sets
https://web.cs.ucla.edu/~lixia/papers/1987Case4CISC.pdf Quote:

Concerning the various alternatives: (1) Fix32 (a simple load-store architecture) with 16 or fewer registers and without cache represents a reasonable design point for a minimum cost processor. Note that the minimum processor cost was achieved with a 50% to 100% increase in instruction traffic (Figure 3), compared with more complex designs.

CISC pipeline design choices may be more complex than RISC pipeline choices but an in-order CISC design saves transistors over an OoO RISC design and CISC code density support saves transistors over larger caches needed by fat RISC. CISC designs are still possible in a 2+2 stage ColdFire V1 core that can be used in a 19k gate sub $0.10 USD MCU/SoC or a sub $1 USD SoC in the case of the 68060. The icing on the cake is the comfort and niceties of readable and easy to program assembly language with minimal instruction scheduling required to avoid stalls. The 68060 is not a Ford Model T but a semi-modern car with good performance potential and even some luxury. I have a 1993 RX-7 supercar which only had 252 HP stock where modern economy cars have that today but it is lighter and handles better than most modern cars while it is easy to add 100 HP which makes it fun enough.

Last edited by matthey on 28-Jun-2026 at 07:49 PM.
Last edited by matthey on 28-Jun-2026 at 07:48 PM.