Okay, hi, okay, so yeah, my name is the Phoncelivator, and today I'm going to show you
risk-5 extension parting without the boring part. And so, first of all, like I've been working
in hypervisors, and I also work at art-5 CPUs at synopsis, and so I've been mostly working
on operating systems and also some part of the toolchain, but most importantly for this talk,
I sit next to a GCC engineer and I hear him cry a lot about how this specs change. So,
I try to make his life a little bit easier, and I'll try to show you how. So, so today we're going
to go through what are the challenges that the risk-5 ecosystem currently has, and it's specific
location, then we're going to showcase the risk-5 unified EV, which is how we're trying to solve this,
and then we're going to show some practical use cases of binutiles and chemo. So, starting with
these challenges with the risk-5 specification, I hope that by the end of this section we agree
that these are growth challenges, but still they exist and they're very annoying to deal with.
So, currently the risk-5 ecosystem relies on multiple disconnected specifications. The most
known ones are the isomanial, obviously, and this is what most people look into, but there's others,
like the assembly manual is the only source for pseudo-instructions, and then there's even
risk-5 upcodes, which has all the machine readable description of instructions, and then there's
sale that has like these foremost specifications that you turn into when I assess, and it's also
in some way part of the specification. And more than this, when you're developing, you'll need to
look specific things about other external things that are not the ISA, and these are interrupt
controllers, these are MMUs, and all these specs, leaving different repositories that you'll
need to kind of search and try to dig your information on your own, which is very annoying.
And when I was in my journey of doing this, I realized that trying to connect this and create
a mental model was for me very, very hard, and I was very, very confused. And so,
and so I started to dig a little bit more, like, why is it this so wrong, and why is it so hard
for me to grasp all these different manuals, and what not? And so, I realized, well, the ISA manual
is just like one big chunk of text, text, that's ASKIDOK, and that also has many other problems,
and just searching information. It also has problems of, like, how do you verify that
information is actually correct, because it's just text, right? There's no way to verify anything,
and then, how do you even diversify, because there's PRMs, there's TRMs that need to be made out of this,
and are you going to copy paste the spec? Well, that's what people do, but I think that's not the
best way of doing this. And so, then there's RIS5, OPCOT, the STC's machine readable, and it has
all the instructions and pseudo instructions, or most of the pseudo instruction, but in reality,
it's not very complete, it doesn't allow all pseudo instructions, the format itself doesn't allow,
and then RIS5 has this thing called implementation options, in which some parts of the spec
change depending on how you want to implement it, and RIS5 OPCOT doesn't allow you to describe this.
And so, yeah, you can really rely on these for any testing that are not including verification,
and so, it's not super complete. And I decided to understand, like, why is it like this?
RIS5 is growing and growing so hard, and so, why do we face so many problems in this specification,
which supposedly is the first step, the first stone, right? And reality is, RIS5 was first,
the AI's manual was first published in 2015, and it had five extensions. Now, 11 years later,
it has more than 200, so there's a big size difference, and even RIS5 OPCOT, it was created
even five years before the spec was first published. You can even see here the first committee in
July 19, and it was refactored, but not fully refactored, and so it also went from five to 200 extensions.
And what I see with this is that the infrastructure in which we are writing the specification
was completely outgrown by the size of RIS5, from five to 200 extensions, and then to all the other extensions.
So to summarize this, so the information exists in disconnected repos, and it's very hard to find
it, sources are sometimes not official, like the assembly manual is not its community
maintained, so it's not an official ratified manual of RIS5, and the data is completely reliable,
and there's different sources for the same data. And then sources of truth don't encapsulate all the
information. And then I took a look at the tool side, but I do in my day-to-day, and I realize,
well, we have all these projects in which we use RIS5 data, and this includes like the kernel,
kimo, camp5, the Knutoolshain, go Zephyr, and well, well, VMS in the afternoon, right?
But all these projects have the same information, and what I realized is, if in one side, we have the
information, if in one side, we have the information, and that's very hard to find this information.
In the other side, we have all these projects that have the same information. So thinking about it,
someone from each of these projects has to go through the same pain of looking at that
information and losing a lot of hours in their lives, trying to figure it to their own project.
So let's say the kernel, or let's say even the goal-language, and then someone from the Knutoolshain,
will go and have to do exactly the same path on the same information. And I don't think this is quite
optimal, and I got an idea. What if instead of doing this all manually for all the information
and all the projects, we just picked up this information and got it in a central place,
well, with some refurbishing of the information so that it would be easier, and then we will
create some pipeline that will allow to output the information in the in the format that all these
projects specify. And this is one of the reasons that UDB appeared. So what is the risk-5 unified
database? I know database is not the best title, but well, trust me, this is just a bunch of
YAML files, it's very, very, very simple and actually quite nice to use. So the risk-5 unified
database is, first of all, we're golden source of truth, that is, there is five specification
and all of the specification, and then even a custom overlay, if you do some custom extensions,
or if you implement something extra to the ISA, then there's some tools that don't really matter,
but then there's the use cases, right? We can generate out of these documents, as I said,
different kinds of documents, but also different kinds of information for tools, and even for
AI and well, I'll showcase a little bit on the end of this presentation, what I mean by that. But so,
to understand what kind of information we have in the UDB, I put it in just a simple
table, so we have instructions and the CSRs, for those of you who are not with five native CSRs,
are control and status registers, they are just normal registers, you interact with the CPU to see
what's going on, and then there's profiles which are subsets of the ISA that people agree on to
have software compatibility across implementations, and then there's even implementation specific
attributes that you can specify for a different CPU, so different CPUs all have their own
perics and whatnot, and this is what this is about. And so, I'll showcase what this is described
for, I'll just showcase these instructions, and this is just an YAMO file, so it has these few
parameters which describe an instruction, which are basically the kind, the 9-1 name, the script
and of what this instruction is, this is just a simple ad, right? There's the assembly, and then there's
the encoding variables for it, and in what location they're in, in the string, and then you
even have this operation and sale, which is like the semantics of the instruction so that you can
generate something that is semantically valuable out of UDB, and so this is what UDB is,
it's just a bunch of YAMO files together with some tools, right? And what are the use cases we're
targeting with this? Well, first of all, we have the docs, as I've said, then there's even
certifications, so like if you want to ensure your CPU is like very much what you're saying,
it is, you can generate automatic tests out of here to run it, to run them, and then there's
tools, right? Compiler, Z-buggers, they all, simulators, they all have this information, this bunch
of the fine files, and so we can just bring up the, bring this data and just convert it in what,
what's your favorite format or the format you need it for, for example, B-neutiles, and you'll
just generated automatically and save hopefully a lot of time. And so yeah, and yeah, again, right?
But going on to UDB into development, I did a proof of concept for B-neutiles, and someone
also did this for Kimu, and I'm going to showcase them both now. So how does this, well, first
why, right? I spoke about the, the GCC engineer I hear complaining about his life a lot, and so
this is kind of the first reason I did it. So we have in Arc5 CPU cars, we have DSP extensions,
and this have lots and lots of instructions, I think definitely more than 100, and this
keeps changing. And so the first, uh, a bringing of these in B-neutiles look like this. So it was
4,000 lines of declarative code, just literally a bunch of defines and just some very small tests,
which I mean, in my opinion, this looks like a very poor guy that went through a very
set afternoon to create them, and I think he will agree with me. And so, and so, how can we automate
this boring part? Because those are not, that is just the start, but then the spec will change,
you'll have to change one line, and then the tests, and then another line, and then the tests,
and this is really just like not the work we will prefer to be doing, right? So if we change the
DB, maybe we can change automatically being new deals without going through this process. And so,
what you're trying to achieve that is exactly that. We're trying to achieve an A to developers,
and also to ensure that no one will lose their high site as well, those 4,000 declarative lines
definitely suggest. But we don't try to achieve like full replication of
being new deals, that's like very complex, there's designed decisions made by humans, and those
can't be standardized. So this is not an end-to-end solution, it's really innate so that you can
save definitely some time. And so, what we generate, well, the first file we generate is
risk5obcodes.c, which as you may see, and if you remember that Yamofile I showed, there's a lot of,
there's a lot of these parameters. They're around the Yamofile, and they're just direct correlations
between these two files, so like the name is definitely there. The class is definitely reliant on
the extension we are using, but this is a tricky one actually. Operants are there, we just need to
map them to binitials operants, and then match and mask are definitely in that encoding in Yamof,
and then there's this well-standard match, optical, and being for, well, this is binitials specific,
so it's up to the generation, but as you may see, the growth of this is already in the database.
So, there's also like risk5obcodes.ht, where you define much mask and class, we do this,
and then there's even gas tests, right? We have, well, tested, doesn't test that file. It's
all you can have, but we can generate these tests by manipulating how the operants are
valid or invalid, basically knowing what these operants are. And so here you have, you can have a
look at risk5obcodes.c that was generated out of UDB, so this is for the I, each this is based
risk5 instruction site, like the smaller amount of instructions, this is just like your basic
branches and ads and ALU ops, and so you may see that the file itself is looks very much as it
should look like. There is like here one no match in, this is because, well, binitials operants are a bit
tricky to match, and in this specific cases, I decided to be very specific that we're not
matching what we should be matching, and so you should manually change the generation to map one
to the other. And this is what risk5obcodes.c looks like. This is what risk5obcodes.ht looks like,
it's just some basic defines for the same file, this is a very reduced size of it, and then this
is what tests look like. Do you have the tests that are valid, tests that are invalid,
and this were all automatically generated out of that original database. And so on this binitials approach,
I do need help from you guys, because I mean this problem in, what comes first, the egg, or the
she can in which I've developed this tool, but I haven't fully tested it, and I'll probably
will, if you give me another year or so, and that I actually have enough time to fully test
and build binitials and new extensions, but I actually need people that can help me on this, because,
well, I'm just one guy. So if you're interested in parting extensions to binitials, please try this,
and let me know how it goes, so that we can continue to iterate, right? And so next comes this
schema approach. This was not done by me, this was presented by Rev.nge Labs, I think in collaboration
with Qualcomm by Anton Ewanson, and I'll send you a different featheriko, if my tell is correct,
and so what they did was an emulator in the loop design. They described these extensions inside
UDB, and then they automatically generated the keymo definition of all these extensions,
so that they could rapid prototype when defining an extension and go from like,
architect to functional model, and then back and forth very closely. And this is quite interesting.
There is a pipeline for downstream case, and like all these tests and semantics, and
and tiny coding keymo, these are all generated out of UDB, and if you're interested in this,
please definitely check it. Their work was very, very good on this manner.
And so what other use cases can we have with UDB? So first certification and architectural tests,
I thought I talked about it earlier, then we have like a fly assessed that integrates with
re-node as well, so this is different than the keymo approach, but this is also an instruction
set simulator out of the database, automatically generated, and then we're using it like to
for documentation inside synopsis, for like programmers, reference manual, technical reference manual,
and so on. And so,
do you mention art here, the successor of ARC, and it's now a risk file, yeah?
And so yeah, so all other downstream use cases, so people who are using risk file,
upcodes already for creating decoders in hardware and other things, so we can also do that out of UDB.
And so yeah, UDB is now being collaboratively developed. I mean, this slide was a bit
of some of these companies were acquired, but they were all working on this,
and there were a lot of mentees working on it, and now we're official risk file project,
we are on risk file GitHub, yeah. So check us, yeah, if you're interested, come see the repo,
and before we go like, if you're interested in how this UDB and think works and how it can be used
for AI, I created this small demo that is like a chatbot with UDB, and if you want to ask
it some questions, it will give you a risk file information. Thanks.
Well, we have five minutes for questions if you have any. Hey.
Well, yes, I can repeat the question. So the question was, we have had a lot of this with
C-Gen, what can this do that C-Gen can do? So I haven't been around for that long, and I have never
used C-Gen. There's definitely a lot of C-Gen tools in Arc 5 and Arc, and that were used,
and none of them were solving this problem. So maybe was it because people weren't inventive enough?
Maybe, but I'm not the best person to answer that question. Sorry.
Yeah, so the question is how did we feel the database, if it was by hand, the answer is
partially. So there was this risk file uptoed database that already had some of the information,
but it was not completely enough. We used that to first generate the skeletons, and then we
manually went, well, we had 13 mentees that we used as helps for writing that, and we manually went
on and on and feel that this database. Yes. Yes.
In your introduction, yes. A lot of IP that doesn't have any of the opcodes within the
really talk to you because it's an opcodes. So do you have the way of modeling the other IP?
So the question is, I mentioned a lot of the IP that doesn't have a lot of two with opcodes,
and I'll show this quickly. So these I believe are the non-ISAS specifications that are like,
that are things like inter-optarchy texture, and this is it. Well, the thing is, some of these things
are not directly related to opcodes, but first, some of them actually have some opcodes
relation, like the AI actually introduces some instructions, and this is very tricky, but we do
have a way of modeling things that are not, I say, only. This is a new project, so we first wanted
to get the ISA and opcodes, but yes, now we're modeling the other things, but we don't do it
functionally. So, functionally modeling, no, but describing them as they are in text and in different
attributes. Yes. Is that, I'm happy to have a model of this myself, just as big fields.
Okay, yeah, definitely, I am, yeah. Thanks. Hi. So, the question is if the spec has any incompatibilities,
from like previous versions of the spec to the next versions of the spec. Well,
actually, I don't think so. Well, I mean, our, like, I've modeled custom extensions in
UDP that have incompatibilities, but what we have is this versioning system in which, like, if there's
for example, an instruction that has different operands into versions, you can definitely specify, like,
version 1.0 and 1.2. And so, yeah. Okay, I guess there's no other questions. Thank you.
Thank you.