So welcome to our 2025 Foz Dem open hardware and CAD CAM Devroom.
I am very happy to welcome you.
You got in early, which means you got a seat and we're going to be starting with a very
interesting talk on the 8-bit architecture from the SDCC.
This is a film of course, we'll be giving us an overview and I hope that this is as interesting
to you as it is to me.
So, good, please.
Thanks.
Thank you very much for your time.
Let's get to the background, click in production, 8-bit architecture, I mean,
I hope it was still relevant, because it's still not between either lower and
farbit microcontrollers and the back side of the tube is there where we have arm and wrist.
Actually, last time my body is a cyclocomputer from my bike and the took in the
part, and it had a four-bit microcontroller in it.
So this is things still exist.
Typically, sometimes I would say if you're lucky programmed and see, but there's, because
there's still plenty of stuff on the market where there's no compiler at all, and you have
to program them in a simpler.
They tend to be not that expensive, typically about a cent to a euro, just also sometimes
cheaper ones.
The better memory is in the range of about 30 bytes, to about 8 kilobytes, typically in
the system.
You have a few kilobytes of programmery, either in the form of flash or fused pirom or
similar thing like that.
There's a lot of these devices being made, yeah.
The selling for phobillion, then if one cost just a cent, you can guess the
number, the architectures, however, often not so nice, either they are like ancients,
they're like 85, that's not really a high level language, frankly, I mean, I'm talking
about, see, what the same would hold for any other high level language, which we try to use
it with.
And then there's a few popular theory architectures, that all have the strong and
weak points, but only one manufacturer and when that one goes out of business or just decides
they want to migrate their customers to their new arm line, however, their architectures
are the ice with it.
Okay, that much about 8 bit, now let's get to the small device, see compiler.
Basically, the small device, see compiler is the free, see compiler for 8 bit architectures.
Yes, there are a few architectures supported by GCC or LLVM, but most 8 bit architectures
either don't have a free compiler or it's SCC.
It's a part, current standards, I forgot to update the slide here because it's ISOC 23 now
standard has been officially released recently and we recently have been supported, just
as earlier one, the typical use of the free standing implementation, but sometimes also as
a part of the one, the support in tools for sale, the same clear linker simulators for
the architectures VisaPort, it works on like the most common host operating system,
such as the herd, and a target, of course, a lot of headbed architectures, MCR 51, that's
probably the very important one, because the 51, despite not having been made by Intel for
the case, as a river, probably nearly every one of you in this room probably has been released
one with them right now. For example, if you have a real tag network, Wi-Fi card, then you
compute somewhere, that's small, the 51 core in it. So if those real tag network has ever
get the free firm, where SCC will be the compiler, that it will be compiled with.
Okay, this variance of the 51, there's the 80 and a lot of the 80 derivatives, then we have
things like the S308, an XP microcontroller, must use an automated application, the STM8,
the current S30 architecture, the PDK is a very low-cost device, you can often get some
less than a set, even if you buy just a standard it is reviewed, there's some interesting things
there, such as the HF something like an 8 core microcontroller, the 60-bytes RAM shared by
all 8 cores, and stuff like that, and yeah, the compiler has some unusual optimization, set
make sense for these targets, but wouldn't make much sense for bigger architectures, in particular
a network allocation, because these typically higher irregular architectures. For the target
that you have in GCC, LLVM, graph-coloring, 13-star-ratches, the allocation is perfect, cause
registers are much faster than memory, and registers are kind of equal, as long as you
allocate into a register, that's what matters. On the other hand, here you have few registers,
and no, very often, no two registers are interchangeable, so it really matters, which register
very, it will go into, it will go into a register. There's two big user groups of SDCC, one
is embedded developers, firmware developers, firmware developers, and so on, and the other retro
compute, the retro gaming people, well, that's 8-bit architectures, there too. Okay, so let's
get to the lessons learned, cause I mean, I mean, as the CC developer, that's my background,
I have a computer science education, and I have some ideas of computer architecture, but the
work on SDCC really gives me an idea of what you need in a network, the architecture, what
you want in a network architecture, so it makes a good target for high-level language, because
well, you see, in the support lots of them, but none of them is kind of perfect, even
so, a lot of them have very great features and a really good architecture, so I guess a very
first point is probably the most important, you need efficient stack point of electricity
by seeing, yeah. If you want to implement C, the site forward, where you have local variables
on the stack, and you need to access, be able to access them and generate efficient codes
for accessing the stack, and unfortunately a lot of these architectures don't have it, if
you have it that 80, you can use an index register to set up as a frame point, that's kind
of okay, you have the estimate, you have the stack point of electricity with dressing modes
that you want, but for most of them you don't. Instead, you have to take the stack point,
there are the noffs that put that into an index register, every time you accessing a variable
inefficient. A unified address space makes things much more efficient. I mean, you're used
to that, maybe, from the big architectures, but in the eight bit, well, there's more to
live in. If you have an 80, 50 one, and you have a pointer in SDCC, and you just derive
from inside the pointer, what we do is we look at the bits, and then call a helper form, function
just for the read from memory via a pointer, because there's five different address bases
in the hardware, and depending on which one the pointer pointer pointer you need to do the
different instruction to read from memory, and that, of course, is a huge overhead for
any pointer access, access does help, cause what you can keep an access does not go over to the
memory, hardware multi-strading can be created for replacing peripherals. I mean, if you look
at an SDM8, it's a very powerful device, but all the peripherals are 90% of them are not used
in any given application, that's just that silicon, but they're going to have a multi-cost
up, even if you have a time-critical peripheral, you can still emulate it in software, by having
running it on an extra core, but if you want to do multi-strading, you need support in the architecture
for that, you want to communicate with the user, the script, so you want something that
allows you to, let's say, implement C at all, mix, and then they don't have it. Then we get
to the irregular architectures, as I mentioned before, no two registers are the same, the
few registers are then so on, so it doesn't work well with chantines, the graph-coloring
application, but there's three top, the composition base registers, the allocators, graph-coloring
batches, well, okay, that can handle it, especially for small number of registers, so it's
possible to generate efficient code for these. We want to make sure of 8 and 6-in-bit
operations, because 8-bit is what you use to conserve memory, 6-in-bit is what you use because
well, in and point us as 16-bit, so you need to be able to support that well too, and
here the point us should ideally be 16-bit, because if you have a wider address base, then
you get into the realm where you have the arm and press C5, then other things, no point
trying to compete with them anymore these days, if you have something, all those smaller,
you just can address everything in a uniform way, especially your program memory, where you
want to be able to keep constants, you don't want to have to copy constants to data memory
first as a start-up, because that will cost data memory, that's valuable. Okay, let's get to
some details from here, a lot of these days, with architectures, have something like call
zero types of testing, where you say you have like 256 or 128 bytes of kind of scratchpad memory
as I think is what you usually call it in computer architecture, and the point is, it's actually
not as useful if you have at least deck pointer relative, if it's racing course, then you can do
everything with your local variable on this deck efficiently, in the next pointer relative read instructions
are important, because that allows you to go through chains of structs or access struct members
efficiently, and the classic way of task architectures, namely having prefix bytes, it's an
efficient decoding memory efficiently, encoding for your instructions, I mean, this idea architectures
often are more efficient in terms of code size, then let's say risk files, risk compression instructions
or these are some things, because many instructions are actually just 8 bits, and then there's
variance with a prefix byte, that are in 16 bits to do something else, harder multiplication is useful,
it's of course expensive, there have a multi player, but 8 times 8 to 60 is not that expensive,
and it's very useful, not just for multiplications that you see in code, but also for things like
array access, when you have an array of structs of non-power of two size, and you don't want to
add padding to make it power of two, because you don't have a lot of memory, so you need multiplications
for array accesses, division on the other hand, another hardware-wise expensive instructions relative,
you can eat it out, multiply a letter instructions, help you build wider multiplications from the smaller
ones, and interestingly, there are ancient binary code decimal, so port in the hardware,
can actually be useful for converting from binary to ask you, and therefore for printing numbers,
if you don't have hardware division, so if you don't have hardware division, if you do this
of port, it's something that's cheap and actually still useful, and shift in hotels instructions
of course are also useful, although for implementing bitfields, I mean bitfields often get a bad
name, cause the compiler could add padding, and people just think of using it to make a fixed
layout, but in these architectures using bitfields just to conserve memory is also major application,
and then it's fine to let the compiler handle the details, you just want to make sure you don't
waste any memory, you have only 60 bytes of RAM in your 8 core device, you don't want to
waste a byte or two in your stocked, okay, so basically that's all about the introduction and
the lessons learned, and actually now basically where do I get, yeah, an eight 16 bit mic
architecture, irregular tisk architecture, the core will be a bit bigger than a typical risk,
but it's worth it because, in such an encoding is more efficient, to illustrate that,
this is a dual core 8 bit microcontroller, one of the things that cost only one cent from
paddock, that I boiled in California and put under a microscope, this is not much more than a square
millimeter, it's die, it's one of the biggest devices paddock makes, and we can see the regular
structure on the lower right, plus it's the rounding stuff, that's the program memory, it's accuracy
coders, so that takes up is the potential part of the whole die, so if you have an efficient encoding
for your instruction, you can go with a smaller program memory, even if the core on the upper left
gets a bit bigger, it's worth it, okay, on the other hand if you go to like very small devices like
where you have only one, or maybe only half a kilometer of program memory anyway, you don't want
on the big core, cause a few by itself in the program memory or less, so I have a sub variant of the
F8 that is a bit simplified to make the code a bit smaller, that leaves out a few instructions,
sure code size goes a bit up compared to the regular F8, but it's an option that you want to have.
So, yeah, and I started work on this a bit and I got some support from an Lnet and the I
Siro core program, so that allowed me to put quite some time into it, and well, we have a port in
the compiler, so as current SDCC release from a week ago, the ports are F8, in the current
F8 is not fully fixed, there might be some small changes in the instruction set, but current SDCC
supports the current existing software implementations of the F8, I have implementation of F8 and F8 L,
so SDCC then supports F8 L, that's a GitHub repository with a little bit of documentation
of the architecture and tutorials to put the software onto the MFPGA boards, and for example,
this thing here that counts up seconds from Siro to 31, that's running on an F8 software with
the program is written in C, it uses interrupts and timers to do exactly the second counting,
it's running on a Lnet as FPGA which is supported by free synthesis tools,
and complex, more complex programs also work, it has three-stone, vector, and comma,
benchmark, running the parser, self-test, and so on, I've also ported the F8 code, also works on
the colonships FPGA, I've started porting it to go in, there's still some issue with the interrupts,
might be because next pin also ports the experimental, but yeah, we have a working software,
we have the port in the compiler, we don't have any AC go anything yet, and the F8 L sub variant
is not yet supported, then STCC, but let's look at the current state of the F8.
Thank you, everybody, questions?
What are these two existing names?
They look cool, F8 is an old third shield, this is the first micontroller I think.
There was a fair trial, they've had it, one can call it microcontroller, but I
don't think it was actually a single chip, but the capital of it was a capital F, but actually
there's so many 8-bit architectures, it's not easy to choose any two or three character
names that hasn't been in use for some 8-bit thing at some time, or ready.
Yeah, there's lots of computer science courses that make up some sort of architecture for
educational purposes for teaching assembly, you think this would be a super boring placement for dolls,
such that it has actually all like use.
I mean for teaching, it depends, I mean for teaching very often, you do a very simple architecture,
yeah, you leave out details that you want like, there's a CISG architecture, that's of course
a lot more complicated than a simple risk thing, of course if you want to introduce CISG
in my work, but in the end, well, for real world, efficient 8-bit architecture, you need some things
that you could do if you want to go in depth into this topic, but there's a quick introduction
to computer architectures, you probably just want to leave them out and just get the basics there.
Okay, thank you very much.
Oh, one more question, do you have time for us?
I intend to do that, but I don't have any concrete like timeline or the on the next step will be
to have the F8L supported in the compiler, and this is on the simulator, because of course you can
use a very lot to simulate, but that's low, so to do more simulation, compiler testing, we also have
a different architectural simulator that currently only supports regular F8, but the F8L
subset of course in F8L program is also valid F8 program, so it would just run, but you can't
give on to detect invalid instructions in the simulator, so the next few months will definitely
still be non-ASIC work, but after that, I intend to also look into possibility of ASIC implementations
again, but of course you have to long to an around time, yeah, and you stop mid-year stuff to the
hub, and then it takes like half a year or as a reward as of a year to get things back, until you can
start your debugging, that's one point and we have this thing, some of these MPV startles or these
have relatively small space, and you're sharing with others, so we have to see how this affects
the possibilities, but in general, yes, I intend to try F8 on ASIC, okay, thank you very much,