F8 – an 8 bit architecture designed for C and memory efficiency [video]

The amount of research (or lack thereof) into whether the name was already taken in the same domain is disappointing. For me, F8 will always be this:

https://en.wikipedia.org/wiki/Fairchild_F8

What a strange variation on Z80, extending it with 16-bit wide data paths... Who needs that? We have enough 16-bit ISAs around already, including PDP-11, original 8086 and even 65C816.

I wonder what's the point. 8 bits is not enough to store most values for most applications, it's bad for timers and multiplication, it's just a big waste of CPU cycles in general. The more work CPU has to do, the less time it spends sleeping, which is bad for battery-powered embedded devices. Perhaps, it has its place somewhere, but realistically, an 8-bit CPU these days is very niche at best. Imho, it's not going to take off in mainstream embedded.

https://github.com/f8-arch

There already is an 8bit architecture designed for C: AVR

How does F8 compare to RV16 in terms of resources (die size) used and performance ?

Oh, looks interesting, lets check out the architecture documentation! searching.... Ah, found it: Makefile and manual.tex... Yeah, f off :)

I honestly don't see the point. I personally would prefer a CPU architecture with as wide a memory bus as possible.

All the way to 16384 bit and at least 4, but preferably 16 cores, each core with at least 1 MiB of on chip SRAM.

Now that would be useful to me.

C is undeniably a legendary programming language, but it's time to move beyond the constraints of the C abstract machine, which was heavily shaped by the PDP-11 due to Unix's origins on that architecture. C feels outdated for modern computing needs.

It lacks features like lambda calculus, closures, and coroutines—powerful and proven paradigms that are essential in modern programming languages. These limitations make it harder to fully embrace contemporary programming practices.

The dominance of C and its descendants has forced our systems to remain tied to its design, holding back progress. Intel tried to introduce hardware assisted garbage collection, which unfortunately failed miserably because C doesn't need it, and we are still having to cope with garbage collection entirely in software.

While I’m not suggesting we abandon C entirely (I still use it, like when writing C FFI for some projects), we need to explore new possibilities and move beyond C to better align with modern architectures and programming needs.