@OlafS25

Quote:

OlafS25 wrote: @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

You're confusing assembly and code density: they are NOT the same thing!

Code density is very important even nowadays with CPUs integrating hundreds of billions transistors and despite most of the code is generated by compilers from high-level languages.

@matthey

Quote:

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

I would also add "data density" as a 4th metric: how much data is stored on data, BSS and stack sections, because this influences the performances as well.

Depending on the architecture, code density and data density "fight each other", because constants (immediates, offsets/displacements) could be located more in the code section (CISCs) instead of the data section (pseudo-RISCs).
Being in the code section is greatly preferred, because this data is immediately accessible due to the fact that... it's already there (part of the instructions stream), and just need to be masked & unpacked, whereas being located on the data section requires additional load instructions to be executed to retrieve it and likely a temporary register where to put the data before being used (common case for pseudo-RISCs).

Evaluating the data density could be difficult, because it requires an analysis of the stack usage, which is different depending on the specific architecture. So, roughly adding the data and BSS sizes isn't enough, but it's just the starting point (let's call it static data density).

The data density influences the performance of the L1 data cache (and down to the memory hierarchy) in a similar way that code density influences the L1 code cache (and so on).

Architectural designs can help improving data density with more compact/efficient data layouts and/or by specialized instructions which reduce, or even completely remove, the use of data in some scenarios. Think about pointers size(s), for example: compacting it/them brings benefits in this area. A different data layout for function pointers tables and VMTs can help as well. Other ways to implement switch/cases, in particular when case values are sparse. And so on.
Quote:

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.

Right, but still has too many executed instructions for the reasons that I've highlighted on a previous comment.

Memory accesses are higher than AArch64, but that's primarily because this architecture doesn't push the return address to the stack, and viceversa, when making a call to a subroutine or getting back from it, since a proper register is used in those cases.
I've solved this issue in my new architecture by (optionally) defining a "return address pointer" register (and some internal memory for keeping those addresses) which points to the last return addresses. The primary reason for introducing it was for security (to forbid changing return addresses by malicious software), but it has also very good benefits in terms of reduced memory accesses (even better than AArch64, which can avoid storing only the last return address to memory).

@OneTimer1

Quote:

OneTimer1 wrote: @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

Not only MIPS, but RISC-V as well is inferior.
Quote:

but we might remember how the SONY PS1 ran circles around a naked A1200.

Seriously, are you making such a comparison?!?
Quote:

No one asked for Code Density

Then could you please tell me why processor vendors are spending TONs of money on improving the situation of their products from this PoV? Why so many studies regarding this topic?
Quote:

and even NXP, the owner of the 68k ISA, dumped this architecture for ARM.

Nope. They went to PowerPC, which sucked at the embedded market. After many years they recognized the failure and embraced ARM.

Whereas they should have continued with their 68k instead of abandoning it.
Quote:

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.

The main problem of the Amiga o.s. is that it's too much linked to its hardware.

Otherwise it would have been very good for embedded use.

AROS has shown some value. Unfortunately, it's not yet complete.
Quote:

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

Interesting. What's the license?

OneTimer1

Quote:

OneTimer1 wrote: @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 LESSTHAN= 10; iter ++) { count = 0; for (i = 0; i LESSTHAN= SIZE; i++) flags[i] = 1; for (i = 0; i LESSTHAN= SIZE; i++) { if (flags[i]) { prime = i + i + 3; k = i + prime; while (k LESSTHAN= SIZE) { flags[k] = 0; k += prime; } count = count + 1; } } } // return count == 1899 ? 0 : count; } M68k GCC 16.1.0 Size: 0xB6 main: linkw %fp,#-20 moveq #1,%d0 movel %d0,%fp@(-16) braw 98 clrl %fp@(-12) clrl %fp@(-4) bras 2a moveal %fp@(-4),%a0 addal #0,%a0 R_68K_32 .bss moveb #1,%a0@ addql #1,%fp@(-4) cmpil #8190,%fp@(-4) bles 18 clrl %fp@(-4) bras 8a moveal %fp@(-4),%a0 addal #0,%a0 R_68K_32 .bss moveb %a0@,%d0 beqs 86 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 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 addql #1,%fp@(-12) addql #1,%fp@(-4) cmpil #8190,%fp@(-4) bles 3a addql #1,%fp@(-16) moveq #10,%d0 cmpl %fp@(-16),%d0 bgew e cmpil #1899,%fp@(-12) beqs b2 movel %fp@(-12),%d0 bras b4 clrl %d0 unlk %fp rts ARM 32Bit GCC 16.1.0 Size: 0xBC 9e movs r3, #0 str r3, [r7, #12] movs r3, #0 str r3, [r7, #20] b.n 2c 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 movs r3, #0 str r3, [r7, #20] b.n 8e 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 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 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 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 ldr r3, [r7, #8] adds r3, #1 str r3, [r7, #8] ldr r3, [r7, #8] cmp r3, #10 ble.n c ldr r3, [r7, #12] movw r2, #1899 @ 0x76b cmp r3, r2 beq.n b2 ldr r3, [r7, #12] b.n b4 movs r3, #0 mov r0, r3 adds r7, #28 mov sp, r7 pop {r7} bx lr You see, size isn't that different

I don't know where you've picked such results and how you've compiled them, but they are very bad and the compiler hasn't even done trivial optimizations.

Here is the same program compiled for size (with -OS) on the 4 most common architectures plus the 68K: https://godbolt.org/z/xvv17foPn

Yes, ARM is very good (best result), and 68k is at very honorable 3rd place (despite the generated code is certainly not optimal) with just one byte more than x64.

However, you can clearly see why code density is so much important nowadays when you check the results for the other two architectures.

BTW, I've already reported here:
https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44169&forum=17&start=0&viewmode=flat&order=0#841311
the results for the same benchmark.
My new architecture performs "a little bit" (!) better (also from the executed number of instructions metric), but with finely tuned manual assembly code.

This new architecture S32E has similar (and could do better, according to the authors), claiming that the code was generated by their compiler. However, it looks finely tuned manual assembly code as well.
Now could you please tell me why people are developing a new architecture nowadays focused on getting the best results for the code density?

Last edited by cdimauro on 25-Jul-2026 at 04:57 AM.

@matthey

Quote:

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

Just a note here: 68k was never 64-bit. Only some 32-bit instructions which produced 64-bit results were removed from the last architectures.

All 68k processors are designed and remain 32-bit ISAs.