or say geeks integration or something like that.
But in general, those APIs won't be used
by Goblin's programs for the most part.
But we will provide the compatibility.
Because we already started the next door.
All right, very good.
Thank you very much.
That's the, that thing.
Hi, can you hear me?
Yeah, right?
Okay.
How many people here is aware of the problem
of the bootstrapping?
Place hands.
Okay, that's good.
That's better than I expected.
That's fine.
So, first of all, this is a disclaimer.
I wrote everything I'm going to talk about in my blog.
And also I give a talk the last year.
So if you really want nitty gritty details
about the bootstrapping process, go there.
This is not going to be a very technical talk.
Okay?
It's going to be just an explanation of what we did
in the RISC-5 world in the bootstrapping process
on gigs and live bootstrap.
So, this is me, right?
I'm a telecommunication engineer,
and a freelance programmer, and I work a lot in gigs.
So maybe you remember me from the last year.
I gave this talk.
There we explain the bootstrapping problem
is you have more interest on that.
There's more slides on that and a,
quite a long explanation of what we are doing and why.
So this is the context.
I work with NLNet.
The last year, so they paid me literally to make some work
in the bootstrapping process.
I back ported some support for RISC-5 to another GCC
to the 4.6.
And also I back ported support for tiny GCC boot,
which is a fork we are maintaining
in order to be able to bootstrap the compilers.
So I'm going to talk a little bit more about this later.
So this was explained in the last year, so that's nice.
So this year, I decided to continue with this project,
but it was completely burnt out, and I needed help
because people always helps, right?
So I added more people to the project.
These two are most, the ones that took more work in this port,
and they literally gave me the energy to continue, right?
So Andrews is very interested in the project
because he works in Live Bootstrap and Stage Zero,
which are projects that are very related with this.
We are going to see them later.
And Janneke is the author of MES
and also the maintainer of tiny GCC boot.
We are going to talk about that just now.
So let's see in pictures, right?
There are some colors, but I'm going to point.
So if anyone has problems with the colors,
it's no worries.
So this is what we had before my project, right?
We have Stage Zero POSIX, which is source code, right?
Then we built with that, we use that to build MES,
and with MES, we try to build a bootstrapable tiny GCC,
which is a fork of tiny GCC, but that is easier, right?
The C code it uses is simpler to be able to build.
Then we try to build tiny GCC,
then we go for a very, very old GCC from the 90s, right?
And then we go for a modern GCC,
maybe with many steps in the middle in all of the parts,
and then we try to compile the world with GCC.
So now the colors.
All this is the current bootstrapping process
that is in live bootstrap.
We have it in Geeks too.
So this just works, but only in X86.
So I'm working in the RISC-V port of all this.
So RISC-V, the status of the RISC-V part
was these two parts of the top,
they were already having some RISC-V support.
It was working pretty fine, okay?
The bootstrap of all tiny GCC had zero RISC-V support.
Tiny GCC, it was supposed to have some RISC-V support,
but it was worse than we thought.
GCC didn't have it because these are very old GCCs.
They were written before RISC-V was invented,
so no support there.
And the modern GCC that supports RISC-V
is the 7.5 version.
Then the world, some things support RISC-V,
some others don't, but that's not my problem.
I'm only working from here to the top, so don't worry about that.
So after my effort, my previous effort,
I took the support from this GCC,
which is kind of a modern GCC, 7.5 is not at all,
took that to GCC-4, this is a note here,
this is written in C, this is written in C++,
ha ha, I had a lot of fun there.
And also, I took the support from here
and I moved it to this one, right?
So this was also, I think it's like a 10-year difference
between these two, so the APIs, the internal APIs changed,
many things are very difficult.
GCC is horrible to read.
Maybe here there is the maintainer, I'm sorry,
but it's really hard to read this project, I'm sorry.
So at the time, we didn't know that this was orange,
this is not fully supported in RISC-V,
we thought it was completely green, fantastic,
no, it's not, so problems there.
And this one, I finished this backboard
and I thought I was going to have issues with this,
but it happened to be pretty much okay,
so nowadays this is way greener than we thought
at the beginning, so this is before what we did this year,
right?
Starting in June, we started working on this
with the people I already mentioned,
and now we settled to this point
and this is already in LiveWoodstrap
and we have it in Geeks, in Core Updates branch,
this is already upstream to Geeks.
So until here, everything works, so thank you very much.
Good, so this part we already tested in Adobe Machine,
this part we tested in Adobe Machine in real hardware,
in RISC-V board we have, and this also works,
this GCC 4.6 compiling stuff for RISC-V.
So a compiler that was written before this architecture
was invented is compiling to that,
so that's also very nice, we have it, yeah?
So this is more or less what we did.
So there are problems though, the arrows here
are still red, I don't like that.
So why are they, they are still red, why?
So TinyCC request some changes in the C library
where we have here, so we need to change those
to make them work, right?
Also, the old GCC requires make,
which I managed to compile the other day.
And it requires some other stuff, right?
It requires patch, we also need G-SIP,
which I didn't have the time to compile,
and some other things.
So also this jump is going to be kind of complex
because GCC really has a very complex build system,
maybe you tried, it's a really complicated thing, right?
So it should just work, but it probably won't.
So, questions now, and I have some extra slides for later,
but anyone has any question?
No?
No, okay, extra slides.
So we had some limitations in the backboard we did,
and this is what we have been playing with
since June this year.
So when I made the backboards,
I was working only using a cross compiler.
So if you're working on a cross compiler setup
from x86 compiling stuff for RISC-5,
you are going to have a lot of problems, why?
Well, first of all, you have the bootstrapping problem
we're going to show in the next slide.
And also, I was using G-Lipsy,
which is a very powerful Lipsy,
and we don't have that in the bootstrapping process.
There's no Lipsy, so we need to play around
with all the stuff we have, like Meslipsy,
which is written by us, so it's probably not going to be great.
We're not that good after all.
So also, there's the RISC-5 assembly issue.
In TinyCC, the RISC-5 assembly they have,
it doesn't use the same syntax as gas does.
So our library was expecting a gas syntax,
and this doesn't provide that.
And also, it doesn't support the extended assembler.
So we can't really mix very well C code with assembly code,
and we need to play around with all the variables,
protect them, and make all those things
we have to do by hand, and that's a problem.
So this is how TCC is built.
The graph I showed you before is just a lie,
but it's a good lie.
So this is how it works.
We first build Meslipsy,
we take some part of the code of the TinyCC boot,
and with that we build this one,
and with that we build this one,
and we change the flags of the code
so we add more features.
With that one, we build another one.
We take the code again, we build another one.
We do these six times, and then,
of course, all these steps will need to work.
There is a lot of bash, bash glue code in the middle
to make all this happen, and you have to fix that too.
And fixing very old bash code we did for this kind of thing
is even harder than reading the compiler, but anyway.
So then we check that this one and this one are the same.
In the binary level, they have to be exactly the same.
That means the compiler is not adding new stuff,
so we have settled.
So we can just continue with those.
My colleague, Andrews, already tested
that we are already settling the fourth iteration,
but we do six because we did six
and we don't want to change.
They did.
In live bootstrap, they only do four, right?
So problems with GCC.
I only tested, again, as a cross compiler the last year
because I only wanted to see that it was able
to compile things for RISC-5.
And again, I wasn't doing the bootstrapping process of GCC.
GCC does internally, when you build GCC by hand,
they do a similar thing.
They take all the code base of GCC,
they create a previous GCC, then they take the code,
they compile it again with the GCC they created,
and then again, and then they compare.
So I wasn't able to do that.
And I didn't work in the C++ support either.
So the work we did, we started with tiny CC boot,
and we started working on top of it.
We had to read, we spent many times, many nights,
debugging crazy things, and also because
Andrew has a real job, not like me.
So we need to coordinate to do these kind of things.
It was really hard.
So also we don't have debug symbols
because our compiler is very simple,
and implementing that takes a lot of time,
and it's difficult.
So we do all of this like one hand here.
It's very hard to do with one hand and also blindfolded.
So, but we managed to do that.
I wouldn't have the energy to do this without Andrew,
so thank you, Andrews.
Also, well, these are some errors,
I explained them in my blog,
then or later you can come and ask me about them.
This is a lot of fun because the body was never executed
for any X, it didn't matter.
This happens a lot in RISC-5, sorry, in TCC,
and in our backend, it exploded.
Why?
Because this is undefined behavior,
and all the compiler was based on this.
So they used these to clear bits,
and we needed to check all the appearances of this
and fix them all.
So, funny stuff.
Yeah, and many other things we found a lot.
So you can read about them there.
There's a very long explanation about all of that.
Yeah, so we finally managed to build it, we have it,
we have a recipe in Laboodstrap and in Geeks.
Yeah.
So, about mess.
We had all the stuff in mess because it was affected
by our work in TCC boot,
so we started fixing stuff.
Why there were errors in mess?
Obviously because we were not perfect.
Yannick almost is, but still.
We had some issues because the bootstrapping process
of I386 didn't use all the C constructs
that appeared in RISC-5, so it started fixing many things,
like the switch cases, they were wrong.
The initialization of the structures
were initialized to 22, I don't know why.
So, these kind of things.
And I am almost there.
Well, TCC is the same.
We finally managed to compile it in a different machine,
with C++ support, all of that.
Okay, fantastic.
So, last words.
So, people is important.
If you're alone, you don't work well.
I had issues, I was like completely depressed, burnout.
So, bringing people, giving me energy,
the knowledge I lack, and emotional support, good stuff.
Also, money is important.
You all know this, but if you're getting paid,
you work better, you don't feel stressed,
you are not just trying to eat the next day,
to just get paid, do your work, that's fine, that's good.
You can focus.
So, thank you to Andrews, to Janneke,
also on the net for the money.
And you for listening.
Thank you.
And it's our question.
I don't know if we are in time.
We have time for questions.
Okay.
We'll set off to the data.
Questions?
Regarding both the people and the money,
will you be continuing your work?
Yeah, so regarding money, the people and all that,
will I continue with the project?
I'm not sure.
I'm not sure.
I don't think I'll be doing it.
I don't think so.
I don't think so.
I don't think so.
I don't think so.
I don't think so.
I don't think so.
I don't think so.
Will I continue with the project?
We have funding and stuff to do still,
until I think the project finishes in one year.
So we're starting in June.
So until June, we're going to continue.
I'm still working on it.
I have, most of the budget is not spent
because we need to finally combine until GCC.
So the project is to...
June, we're going to go.
Yeah.
More?
No?
Yeah?
I was listening to a ZIP project.
It's used an interesting approach to this,
where they use WebAssembly.
So how is it working?
Your project was you use the latest GCC
to compile GCC to WebAssembly.
And then your problem on risk five,
is you just need to bootstrap a WebAssembly runtime,
which is very small, to run GCC on risk five.
Do you think this kind of approach might work
in your environment, or is that just
very specific to SIG's problem?
So the question is around how the people at SIG
resolved their issue with the bootstrapping.
And they are yet using a WebAssembly environment stuff.
And if we can do the same, or if that makes sense in this.
So our idea of this is that we want to build everything
from source in your machine.
Why?
Because if you get a Linux distribution,
you download a Vivian or whatever from the internet,
you are getting a lot of binary blobs.
So the idea is just to get the source.
So that's not very compatible with the approach
you are proposing, because you won't get sources.
You will get some kind of a wasn't thinking.
And that's not easy to inspect.
So what we have here is that you can inspect everything,
starting from a very small binary that
is written with comments, so you can read the comments
on the binary that the bootstraps everything.
So the idea is philosophically different.
And I'm a little bit upset with the problem with SIG,
because I really like the language.
And now adding this wasn't thinking in the middle
is making us very difficult to add SIG to Giggs,
because we will have this kind of binary in there.
And we don't really like that, because we want everything
to be sourced.
But yeah, the idea is good.
But philosophically, it doesn't match with what we are doing.
Any other time for another one?
Piot?
Yeah.
No more?
OK.
Right?
Thank you.
Thank you, guys.
You have one, Piot.
OK, you have one.
Sorry.
What about the arm board?
The arm.
I don't know.
I'm not sure.
Maybe you should ask another people here, like Danny.
But everything we are doing, the RISC-5 board we are doing
is 64-bit.
It's going to affect all the other 64-bit architecture.
So we are doing advances in X, 66, 64, and ARM,
and all things.
So yeah.
Yeah, shoot.
Shoot.
All yours.
Yeah.
So for the arm board, we got as far as compiling tiny CCC,
and that one compiles an old GCC.
And that old GCC has a lot of problems
that are well known.
Nokia had a lot of fun back then with these bugs.
And so we are waiting for you to update GCC,
and hopefully that fixes everything.
So.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.