Okay, so all the few words about this small device, the compiler, starting with the quick introduction,
what it is, the reason progress and our plans for the near future.
So, this is a standard C compiler that supports all the relevant C standards from ancient NDC,
and it's the 89 also called, also C90 to the current ISOC 2020.
It's a few gaps of course here and there, but in general, nearly everything is there.
And, as I said, everything relevant for so small devices is there.
It can be a freestanding implementation that's what you'll typically use,
it could be part of our student implementation.
It's a supporting tool included, a sampler linker, and simulators for the architectures we target.
It works on many host systems, or your typical, let's say,
you're using the heart or new Linux or whatever it will work.
And we target a lot of right-bed architectures, and have unusual optimizations that make sense for these architectures,
that you won't find an LLVM or DCC.
We just had a release a few days ago, while we usually do yearly releases,
and they're often at the beginning of the year.
The user base consists basically of two groups.
And by the developers, we use it for small right-bed embedded systems,
and right-row computing and right-row gaming people who use it well for older right-bed systems.
And it's also often used by our team project.
So it's at the ATK, the Gameboy Development Kit, or that kid SMS.
My first on a background, however, got into it, it's also said that the long time ago,
why didn't games, was a clicker vision, video game system,
then got into some compiler, later also this little bit of games for Sega egg-bit systems.
And since it was mentioned in the previous talk,
LLVM also has a C-bag, and it's not, it's a bit outside to main project,
but it's maintained by other people, and there are a few people who, for example,
actually used Rust on the Gameboy, by using LLVM Rust front-end,
compile to C-bag-end, and feed the resulting C-code into SDCC,
and then run that on a Gameboy.
Okay, these other architectures, these are for the first part,
and there must be architectures relevant to data embedded systems,
depending on what you're doing, some of these are also over there.
The 6500 tool and its derivatives are also supported,
that's a more recent part, that too many of you are interested in,
but it's not something I personally worked on.
However, we also have this huge family of Saturday related.
The most original Saturday, these were used in the set-expectrum next.
The set-one on the Saturday, these Saturdays, here's the 90,
it's a relatively exotic one.
It's super relatively old.
It's an 80-3, it's a CPU used in the Gameboy,
then there's the rabbit, with a still in relevant use for embedded systems,
like the Saturday, but there's also some of them are also quite old,
and there's an ASCII corporation,
there are a tantrat, just in some Japanese-older systems.
Okay, so let's introduce a project,
the source that it's source for, since a long time ago,
and it's still there, we have our ticket systems there,
we have mailing lists, we have a repository,
we have a Wiki for documentation,
we have our own compile form,
that's basically distributed,
among the SSC developers,
so every night, the current version is downloaded from our repository,
gets compiled on a host system,
and then compile the large number of small test programs,
and executes it on someone similar,
and we check that one.
We run, we give it a correct result,
and in some cases we check that one.
And compile and get a correct error message as a line, where we wanted it.
It's mostly a volunteer project,
but it has actually received some external support,
that comes mostly from the embedded applications side,
so the prototype front and LLNet
have actually given a monetary support for certain features,
such as improving standard compliance,
hardware vendors, usually if this support gives us hardware,
or gives us extra documentation,
and the DFD,
that is special because the research organization,
the German one,
so if in compiler research,
you have an idea for relevant algorithms,
you probably want to do reference implementation for publishing,
while they don't care if it's in,
more, I mean,
I've worked at a university,
and I've done a compiler research,
and the reference implementation is,
in the study,
the backend of SDCC,
it's still good enough,
so technically you can get even for retro computing,
relevant things,
get funding,
software.
Okay, so what's happened recently,
while the union parameters and return types,
the same thing, that was for long time,
the main missing standard feature,
we did that a few years ago,
Then, of course, another big improvement was the recent ISOC 23 standard that we now support most of it.
And a lot of it is relevant, particularly to such small devices, such as the big precise integer types or big fields of big precise integer types.
It's really helped a lot with saving a few bits in your precious data memory.
For example, a colleague of yours has one kilobyte of data in memory.
If you want your game structure in there, you often want to use big fields.
And with big precise integer types and big fields of big precise integer types,
a lot of that can be done even better than with the old plane bit fields that we had in previous.
And we actually already had a few bits of the future C2 and C2 by standard that we will see a ratified probability towards the end of this decade.
Yeah, we have, oh, the 7th shouldn't be there.
This is, of course, the 6502 and the R100 port, which is a set 80 derivative.
But also subset of the instruction set of R1, a transcript of the subset of the set 200 and 80 instruction set.
So if you happen to want to target the set 200 and 80, you can use the R800 port and get some more efficient code in particular for multiplications.
Yeah, we also improved our optimizations.
For example, bitrotations are reasonably common pattern in C code.
Yeah, you have shift lift, left shift rate.
So that's the sum of the two shifts amount.
It's a size of the things that you're shifting.
And then people either use binary or the at the two results when they want to rotate stuff.
So we have some optimizations to recognize that because many at the same time optimizations for that.
For example, this set 80 and that they're using the set X spec from next.
So generalize constant propagation where we now can propagate information about the possible values of the variable throughout the program much better.
So for some reason, it's clear from the code that let's say the lower 8 bits of some variable all where 0 we can use that information better.
Then we were able to be formed and we've also changed the calling conventions and of course,
upsetting everyone in the process because they had to adapt their hand with an assembler code.
But still, I mean historically we've passed a lot of things just on the stack and we've made.
We're making better use of registered parameters now to improve efficiency.
So how does this reflect in code size?
I've just put up a few small graphs how code size developed over the release.
So I've used the set 80 since that's probably what many of you are interested in.
And we see a general trend of code size going down over time.
I mean, this is about 10 years of SSC development.
Dries down a classic integer benchmark with a strong focus on string C standard library string operations, which is also the main criticism people put against it.
Wets down technically a floating point benchmark 100 might not if you look at it like that it's not interesting, but it's these architectures typically don't have hardware floating point.
And floating parent is implemented by doing a lot of bitshifting bitwise or, and so on.
So exactly the stuff that everyone's doing and so small architectures.
So floating point benchmark is actually reasonably good representation of what many people are doing even if they're not doing floating point.
And here we see a similar situation for comma comma.
As a benchmark introduced by people criticising Christo and for being too biased, then they came up with something even more biased.
For the code size, like I'm using here, it's okay.
But in the end, the benchmark does matrix multiplications in its inner loop.
And if you are doing matrix multiplications somewhere on these small architectures, then the matrix multiplication in the end is all that matters for the speed set you get.
But for the code size, what I'm using it here, it's kind of okay.
Okay, so that's what happened so far.
Let's see what we want to do with this DCC.
And I hope we can do.
We see.
Okay, so in standard compliance, we want to complete this standard support mostly from the 99 to C23.
We are still missing compound literals.
Our attribute support is still incomplete.
Our support for automixes incomplete, and we don't really support double and long double.
Basically, if you use them, you get the warning saying that it's essentially a float in the background what you're getting.
And of course, more of C2 by support, even though it's at this point, of course, still very unclear what C2 by will look like.
So we will introduce additional parts to better support the rabbits.
As I mentioned before, it's at 80 inspired architecture of microcontrollers.
For the rabbits and it's at 80 we will include use far pointers, because those architectures are all still like this at 80 essentially.
16-bit architectures, but they have some mechanisms to access data beyond 16 bits without going through explicit banks switching.
But rather you have some special instructions that allow you to.
Okay, here's a 24-bit address, there's a 16-bit address.
Still a lot less efficient than you operating within your 16-bit address space.
But a bit more efficient than banks switching, so we are introducing a named address space to do that.
And all the further satellite related targets we want to introduce pointers into the IO address space.
Because on the satellite it's actually possible.
I mean for the game boy, of course not relevant, because the IO is mapped into the normal address space.
And you can just use normal pointers, you want volatile tile qualified target there.
If you're doing IO, but for a normal satellite, it's also programmed in the same plan out, especially our instructions.
But its address can be used from register so it's possible to implement this as pointers.
And we also want to introduce an improved optimizations, because of course, on those motivations you're constrained in terms of memory, both program memory and data memory.
Something users have been asking for a long time.
It's a link to the elimination of unused objects and functions.
What's the reason some users love to put functions into their C core source code?
They don't actually use and then expect us to optimize them out.
Then currently we can only do that if it's in a library.
So unused library functions, okay, that works.
But normal object files are treated differently, everything is normal object files end up in the final binary.
So we hope we'll get to that too.
We have to optimize that too.
When a spilt local variable is in the non-stack memory, that's not relevant to the satellite.
Because it's at the ATS reasonably efficient stack access.
But for the 6502, for example, as DCC by default puts local variables at fixed addresses, which means functions are non-reentrant.
By default unless you tell the compiler you want it to be reentrant.
That's not standard compliant, but stack access is less efficient on such architectures.
So most people prefer efficient access rather than reentrantcy.
And currently these local variables are not allocated as memory efficiently as we are doing it on the stack.
And for the satellite related targets, we also want to handle global variable's better.
Because a lot of the work, relevant into dealing with local variables, register allocation, and stack staff.
While the global variance also has a very rough, very risk-based query.
Okay, can we point i. Why do it?
Well, let's do that.
Well, if not, then we point hL to it.
And so on, what in reality it would often be efficient to choose depending on our operant type,
depending on the value of the registers, and so on, to use iY or hL, or even direct addressing modes in the satellite.
Typically direct addressing modes will be faster, if it's actually just an eight bit operant.
And actually that's the end of my talk today, and maybe we'll even have time for questions.
No.
Thank you.
So your set-up of architectures have all types of DNA variants, but the answer starts.
The 8080 and 85 is what we do.
Is that for technical reasons?
Well, that was no one did it.
A pattern part, there was an attempt to make an 8080 part, but I think it never got finished.
And then, of course, when you have the satellite, it's usually easy out to support an extension of the satellite.
Because while you trust there can be special cases, I'm using the additional instructions.
And you get correct code anyway, even when the new ones are not used yet, while leaving out is harder.
In that sense, the gameboy, which is a restricted satellite variant, because it doesn't have the index vectors,
because the satellite, in other reasons, traction set, was definitely harder to add support for the end of those extensions of the satellite.
How easy it is to support the complete new architecture?
Well, it was actually clear to us that depends on the architecture.
Now, basically, for support, we need to complete the new one, not related to an existing one.
You need to write your code generation state, and you probably also want people, optimizer rules,
so it's optional, but there's an optimisation, people will expect, especially in people who are experienced,
which is simply programming.
And, of course, there are certain rules, depending on the architecture, if it makes more sense to make an SDCC or LLVM versus GCC background.