I think we can start.
So, hello, my name is Fonselli Varian, and today I'm going to present to
a risk-five hardware is here, what about software.
And as a first disclaimer, this will be a very, very opinionated talk.
So, there's not much science in this slide.
Just my personal opinion from my empirical work on risk-five.
And so, to start on, I'm a senior software engineer at RQ5 CPU.
So, in the last two years, I've been creating the risk-five-unified DB project,
and I've contributed to Zyfer, including the AIA driver that's actually health-merge,
health-not-merge, but we'll get to it.
So, yeah, and I've been bringing up the software stock for a lot of different
risk-five cars inside the RQ5 family, so I had to play with all these different projects.
And so, risk-five hardware is here.
I think a lot of thoughts already went by that today, so I'll quickly go through there.
So, like, we have a lot of products coming out in RQ5.
I don't know if you've seen deep computing laptops, but those are pretty awesome,
and they do run, right?
So, we have products, and Western digital and video, they both already acknowledge
that they are using risk-five cars inside their products.
In Finian also came out and showed us an automotive platform with RQ5 products,
which is pretty nice.
And on the other hand, there's a lot of open cars, a lot of startups working on
risk-five, and well, I have a couple of boards here, but in reality, there's many, many more.
So, this is actually very, very, very small.
I went to risk-five landscape, and I got the full list.
It looks kind of like this.
So, yeah, it's pretty extensive.
I don't think I can go over all the names, but this really,
like, this really showcases how big risk-five is growing.
And if you're like me and you leave briefly,
risk-five is always on your mind, and you're algorithm-sketched to it.
At least for me, like on the way right now, what I feel like is that
I'm constantly getting born with different news involving risk-five,
a lot of different things happening in risk-five.
And this is not just an impression, so it seems like
some smart guys went and did like a market research on risk-five,
and risk-five is expected to be in over 16 billion SLCs in by 2030,
which now is like four years ago, so, well, four years in the future.
So, it's pretty close by.
And so, it's supposed to be in all these different markets,
we'd actually like a very fed by in the chart.
Well, part of the chart, right?
And so, yeah, in very, very, very different markets,
and with a really big presence.
And so, like, I think as other people have told today,
and what this data really shows is that risk-five hardware is here.
Like, this is a statement that there's not much you can say against it.
And the question I'm going through today is,
what about software, right?
We've seen couple talks talking about software in risk-five,
and they were more in debt than I'll go here.
But what I really want to strengthen is that,
the ecosystem will at some point start deciding the adoption,
because, well, there are some industries that care about the ISA,
and so, they'll just move because, well, it's risk-five,
it's open, and like, if you're building a space station, well, maybe.
You prefer to have some openness.
But in reality, most developers, and especially most consumers,
will not really care about whatever ISA you're running.
So, your ecosystem really needs to be ready
to accommodate all these people into it.
Otherwise, developers, like, face without an operating system,
ready will be very against going to risk-five.
And consumers will just see what final software exists
and how well that software runs.
So, we have to have all those layers ready,
so that we get mass adoption in risk-five.
And, like, here I have a fun story.
This is a personal story.
Two years ago, I had to buy laptop,
and I had an X86, the good old X86 laptop,
and the normal laptop.
And even now that RM has, like, 30 years or more of a market share
or in presence, I actually chose X86,
because I do a lot of weird things in laptops,
and I knew that at some point in my journey,
I will find some package that was not built,
and I will have to go and build it myself or find some extra
two hours to debug whatever was going on.
So, if we don't want to wait for next,
I think risk-five is 11 now,
if we don't want to wait for next 19 years,
to not follow these mistakes, I think we should be prepared.
And so, there is also a point in risk-five,
that is very against this software ecosystem maturity,
to what I call hardware dispersion here,
but well, you can call it a lot of different things.
This file is very, very modular and extensible,
and that's a good thing.
That's why everyone is adopting risk-five.
But, as you know, like, if you're not familiar,
risk-five is actually three different ISAs.
It has, like, R32E and I, and R64E,
which is normal, and there's an effort that,
but with those three basic ISAs,
there's, like, more than 70 risk-favings extensions,
and then there's a lot of implementation,
defined parameters that you have to accommodate
in your software as well,
then you have custom extensions
that companies create for very good reasons,
but it's also something you have to accommodate
in your software,
and then it's very open and very extensible.
So, you'll see an endless creativity
of people doing different things,
and then you'll need to try to accommodate
them all in the same software projects,
which brings us to the question,
what about software?
And, well, earlier this year,
we saw some controversy in the kernel mailing list,
right? And, unfortunately,
this is not the most fortunate event.
I'm not going for it, but it happens,
and we saw, why not going crazy with R64, right?
And I think, although this is somewhat controversial,
I think if you go down and you look,
why is this reaction happening?
I kind of understand where it's coming from, right?
And this is what I'm going to talk about next.
My own negative opinion on R64,
well, not negative, but the word that it takes.
And so, I think where that really comes from,
it's R65 means supporting combinations.
As we saw before, it's at least the three-base,
well, the three-base, as a times,
70-plus extensions, because they're always growing.
And then you have to define number,
which is implementation parameters,
that I don't think anyone has ever counted.
But I think there's more than 1,000.
So, if you multiply this,
it's like 200,000 different combinations
that you can have to accommodate in your software.
And this, as I showed time and effort,
and then we go and we see that,
well, why does this agree with these in some,
some extensive, because beforehand,
he had told about the millions of silly configuration issues already.
And this really stem from these hundreds of thousands
of configurations that we can have with R65,
which is awesome, but comes with a cost.
And so, R65's trans truly is its flexibility,
and this flexibility fragments the ecosystem,
but obviously, I mean, most of you guys here already know about this,
there is an answer to this portion.
And it is the risk file of profiles that we've been hearing about,
and in case you don't know what these are,
R65 profiles define a baseline,
like a fixed-base either,
a required set of extensions,
and fixed choices for ambiguous implementation options.
So, there is no that end was extensiveness,
or at least there is a baseline
that everyone has to follow for software compatibility.
And so, this reduces a lot of reliability across implementations,
and this enables portable software.
I mean, this is kind of a term that we've tried to reach many,
many times, but at least it will allow you
to download the compliant binary to ERCPU and run it.
And this allows consistency to two shades clear hardware targets,
and essentially, you can trust your hardware,
and you can trust that it will run X or Y project.
And so, profiles really enable compatibility,
and this is one of the very, very good things,
I think, is going on in risk file,
and I'll go over what these profiles are.
So, there is mostly three profiles,
I think only RVA and RVB have been ratified by now,
but RVA is your Linux reach software,
so where you run your Ubuntu,
which is probably for server and even for laptops
that will run this RVA-23,
then there's RVB for a little bit smaller cores
that will run the build router of the Linux,
and then microcontrollers, obviously they also need to agree.
Again, depending on the markets,
there's a lot of different things,
so there's a lot of different intricacies,
for example, automotive.
They really almost do everything by themselves,
and part of software is stuck entirely,
but if you want the laptop,
you really need this software compatibility to happen.
And so, here I'm going through what I believe
are the most basic parts of the software stock
that we need to have ready in risk file,
so that we can then build on top of them.
So, I think first one is obviously two chains and simulators,
so like your team needs to be ready,
so that people can actually try and write software,
and obviously you need GCC and LVM otherwise,
how will you get code?
I mean, maybe for chemo, you won't need it,
but for everything else, you will need it.
And so then you need your firmware in risk file,
it is open SPI, it's pretty standardized,
everyone is using open SPI,
and then for operating system,
and real time operating system,
I got Linux and Zefer here,
I believe they are the most supportive,
they are the ones that support with five pairs,
there's of now.
And well, on applications,
well, I don't know a lot of applications about applications,
but we may never have Adobe,
that's what I feel like,
which may not be so bad.
And so, I created a tier list,
this is a very opinionated tier list,
and this is based entirely on my bringing up
of different risk file hardware,
and problems I faced,
and the big downs I had to do for some of these.
So, first, the only perfect project in risk file
is risk file unify rate of base,
as you should have known by now,
this is a project I created,
it's obviously not perfect,
it's just a venture.
But the ready projects,
I think from all the projects I've seen and used,
I never had any problems with neither key,
neither tool shins,
and even the Linux kernel,
it can always have what I need it.
On the other end, Zefer,
and open SPI,
I had to fix Zefer multiple times.
And so,
I think they do really,
they are indeed lacking,
a bit of the risk file support,
and for microcontrollers,
I definitely need Zefer,
and so I think this is now a lacking point
in this ecosystem.
So,
this next part of my talk is a bit of a practical beginner guide
towards risk file,
probably majority of people here already have contributed,
maybe some not,
and so I'll share the lessons I learned in the last couple years,
while creating an open source project,
and also contributing to Zefer mostly.
So, let's start with my own three contribution commandments,
things I learned,
I hard learned myself by hitting my face against the wall multiple times,
and so,
first one is to sheep early and small.
Second one is to make maintainers like easier.
I know this seemed like very basic things,
but I'll show some examples later on on how I messed up
or how I saw people messing this one really badly.
And then it is to solve real problems
to not drive any maintainer crazy,
because yeah,
solving hypothetical problems with a lot of everyone's time, right?
And so, starting with the first one,
I won't really suggest that if you're starting to contribute
to risk file or to a new project to release the minimum useful thing,
and not your grand vision of how it will all go in,
because well, you're reducing your risk,
it may never be merged,
and at least you wasted the instead of wasting 30 or 60 days.
And so, an example of this is,
my first commits to risk file actually were,
and how good you may read them,
but I fixed some typos,
which was of my same win for me at the time.
I got a lot of momentum,
and actually some of the typos were reverted,
because they were not typos,
so,
this was my first contribution to risk file.
But, well, then I joined Zyfer,
and I started contributing to Zyfer,
and I had the word in Zyfer,
because I was really struggling to understand it,
and this was like a Twister output,
and everyone that worked in Zyfer,
like for 10 years, newbies,
but I didn't know that the output path was changing,
and it was like a meaningful contribution,
very small, but it got merged.
And so,
now I'll show you examples of people that didn't follow this,
including myself.
Then, I parted the risk file,
advanced interruptor architecture to Zyfer,
2500 lines of call,
36 comments and conversation with maintainers,
67 times that I first pushed into that branch,
and I quit,
and I said,
well, I'll upstream these in chunks,
because this isn't ever going anywhere.
So, yeah, I faced these problems,
and as you may see,
these were three weeks ago,
not that long ago.
So, the next one is to make maintenance easier.
I think this will,
this is pretty obvious,
they will be the ones helping you,
and be kind to them.
Most of them are not even paid to maintain the project,
probably they were at some point,
maybe they still are,
but you can't really expect much from them.
Sometimes they're very fast,
but sometimes they're not,
and that's life.
And one very important thing I have to say is,
please don't push a,
I saw,
like,
I created the unified database,
and at one point there were
re-five mentorships open,
and so obviously,
a lot of those mentees started to push things
before getting accepted
to enhased their chances,
but this guy did it in quite the inverse,
I believe.
So,
he pushed several of these poor requests,
which, if you're familiar with CGPT,
this is basically what CGPT answered to him,
and he copied paste of them here,
and then,
he pushed 24,000 lines of code,
a hundred and sixty-eight files changed,
and we tried to help him,
like, there's a hundred and ten comments,
we tried,
but obviously,
there's not much,
we can do,
because he,
like,
and to give you context,
he was peaking our comments,
pasting them back onto CGPT,
getting all that code re-factor,
and then pushing a commit,
and you may see,
there's sixty-one commit,
so like,
it's going back and forth with him.
So, yeah,
please be mindful that you're wasting people's time,
and at least try to make something meaningful,
and it's my last point,
and yeah, we're back and lines.
So I think what wine is was saying with this one,
is,
and maybe not in the nicest way,
there's already so much going on in Wies5,
we have tens of thousands of configurations,
and we're trying to preemptively support something
that doesn't really exist anywhere,
and I think,
I mean, this bendooks,
I think,
hence,
that this exists,
meets some cars that have begun,
but realities,
there's not much,
like there's no one showcasing that they are using those cars,
so why are we all maintaining them open source?
And so,
this kind of shows a hypothetical use case,
that maybe was not hypothetical,
but was treated as such,
and so I think a much nicer way to,
so obviously,
this was by,
when Duke sees much more experience than me,
but if you're starting to work in open source,
I would say,
and suggest that,
like, a much nicer way to start contributing,
would be to check very small things
that you may contribute to,
and like,
check CI failures,
everywhere,
in all open source projects,
you'll see hundreds or thousands of CI,
warnings that no one has time to look after.
Go look after them,
I think that's like a very nice start,
and our soft problems,
you face as a user,
so like, there's all these boards that are,
like, I mean,
out in risk,
probably,
if you run any type of software there,
you'll find some things,
and try to understand what are the issues
that you're facing in contributing,
contribute them back,
and you'll probably help a lot of other people,
and people will like you a lot.
And so,
if I can feast you to contribute to risk,
this is a very curated list of tasks,
and this is just in Zephyr,
and in need of database,
and these are things we can work together on,
if you're interested in that.
So,
I think Zephyr right now,
in the risk of cold,
has a lot of CI warnings about different things,
if you want to go check them,
that will be very helpful.
Or if you're more experienced,
and you want to part extensions that are ratified,
and don't exist in Zephyr,
there's a whole bunch of them.
So,
so feel free to just hop in,
and definitely a lot of people will be thankful,
and will help you in that work.
And in the risk of NFIDB,
you never heard of it,
most likely,
it's a softer project to describe risk five ISA.
We have a lot of open issues,
you may start there,
but I also have this personal journey of trying to develop data
from UDB to upstream projects,
like the Linux kernel,
like being Newtills,
like LLVM,
like you know,
that's a new tool for everyone this morning.
And if you're interested in
automate some of these definitions in upstream projects,
yeah, let's talk,
and let's make this happen.
And so,
there's also a whole world of contributions to be made.
I think there's still a lot of time in this presentation,
but I'm done,
and thank you.
Thank you.
If you have any questions,
feel free.
Hi.
I wouldn't do.
I would not give too much in your presentation.