[HN Gopher] F8 - an 8 bit architecture designed for C and memory...
___________________________________________________________________
F8 - an 8 bit architecture designed for C and memory efficiency
[video]
Author : mpweiher
Score : 71 points
Date : 2025-02-17 21:24 UTC (3 days ago)
(HTM) web link (fosdem.org)
(TXT) w3m dump (fosdem.org)
| dirkt wrote:
| https://github.com/f8-arch
| ruslan wrote:
| How does F8 compare to RV16 in terms of resources (die size) used
| and performance ?
| kjs3 wrote:
| How does it compare to AVR, another "8 bit architecture
| designed for C..."?
| userbinator wrote:
| 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
| makapuf wrote:
| Question was raised (and answered) at 16:35 on the video.
| drfuchs wrote:
| The speaker's claim that it's hard to find a two-character
| name that hasn't already been used for a CPU architecture
| seems ridiculous on its face. And his tone seems to indicate
| that he knows that (to me, anyway).
|
| 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.
| Joker_vD wrote:
| 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.
| kjs3 wrote:
| MSP430 has entered the chat.
| glouwbug wrote:
| I remember them selling for $4.30 when they came out
| dfox wrote:
| That was long after MSP430 were widely used, that pricing
| was part of the launch of the "value line" G-series (And
| it's associated MSP430 LaunchPad eval board, which is what
| was priced at $4.30).
| glouwbug wrote:
| Yeah I loved my LaunchPad. I bought like 20 and handed
| them out like candy at school
| stevekemp wrote:
| The EZ80 offers enhancements to the Z80, allowing the size of
| the register-pairs to be 24 bits..
|
| https://en.wikipedia.org/wiki/Zilog_eZ80
| imtringued wrote:
| 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.
| kjs3 wrote:
| You need 16 cores and 16MB+ of memory to control a toaster? A
| water heater? The washing machine? At the cheapest possible BoM
| and low power usage?
|
| Because that's the kind of stuff an 8-bit micro does.
| glouwbug wrote:
| No one dreamed of controlling a toaster with an 8 bit CPU in
| 1969
| kjs3 wrote:
| Faggin started the 4004 in '69 and Hoff was pushing off the
| bat for it to be more than a calculator chip so it could be
| used as a general purpose processor. So they might not have
| specifically been 'dreaming of controlling a toaster', they
| and others were clearly dreaming about similar control
| tasks, like printers. They wrote the history down, first
| person...you might check it out.
|
| 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
| glouwbug wrote:
| I certainly do pine for the early years of civil
| discourse
| kjs3 wrote:
| Oh my, pulling the "snark for me and not for thee" card.
| Sometimes you get the discourse you deserve.
| glouwbug wrote:
| I am so confused
| burjui wrote:
| 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.
| osigurdson wrote:
| I haven't use these in a long time but fairly certain the
| memory address is more like 16 bit (otherwise, yeah how could
| you do anything). Still with 8 bit instructions many ops
| require several instructions. If that doesn't matter and it
| needs to be super cheap / small / etc., I think that is why
| these exist.
| boesboes wrote:
| It's a 9 billion market, projected to grow at 5-6% per year.
|
| And flipping/storing more bits also use more power, it is a
| trade off.
| PaulHoule wrote:
| Personally I'm a fan of AVR-8 which has 32 8-bit registers so
| if you want to do 16-bit or 24-bit or 32-bit or 40-bit math you
| can do it just fine, it just takes longer. The biggest AVR-8
| device has about 8k of RAM and about 240k of rewritable program
| ROM. Those are on different buses so it can suck down an
| instruction at the same time it transfers data, and clocked at
| 16 MHz it beats the pants off any of the 8-bit micros of 1980.
|
| 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...
| Joker_vD wrote:
| I've looked at F8's ISA reference and it has _lots_ of
| instructions to support 16-bit numbers, including all the basic
| arithmetic and bitwise operations, plus loads /stores/pushes
| and pops. It's almost a 16-bit ISA, actually.
|
| 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.
| dfox wrote:
| This seems to be meant as pretty much 8051 replacement. 8051
| cores are duct-tape of the modern computing and in almost
| anything, while 8051 is not exactly C-friendly architecture.
| flohofwoe wrote:
| OTH 8-bit floating point types are so hot right now in the GPU
| world:
|
| 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).
| AlotOfReading wrote:
| A minimal 16 bit system is something like a XAP [0] at 3,000
| transistors. Incidentally, also a terrible architecture to
| program for.
|
| I don't think any "real" x86 processor from the 286 onwards
| had under 100k transistors.
|
| [0] https://en.wikipedia.org/wiki/XAP_processor
| artemonster wrote:
| Oh, looks interesting, lets check out the architecture
| documentation! _searching..._. Ah, found it: Makefile and
| manual.tex... Yeah, f off :)
| Joker_vD wrote:
| While I agree that repos with docs should have "releases", in
| GitHub parlances, with compiled PDFs/ebooks/whatever, building
| it yourself is as simple as 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
|
| The future is now, old man.
| artemonster wrote:
| I know how to do it. The sheer audacity that I am being asked
| to do it rubs me the wrong way. Once I am on my phone, then I
| am on my work pc with no rights. Then by the time I got home
| i have lost my interest
| PhilipRoman wrote:
| Out of curiosity, what would you prefer? I wouldn't say tex is
| my all time favorite format, but definitely better than 90% of
| the documentation solutions out there.
| artemonster wrote:
| A clickable PDF. Dont ask me to jump through loops and hoops
| to read about your stuff
| dmitrygr wrote:
| There already is an 8bit architecture designed for C: AVR
| v1ne wrote:
| Yep, and AVR-8 has excellent documentation, is easy to learn
| and I find really fun to work with.
|
| 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.
| nxobject wrote:
| There's also an 8-bit architecture designed for emulating
| 32-bit architectures: AVR!
|
| (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!)
| stevefan1999 wrote:
| 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.
| codr7 wrote:
| I'm pretty sure the second there is a significantly better
| alternative that offers the same flexibility and control,
| plenty of people will jump.
|
| Same for C++.
|
| Assuming everyone else is an idiot leads nowhere worth going.
| ff317 wrote:
| https://ziglang.org/ is a solid future C-replacement, IMHO.
| There's pretty much no downsides and all upsides from a C
| hacker's perspective. It just hasn't reached 1.0 yet!
| flohofwoe wrote:
| Zig is a nice language, but from a 10000 ft view it's not
| fundamentally different from C (thankfully) - at least from
| the CPU's point of view. Any hardware that's a good match
| for C is also a good match for Zig.
| flohofwoe wrote:
| Newly created programming languages specifically tailored to
| GPUs (e.g. all the shading language dialects like MSL, GLSL,
| WGSL, HLSL, ...) are not limited by backward compatibility
| restrictions to C - and the execution model of GPUs is very
| different from traditional CPUs, yet all those languages turned
| out not much different from C extended with a handful new types
| and attributes.
|
| 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).
| tengwar2 wrote:
| :%s/essential/moderately desirable/g
___________________________________________________________________
(page generated 2025-02-20 23:02 UTC)