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

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

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

After multiple discussions on PPC VLE, I found some comparison data with Thumb-2 in an old NXP thread from 2017.

ARM or Power Architecture
https://community.nxp.com/t5/QorIQ/ARM-or-Power-Architecture/td-p/685411?profile.language=en
EAlepins Quote:

We've compared a single core of the MPC5777C (e200z7 @ 264MHz) with the Texas Instruments TMS570LC4357 (Cortex-R5 @ 300 MHz), both at maximum performance (but code running from Flash) and we've got that MPC5777C is ~15% more performant than TMS570LC.:smileyhappy: ... No, benchmark is made with proprietary source code. I can however say the source code is generated from models (model-based) and the code is very linear (not that much loops). It is a control application (in, logic, out). It has 300 000 lines of code (without comments or blank lines). The benchmark accesses no true I/O or drivers (they are stubbed with SW). Uses 32bits floating-point. Comparison was done with VLE for PowerPC and with Thumb-2 for ARM. Code size is 19% smaller for the TMS570LC: ARM wins there! PowerPC compiler used is CodeWarrior 10.5 for MPC5xxx (Freescale/Metrowerks, not GCC). ARM compiler is IAR.

Thumb-2 code is ~19% smaller than PPC VLE code but the PPC VLE ISA may provide better performance. Too bad there are no stats on the number of dynamically executed instructions. I would not be surprised if fewer instructions are executed with PPC VLE than Thumb-2. Thumb-2 is much better than Thumb in this important performance metric but there are still more instructions executed on average than most 32-bit fixed length RISC ISAs.

In conclusion, the compressed PPC VLE ISA would likely be behind both Thumb-2 and RISC-V extension hell in code density. Therefore, wider adoption of PPC VLE was unlikely to save PPC. At least RISC-V developers understand the importance of Thumb-2 like code density for the embedded market which is their goal while Motorola/Freescale/NXP AIMed for surrender in the 32-bit embedded market their 68k pioneered and led for roughly two decades before switching to fat PPC.

@matthey

I know how you love the topic code density. But in reality, as someone else mentioned, most software today is written in high level languages using compilers. Only low level stuff is written in assembler. Even games use special APIs like DirectX and do not talk to hardware directly or use game engines who do that. So for more than 90% of programmers "code density" is irrelevant. And even for the rest the overall performance including supporting several cores is more relevant than code density.

You are doing a lengthy discussion about something noone else outside cares anymore

OlafS25 Quote:

I know how you love the topic code density. But in reality, as someone else mentioned, most software today is written in high level languages using compilers. Only low level stuff is written in assembler. Even games use special APIs like DirectX and do not talk to hardware directly or use game engines who do that. So for more than 90% of programmers "code density" is irrelevant. And even for the rest the overall performance including supporting several cores is more relevant than code density. You are doing a lengthy discussion about something noone else outside cares anymore

Code density was/is extremely important for embedded CPUs with cheaper narrower memory, cheaper narrower data bus and a power saving small instruction fetch size. However, it is an important performance metric for all CPU cores including high performance CPU cores. The top 3 CPU performance metrics that can be easily measured are likely the following.

Top CPU performance metrics
1. number of instructions executed (dynamic instruction count)
2. code density
3. memory accesses/traffic

Early fat RISC ISAs with 32-bit fixed length instruction encodings and 32 GP registers decreased the number of instructions executed but the large code increased memory traffic and instruction supply became a bottleneck. DEC Alpha architects addressed this by pioneering the multi-level cache system but there is a significant delay to the next cache level which reduces performance. Also, caches are wasted for instructions instead of data, more of the memory bandwidth is wasted for memory traffic leaving less for data traffic and instruction supply uses more of the power budget. Compressed RISC ISAs like SuperH and ARM Thumb appeared but the 16-bit fixed length instructions had limited encoding space for immediates, displacements and registers so the number of instructions increased and the number of memory accesses increased even though the overall memory traffic improved. These early compressed RISC ISAs could not scale up in performance.

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

Thumb-2 Performance o Thumb-2 performance is 98% of ARM performance o Thumb-2 code achieves 125% of Thumb performance

On higher end embedded hardware capable of running Linux like Cortex-A cores, the compressed ARM Thumb-2 ISA uses 16-bit and 32-bit instruction encodings nearly reaching the performance of the original 32-bit fixed length encoded ARM ISA. Thumb-2 reduces power/energy and saves cache transistors though. The original ARM ISA was now practically obsolete even though Thumb-2 still increases the number of instructions executed and the number of memory accesses. Support for the obsolete original ARM ISA was dropped from embedded cores and ARM introduced an improved 32-bit fixed length encoded AArch64 ISA with improved code density for Cortex-A cores. AArch64 reduces the number of instructions executed and the number of memory accesses compared to Thumb-2 to improve performance but falls short on code density. However, there are better compressed ISAs than Thumb-2 which do not increase instructions executed and memory accesses and some even have Thumb-2 like code density with the potential to surpass it. One such compressed ISA is the 68k. The 68k has similar CISC performance advantages that made x86(-64) king of the desktop and server markets but with improved Thumb-2 like code density. The performance advantages of the 68k were reduced by scaling it down into the embedded market and ColdFire and then overlooked much like the WWII P-51 Mustang airplane with the original lower power engine. The P-51 had more efficient wings with less drag which provided noticeable advantages like better fuel efficiency, longer range and better dive speed and stability. When the British Rolls Royce Merlin engine used in the Spitfire was put in it, it now had a higher top speed and faster climb rate as well. The single prop P-51 fighter was not only able to do the unthinkable of escorting bombers into Germany but it had enough range and loiter time to gain air superiority ending the war much sooner and saving many lives. Sometimes efficiency matters and code density is kind of like wing efficiency for an airplane. Drag of a wing can never be eliminated completely as lift is what makes an airplane fly. Similarly, instruction supply is what makes CPU cores fly but good code density is like reducing the drag. Early airplane engineering mentality was to add more lift as needed to improve performance resulting in the biplane and triplane but this increased drag. The RISC mentality of increasing instruction supply (lift) while ignoring code density (drag) to increase performance is just as outdated. Drag is not only extremely important for high speed planes today but it is also important for fuel efficient commercial airplanes. Originally, low cost airplanes with a small wing area needed low drag which are like small embedded CPU cores which minimize instruction supply to save power but need good code density to make it possible.

Last edited by matthey on 22-Jul-2026 at 05:20 PM.
Last edited by matthey on 22-Jul-2026 at 03:34 PM.

@matthey

as far as I know is AmigaOS very efficient but not perfect suited for embedded hardware and there are alternatives with better commercial support. Today all development there is ARM based, I do not see any realistic chance to go against that. And the possible advantages of 68k + AmigaOS are not that big to change the market

Last edited by OlafS25 on 23-Jul-2026 at 09:53 AM.

@OlafS25

Quote:

OlafS25 wrote: Today all development there is ARM based, I do not see any realistic chance to go against that.

ACK! ARM and MIPS/RISC-V, the code density of MIPS might be inferior to 68k but we might remember how the SONY PS1 ran circles around a naked A1200.

No one asked for Code Density and even NXP, the owner of the 68k ISA, dumped this architecture for ARM.


Quote:

OlafS25 wrote: And the possible advantages of 68k + AmigaOS are not that big to change the market

FreeRTOS, Zephyr are popular for realtime applications and Linux (with build systems Yocto, Buildroot, OpenWrt) are often used in the embedded world.

If you ever saw how flexible such systems could be build for specific usage, you will understand why an AmigaOS could hardly compete with them. Most people here will disagree because they are Amiga fans, but most of them never built a system for their specific needs.

BTW.: If you are an Amiga fan and want to experiment with an AmigaOS for embedded systems, you can find a clone on the Aminet: https://aminet.net/package/dev/cross/AmiExec
I sadly never heard someone used it

Last edited by OneTimer1 on 23-Jul-2026 at 04:22 PM.

@OlafS25
There is a web page offering to compile a program with different C-Compilers and architectures.

https://godbolt.org/

// expect: success
// title:  sieve benchmark, a larger test of the code generator
 
#define SIZE 8190
 
char flags[SIZE+1];
 
int main(void) {
  int i, prime, k, count, iter; 
  //
  for (iter = 1; iter <= 10; iter ++) {
    count = 0;
    for (i = 0; i <= SIZE; i++)
      flags[i] = 1;
    for (i = 0; i <= SIZE; i++) {
      if (flags[i]) {
        prime = i + i + 3;
        k = i + prime;
        while (k <= SIZE) {
          flags[k] = 0;
          k += prime;
        }
        count = count + 1;
      }
    }
  }
  //
  return count == 1899 ? 0 : count;
}

main:
 linkw %fp,#-20
 moveq #1,%d0
 movel %d0,%fp@(-16)
 braw 98 <main+0x98>
 clrl %fp@(-12)
 clrl %fp@(-4)
 bras 2a <main+0x2a>
 moveal %fp@(-4),%a0
 addal #0,%a0
    R_68K_32 .bss
 moveb #1,%a0@
 addql #1,%fp@(-4)
 cmpil #8190,%fp@(-4)
 bles 18 <main+0x18>
 clrl %fp@(-4)
 bras 8a <main+0x8a>
 moveal %fp@(-4),%a0
 addal #0,%a0
    R_68K_32 .bss
 moveb %a0@,%d0
 beqs 86 <main+0x86>
 movel %fp@(-4),%d0
 addl %d0,%d0
 movel %d0,%d1
 addql #3,%d1
 movel %d1,%fp@(-20)
 movel %fp@(-4),%d0
 addl %fp@(-20),%d0
 movel %d0,%fp@(-8)
 bras 78 <main+0x78>
 moveal %fp@(-8),%a0
 addal #0,%a0
    R_68K_32 .bss
 clrb %a0@
 movel %fp@(-20),%d1
 addl %d1,%fp@(-8)
 cmpil #8190,%fp@(-8)
 bles 64 <main+0x64>
 addql #1,%fp@(-12)
 addql #1,%fp@(-4)
 cmpil #8190,%fp@(-4)
 bles 3a <main+0x3a>
 addql #1,%fp@(-16)
 moveq #10,%d0
 cmpl %fp@(-16),%d0
 bgew e <main+0xe>
 cmpil #1899,%fp@(-12)
 beqs b2 <main+0xb2>
 movel %fp@(-12),%d0
 bras b4 <main+0xb4>
 clrl %d0
 unlk %fp
 rts

	9e <main+0x9e>
 movs	r3, #0
 str	r3, [r7, #12]
 movs	r3, #0
 str	r3, [r7, #20]
 b.n	2c <main+0x2c>
 movw	r3, #0
    R_ARM_THM_MOVW_ABS_NC flags
 movt	r3, #0
    R_ARM_THM_MOVT_ABS flags
 ldr	r2, [r7, #20]
 add	r3, r2
 movs	r2, #1
 strb	r2, [r3, #0]
 ldr	r3, [r7, #20]
 adds	r3, #1
 str	r3, [r7, #20]
 ldr	r3, [r7, #20]
 movw	r2, #8190	@ 0x1ffe
 cmp	r3, r2
 ble.n	16 <main+0x16>
 movs	r3, #0
 str	r3, [r7, #20]
 b.n	8e <main+0x8e>
 movw	r3, #0
    R_ARM_THM_MOVW_ABS_NC flags
 movt	r3, #0
    R_ARM_THM_MOVT_ABS flags
 ldr	r2, [r7, #20]
 add	r3, r2
 ldrb	r3, [r3, #0]
 cmp	r3, #0
 beq.n	88 <main+0x88>
 ldr	r3, [r7, #20]
 lsls	r3, r3, #1
 adds	r3, #3
 str	r3, [r7, #4]
 ldr	r2, [r7, #20]
 ldr	r3, [r7, #4]
 add	r3, r2
 str	r3, [r7, #16]
 b.n	78 <main+0x78>
 movw	r3, #0
    R_ARM_THM_MOVW_ABS_NC flags
 movt	r3, #0
    R_ARM_THM_MOVT_ABS flags
 ldr	r2, [r7, #16]
 add	r3, r2
 movs	r2, #0
 strb	r2, [r3, #0]
 ldr	r2, [r7, #16]
 ldr	r3, [r7, #4]
 add	r3, r2
 str	r3, [r7, #16]
 ldr	r3, [r7, #16]
 movw	r2, #8190	@ 0x1ffe
 cmp	r3, r2
 ble.n	60 <main+0x60>
 ldr	r3, [r7, #12]
 adds	r3, #1
 str	r3, [r7, #12]
 ldr	r3, [r7, #20]
 adds	r3, #1
 str	r3, [r7, #20]
 ldr	r3, [r7, #20]
 movw	r2, #8190	@ 0x1ffe
 cmp	r3, r2
 ble.n	3c <main+0x3c>
 ldr	r3, [r7, #8]
 adds	r3, #1
 str	r3, [r7, #8]
 ldr	r3, [r7, #8]
 cmp	r3, #10
 ble.n	c <main+0xc>
 ldr	r3, [r7, #12]
 movw	r2, #1899	@ 0x76b
 cmp	r3, r2
 beq.n	b2 <main+0xb2>
 ldr	r3, [r7, #12]
 b.n	b4 <main+0xb4>
 movs	r3, #0
 mov	r0, r3
 adds	r7, #28
 mov	sp, r7
 pop	{r7}
 bx	lr

Last edited by OneTimer1 on 23-Jul-2026 at 08:30 PM.
Last edited by OneTimer1 on 23-Jul-2026 at 08:28 PM.
Last edited by OneTimer1 on 23-Jul-2026 at 08:26 PM.

OlafS25 Quote:

as far as I know is AmigaOS very efficient but not perfect suited for embedded hardware and there are alternatives with better commercial support. Today all development there is ARM based, I do not see any realistic chance to go against that. And the possible advantages of 68k + AmigaOS are not that big to change the market

The AmigaOS is designed like a RTOS. There are many other options for a RTOS that are better in various ways. The major advantage of the 68k AmigaOS is that it provides a standard small memory footprint system with GUI. Most other RTOS software, including the OS itself, has to be configured and usually cross compiled for the hardware it is used on. There is an advantage to already having some of the needed software compiled, optimized, tested and downloadable. It is not only convenient but saves time and often results in better quality software.

Raspberry Pi CEO Eben Upton said roughly half of Raspberry Pi SBCs (~70 million units) have been sold for embedded use. RPi hardware has set pseudo embedded form factor standards and other standards related to connectors and I/O. There are many clones of RPi hardware and some of it is overall better. The RPi advantage is standard hardware with a good value even though the hardware is not particularly suited for embedded use.

Why Raspberry Pi Isn’t a Good Choice for Commercial Products
https://www.allaboutcircuits.com/technical-articles/10-reasons-raspberry-pi-isnt-a-good-choice-for-commercial-products/ Quote:

Why Do Some Engineers Choose RPi? Let us first try to understand why many engineers may want to use Raspberry Pi for their product development. There are various benefits to the Raspberry Pi: o Low cost (~35$) o Huge processing power in a compact board o Many interfaces (HDMI, multiple USB, Ethernet, onboard Wi-Fi and Bluetooth, many GPIOs, USB powered, etc.) o Supports Linux, Python (making it easy to build applications) o Readily available examples with community support o Developing such an embedded board is going to cost a lot of money and effort When you are building a hobby or a personal project, all the points mentioned above are good. But, if you are building an industrial or commercial product, you have to think about a lot of other critical parameters before choosing any ready-to-use embedded board.

There is better embedded hardware than RPi hardware but it became cheaper than most because of economies of scale as it is used for other general purposes including hobby, educational and desktop like uses as it scaled up. There is an advantage to a whole standard RPi system, which includes an OS, as now better software can be more conveniently downloaded.

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

Raspberry Pi OS is a Unix-like operating system developed for the Raspberry Pi line of single-board computers. Based on Debian, a Linux distribution, it is maintained by Raspberry Pi Holdings and optimized for the Pi's hardware, with low memory requirements and support for both 32-bit and 64-bit architectures. Originally released in July 2012 under the name Raspbian, it was introduced shortly after the launch of the first Raspberry Pi model.

The RPi OS was optimized for small memory footprint hardware, a requirement for low cost hardware and a major reason why RPi hardware became so popular in the embedded market. However, the 68k AmigaOS is a better RTOS with a smaller memory footprint than the 32-bit RPi OS using the ARM Thumb-2 ISA on RPi hardware. For smaller memory footprint RPi SBCs, the RPi OS is often replaced with a configurable RTOS but loses the advantage of a standard system like 68k AmigaOS systems. Some embedded uses do not required RTOS response times or the lower power of smaller RPi SBCs so the RPi OS is likely used for some embedded applications despite the RPi OS not being particularly well suited for embedded use. The embedded market is huge after all and each use has different requirements. A low cost small memory footprint standard RPi system was the reason why RPI became an embedded market powerhouse, not any new technical advancement.

The 68k is a good embedded market architecture and the AmigaOS is a better embedded market OS than Linux. The 68k needs more modern SoCs/MCUs and the AmigaOS needs updating but a small memory footprint standard 68k AmigaOS system is still impressive today and offers a cost advantage like the RPi used to propel to what it is today. The 68k Amiga has an existing retro market that can be used to improve economies of scale. If new 68k Amiga hardware was produced cheap enough and had a few embedded market features added like the RPi, it has a similar chance of being a success in the embedded market.

Last edited by matthey on 24-Jul-2026 at 03:58 PM.

OneTimer1 Quote:

ACK! ARM and MIPS/RISC-V, the code density of MIPS might be inferior to 68k but we might remember how the SONY PS1 ran circles around a naked A1200.

The A1200 had the Commodore "no new chips" handicap and the low Amiga chipset clock speed meant low CPU clock speed on cost reduced hardware. Commodore used the cheapest embedded CPUs and cheapest memory too. The MIPS R3000 design was released in 1988 so between 68030 and 68040 and one 1994 PS1 chip was claimed to contain 1 million transistors, more than a 68020 and Amiga chipset together. The R3000 performance is more comparable to a 68040 but neither are particularly high performance or good designs for their time. A better compare is the superscalar 68060 vs superscalar PS2 MIPS CPU where both are good designs. The 68060 has better general purpose integer performance/MHz while the PS2 MIPS CPU is more specialized for SIMD performance. The 8-stage 68060 should have clocked higher but the 6-stage MIPS CPU core was clocked higher.

OneTimer1 Quote:

No one asked for Code Density and even NXP, the owner of the 68k ISA, dumped this architecture for ARM.

Motorola/Freescale developed ColdFire and upper management decided it had to scale below where PPC could scale so 64-bit and high end support was removed from the 68k base which included these things. Management had bet the farm on PPC so when it died, 68k/ColdFire was mostly older low end IP deliberately sabotaged from scaling up to replace PPC so they pulled the plug and switched to ARM. Even low end Thumb-2 has 32b x 32b = 64b instructions like were removed from the 68060 and CF. The Motorola/Freescale upper management strategy was to upgrade customers that needed higher end features than CF to PPC to improve economies of scale but most upgraded to ARM Thumb-2 hardware instead which is more suited for embedded use than fat PPC. Between an old downgraded and down scaled 68k and a more modern upgraded and up scaled Thumb-2, most embedded customers would likely choose Thumb-2 and that was the more convenient choice for Motorola/Freescale/NXP. The price of convenience is paying license fees and royalties to ARM but they have enough markup their chip development and it spares them the ISA and CPU core design and development that they had become bad at.

OneTimer1 Quote:

FreeRTOS, Zephyr are popular for realtime applications and Linux (with build systems Yocto, Buildroot, OpenWrt) are often used in the embedded world. If you ever saw how flexible such systems could be build for specific usage, you will understand why an AmigaOS could hardly compete with them. Most people here will disagree because they are Amiga fans, but most of them never built a system for their specific needs.

I agree that there are more modern, flexible and better RTOS alternatives to the AmigaOS. However, if competitive standard 68k Amiga hardware was available, an included AmigaOS likely would find some embedded use like in the Commodore days. The embedded use would likely grow as the AmigaOS improves and multi use like RPi should improve economies of scale.

OneTimer1 Quote:

There is a web page offering to compile a program with different C-Compilers and architectures. https://godbolt.org/ ... You see, size isn't that different

Did you look at the code generated?

1. The 68k may benefit from better code and better looking code with the GCC -fomit-frame-pointer compiler option. VBCC for the 68k and some newer architectures use this as the default.

2. This code is poorly optimized if at all. The 68k code only uses 4 registers and it could avoid accessing the stack frame altogether by using more registers. The 3x "addal #0,%a0" instructions are useless NOPs but waste 6 bytes for each instruction. I suggest using -Os or -O2 for comparison.

3. Despite poor optimization, the 68k still wins in code density and has a large potential performance advantage due to fewer instructions.

Lets look closer at the results. (A32 = original 32-bit ARM ISA, T32 = Thumb-2)

M68k GCC 16.1.0 Size: 0xB6 (50 instructions, 182 bytes)
minus 3x "addal #0,%a0" instructions and 18 bytes (47 instructions, 164 bytes)
68k32 enhancements could save 4x 2B = 8 bytes (47 instructions, 156 bytes)

ARM 32Bit GCC 16.1.0 Size: 0xBC (79 instructions, 188 bytes)

ARM 32Bit A32 with 32-bit fixed length encoding Size: 0xBC (79 instructions, 316 bytes)

ARM T32 code has 58% more instructions and 3% larger code based on your results.
ARM T32 code has 68% more instructions and 15% larger code after removing 68k useless instructions.
ARM T32 code has 68% more instructions and 20% larger code with 68k32 enhancements added.

Your original results actually make the 68k look good just based on the number of instructions. With single cycle throughput instructions, a scalar 68k core would likely easily outperform a 2-way superscalar ARM core at the same clock speed executing this code. Even an ARM OoO core may have trouble keeping up with a scalar 68k core. Too many instructions to execute was a major performance problem for T32 and the motivation behind ARM64/AArch64 which greatly decreases the number of instructions but does not reach 68k or T32 code density.

Most of the ARM T32 instructions have A32 equivalents which are 4 bytes with a fixed length 32-bit encoding. This allows us to roughly compare A32 to the 68k as well.

ARM A32 code has ~58% more instructions and ~73% larger code based on your results.
ARM A32 code has ~68% more instructions and ~93% larger code after removing 68k useless instructions.
ARM A32 code has ~68% more instructions and ~102% larger code with 68k32 enhancements added.

A32 code likely would be a little different with a few instructions saved but a lot more optimization would be required to fix the A32 code density handicap. The T32 code density is actually the industry standard and the RISC-V target. The 68k code density remains very competitive with T32 with good compiler support but compiler support is usually based on hardware popularity. With better compiler support and fewer enhancements than RISC-V, the 68k may have better code density than T32. The 68k also has more performance potential based on performance metrics and CISC advantages.

@matthey

Quote:

matthey wrote: bhabbott Quote: An open standard isn't necessarily the best technically, it's just different enough to avoid IP issues. RISC-V wasn't claiming to be a radical new design that would have higher performance. The emphasis was on openness, and a clean design free of baggage and easily extendable - which is why it attracted so much interest. Of course they wanted it to be compact and fast too, who wouldn't? If an open RISC ISA was the primary goal, why not use earlier open RISC ISAs? 2000 OpenRISC 2005 OpenSPARC 2013 OpenPOWER 2014 RISC-V What differentiates RISC-V from these other open RISC ISAs? 1. VLE with claimed good code density, reserved encoding space for future and research behind it

Only claimed: the reality is quite different.
Quote:

2. claimed to be higher tech RISC but not much new besides compare and branch instructions

Not even that: Intel introduced compare-and-branch instructions (at the microarchitecture level) with the Pentium-M.
Quote:

RISC-V is cleaned up RISC with mistakes like branch delay slots removed but most other RISC ISAs have long since switched to branch prediction or never used them as is the case for OpenPOWER. Smarter use of the encoding space with much of it reserved for the future and custom instructions sounded good in theory.

Smarter? I beg do differ! They FIXED the encoding space with precise patterns, forcing ALL instructions to fit them, giving very little opportunity to make a much better use of it.

For example, immediates/offsets (in the base ISA) are always 12-bit in size, even when it would have been possible to take advantage of some unused bits to further expanding it (especially for load/store instructions).
Quote:

RISC-V developers studied VLEs and developed RVC with the complexity of a VLE, also against the RISC philosophy, but did not understand all the advantages or they may have added 48-bit instructions to begin with. Maybe they wanted to be simpler or maybe they copied other handicapped compact RISC ISAs instead of looking at VLE CISC ISAs, many of which get this right. RISC-V's new embedded instructions introduced the complexity of load/store multiple reg instructions, push/pop return instructions and shift and add instructions which are performing complex instructions like David complained about CISC microcode performing. It was clever to put RISC in the RISC-V name so it can not be removed but simple address modes do not fool me. RISC is dead but the propaganda and hype live on.

We can call all of this RISCwashing.
Quote:

Will there be anything remaining of the RISC philosophy except for a load/store architecture though?

Not even that is remaining, if they implement short circuits in the pipeline to remove the load-to-use stalls. Which basically means that the (micro)architecture is effectively executing load-op instructions.

@matthey

Quote:

matthey wrote: 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.

Just a note: on 68K you can't write to locations using PC-relative addressing modes. But this limit could be easily removed by a new implementation.
Quote:

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

Indeed. And the analysis from the PULP team clearly shows and proves that such super complicated instructions (even more than ARM & 68k) do NOT require many gates for their implementation and do NOT hurt the performance & clock frequency.
Quote:

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

Note: Thumb is 16 and 32-bit instructions lengths (a couple of branches require 2 x 16 bit -> 32 bit encoding).
Quote:

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

Indeed, and for good reason: BA2's 24-bit encoding allows to support binary / 3-operand instructions, which are very common.

Having 16 and 24-bit encodings for common cases is the key to reach a less than 3 bytes average instruction length (32 and 48-bit encodings are a "bonus" to enforce a better code density).
Quote:

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.

Yet, and despite the advantage of load-op instructions, the overall instructions count is higher compared to some ISAs (specifically, AArch64. Which is doing a GREAT job here).

However, even this can be easily improved with a new 68k implementation which supports 3-op/32-bit instructions (arithmetic, logical and shift/rotate instructions).
Quote:

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?

They clearly haven't made the homework and recycled the same propaganda (as it can be seen from the videos of the first conferences).
Quote:

Would the RISC-V developers ever consider CISC tech before ARM implements it?

They are academics living on their utopian world. Hence, the obvious answer.
Quote:

Will the ARM-V ISA return to a VLE and abandon load/store to go full CISC?

Nope. ARM is doing very well with its AArch64 (which, BTW, is already super complicate with extensions like SVE/SVE2. But they have also introduced memcpy and memset instructions: no load/store ISA anymore!), despite the poor code density. That's because the primary market for such ISA is performance, and they are doing very well in the last years (see Apple's Mx processor and the recent nVidia one). They don't care about paying a bigger price (larger caches, more memory) for the poor code density: actually it's all about performance. But they are also lacking the (natural) performance improvements that come from a better code density, and that's something that they can't improve due to the AArch64 design (opcodes length can only increase, but not decrease).

So, AArch64 is not good for embedded, but there ARM has the usual Thumb-2 (but with much bigger executed instructions count, as you've already highlighted), which is still "good enough". Let's see when the embedded mark expands to 64-bit...

@bhabbott

Quote:

bhabbott wrote: @matthey Quote: matthey wrote: 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?

In the real world, yes.
Quote:

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.

That's academia. Again, real-world works differently.
Quote:

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.

Assembly is still used on some specific areas.

More widespread nowadays are intrinsics, and here you've roughly the same problems of writing assembly code, if not even worse than assembly to write (but with much stronger type checking).

@matthey

Quote:

matthey wrote: 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

It could have required even less than 3,000 transistors for implementing both Thumb and Thumb-2 at the same time, if this new ISA would have been designed in a cleaver way since the beginning (by simply taking advantage of a specific "aspect" the ARM architecture).

Now it is what it is: a patchwork on top (an alternative, to be more precise) of the ARM32 design.
Quote:

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.

It's a great achievement for a complex ISA like that.

However, it's still roughly double the gates compared to BA2 (which sports even 32 registers).

@matthey

Quote:

matthey wrote: After multiple discussions on PPC VLE, I found some comparison data with Thumb-2 in an old NXP thread from 2017. ARM or Power Architecture https://community.nxp.com/t5/QorIQ/ARM-or-Power-Architecture/td-p/685411?profile.language=en EAlepins Quote: We've compared a single core of the MPC5777C (e200z7 @ 264MHz) with the Texas Instruments TMS570LC4357 (Cortex-R5 @ 300 MHz), both at maximum performance (but code running from Flash) and we've got that MPC5777C is ~15% more performant than TMS570LC.:smileyhappy: ... No, benchmark is made with proprietary source code. I can however say the source code is generated from models (model-based) and the code is very linear (not that much loops). It is a control application (in, logic, out). It has 300 000 lines of code (without comments or blank lines). The benchmark accesses no true I/O or drivers (they are stubbed with SW). Uses 32bits floating-point. Comparison was done with VLE for PowerPC and with Thumb-2 for ARM. Code size is 19% smaller for the TMS570LC: ARM wins there! PowerPC compiler used is CodeWarrior 10.5 for MPC5xxx (Freescale/Metrowerks, not GCC). ARM compiler is IAR. Thumb-2 code is ~19% smaller than PPC VLE code but the PPC VLE ISA may provide better performance.

Which is a good achievement compared to how poor is PowerPC without VLE.

Yet, not a good result to make it competitive (and not even counting its problem which I was talking since the beginning, and that "the usual guy" hasn't found & reported 'til now).
Quote:

Too bad there are no stats on the number of dynamically executed instructions.

Right. There's no data at all. They could have used a standard benchmark instead of one of their internal projects to show more comparable results. Which to me means that general purpose code didn't look so compelling.
Quote:

I would not be surprised if fewer instructions are executed with PPC VLE than Thumb-2. Thumb-2 is much better than Thumb in this important performance metric but there are still more instructions executed on average than most 32-bit fixed length RISC ISAs.

Likely because the instruction set is limited. ARM hasn't evolved it much, at least on this direction.
Quote:

In conclusion, the compressed PPC VLE ISA would likely be behind both Thumb-2 and RISC-V extension hell in code density. Therefore, wider adoption of PPC VLE was unlikely to save PPC. At least RISC-V developers understand the importance of Thumb-2 like code density for the embedded market which is their goal while Motorola/Freescale/NXP AIMed for surrender in the 32-bit embedded market their 68k pioneered and led for roughly two decades before switching to fat PPC.

I fully agree.