I programmed the real F8 back in the day, so I’m quite defensive about it. It’s most charming quirk: doing a long jump clobbers the accumulator.
You're not going to create really large systems for it, but if you want to work a gas pump or a hot water heater or make a tester for 74xx chips or a display controller for persistence of vision displays it is great.
You can code for it in C but I feel like I'm strangling puppies when I do it because it is moving the stack pointer around and doing things to support C calling conventions that I don't really need for the programs I write [1] AVR-8 assembly is fun but I still write C for it because if I need a bigger device I can recompile it for ESP32 or ARM.
Something weird about AVR-8 is that it does not have a unified address space, so in the case of that display controller, it is easy to spool graphic data out of the ROM, not so easy to upload a small amount into RAM (via serial port) and combine that with data from the ROM. I've had the crazy idea of making a AVR-8 on AVR-8 emulator (would get me to A-rank if not S-rank on AVR-8 assembly) which would make it possible to upload tiny programs into RAM but that probably requires software emulation of unified pointers for program memory.
[1] https://betterembsw.blogspot.com/2014/07/dont-overflow-stack...
Which is just bizarre since, again, we have 8086, we have MSP430. And if you are fine with most of your data being 8-bit (which is not that uncommon), there is e.g. 8051 which is still quite popular.
https://developer.nvidia.com/blog/nvidia-arm-and-intel-publi...
Also, a simple 8-bit CPU like the 6502 is just 3.5k transistors while simple 16-bit CPUs like the x86 or 68k are somewhere between 30k and 70k transitors (e.g. I wonder if a 6502 running at full throttle still requires less energy than an x86 or 68k doing the same work in the same time).
I don't think any "real" x86 processor from the 286 onwards had under 100k transistors.
And flipping/storing more bits also use more power, it is a trade off.
(https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... ... and, yes, that's the joke, it's still an amazing hack more than a decade later!)
Honestly, AVR-8 is the reason I'm really into low-level hardware. If I would have started with amd64, I guess I would have given up long before.
git clone https://github.com/f8-arch/doc.git f8-doc && cd f8-doc
docker run --rm -v "$(pwd)":/data fabtesta/ubuntu-xelatex make # or any other container with XeLaTeX that you trust
xdg-open manual.pdf
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.
Because that's the kind of stuff an 8-bit micro does.
Or, gee, was the comment intended to tell us how you tied an onion to your belt in 1969 (which was the style at the time) and made toast as the good lord intended without any newfangled chips in the way, up hills both ways, and we should all get off your lawn? /s
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.
Same for C++.
Assuming everyone else is an idiot leads nowhere worth going.
Intels iAPX 432 had failed because it couldn't beat the much simpler, faster and cheaper, 'stop-gap' x86 design, not because of some C or PDP-11 conspiracy (and the Motorola 68k was much closer in spirit to the PDP ISA and a 'better fit' for C, yet it also lost against the rather crude x86 design).
And what features exactly would you propose for a future CPU to have to support such language constructs? It's not like a CPU is necessarily built to "support C", since a lot of code these days is written in Java/JavaScript/Python/..., but as it turns out, roughly any sane CPU can be used as a target for a C compiler. Many extensions of current CPUs are not necessarily used by an average C compiler. Think of various audio/video/AI/vector/... extensions. Yet, all of them can be used from C code, as well as from any software designed to make use of it. If there is a useful CPU extension which benefits let's say the JVM or v8, you can be sure these VMs will use those extensions, regardless of whether or not they are useful for C.
> 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.
Meanwhile IBM did in fact successfully add hardware assisted GC for the JVM on their Z series mainframes. IBM can do that, since they are literally selling CPUs purely for Java workloads. With a "normal" general purpose CPU, such a "only useful for Java" GC extension would be completely useless if you plan to only run let's say JavaScript or PHP code on it. The problem with such extensions is that every language needs just so slightly different semantics for a GC and as a result it's an active research topic how to generalize this to make a general "GC assist" instruction for a CPU which is useful for many different language VMs. Right now such extensions are being prototyped for RISC-V, in case you missed it. IIRC for GC in particular, research was going in the direction of adding a generalized graph traversal extension since that's the one thing most language VMs can use somehow.
C is in no way "holding back" CPU designs, but being able to efficiently run C code on any CPU architecture which hopes to become relevant is certainly a requirement, since a lot of software today is (still) written in C (and C++), including the OS and browser you used to write your comment.
Just to be clear: this topic here is about tiny microcontrollers. The only relevant languages for such microcontrollers are C/C++/assembly. Nobody cares if it can do hardware assisted GC or if it can do closures/coroutines/... or something.