Good morning everybody. Hi, I'm Felix. You might know me as Felix CLC, FCLC, here
there and everywhere. Talk this morning is a fun one. There are going to be parts where
I'm being humorous. There are portions where I might be getting a little bit more serious.
There are portions where I'm going to call things very silly. Namely, I'm going to be talking
about the actual architectural implications of various portions of the risk-five ISIS specification.
I want to make it clear that my problems are with the specification, not the people that made
that specification. I want to make that explicitly clear because when I call things silly online,
sometimes people get a little bit angry. Granted, that's how I've gotten every job I've ever had,
was making people angry and fixing it, but that's neither here nor there. So the talk is titled
risk-five had 40 years to learn from. What did they get right and what they did they get
hilariously wrong? We're going to talk about a few things. Namely, the good about the ugly.
We're going to talk about the RV-64 specification more broadly on the application side and the
embedded side. We're going to talk a little bit about the 32-bit spec. We're going to talk about
risk-five compressed and we're going to talk about risk-five vector. All of these fundamental
contracts in the way that we actually have to address the machine. Because at the end of the
day, we're building hardware for people and we're building hardware so that people can actually
get things done. If we don't get the interfaces right, then that fundamentally compromises all the
software at the input, it also compromises the software at the output when it actually gets
lowered to the machine. Be that a micro-ops sequencer, be that an order core, an out-of-order core,
in a server or beyond. First, who's this bozo? I realize not everyone outside of Canada knows
the definition of bozo. I think it's apt and accurate. A stupider and significant person,
typically used of a man, that's me. I'm on-masses on as FCLC. I'm a proud known as a practical
trouble maker. My employer is AI-neco. We're open source hardware risk-five company. I want to
make it clear. I am representing my opinions. These are mine. They can't have them. I help run HPC
dot social on the side and I'm a contributor for the publication, chips and cheese, where we do
hardcore architecture deep dives for performance modeling across different types of devices.
So, where do we like risk-five? What is the fundamental premise of risk-five? I know we're in
the risk-five devrim, so it should be self-evident. But I want to reiterate the beauty of risk-five
is a concept. It's for the first time ever we actually have a true open source community driven
instruction set architecture. We have a set of specifications that allow anyone and everyone to go
through and build a chip. Be that a toy chip in academia for your first undergraduate electrical engineering
course or actual high performance designs. Be that from the likes of test torrent, from rebots,
and ease and so on. There's a bunch of vendors and manufacturers actually going to market,
betting their lives and their careers on this specification that is fundamentally controlled
by the community. That is a really good thing. This is starting to move in the direction of hardware
that is open and that is actually readable and implementable. The same way that we had the compiler
change in the 80s and 90s moving towards open source with implementations of Linux and so on.
Giving that power to the user anywhere and everywhere and giving the user more freedom means that
inclementations for specific use cases can thrive. That's really important and it's a good step forward.
It's real. It's actually real. This would have been a dream.
Now RB64 embedded is the version of the RB64 spec that is meant for embedded use cases.
It's a really weird spec in no small part because why am I making an embedded microcontroller type
system where I actually need a 64 bit machine. But one of the things you end up with in risk five
is that because anyone and everyone has a use case that may or may not differ from the original
use case, you need to support that use case. We end up with a plethora of possible implementation
spaces because it may be that someone actually does need an embedded 64 bit CPU and that's fine.
This is a fun one.
It has been said that risk five 32 especially on the embedded sizes I can't believe it's not
nips and I think that's pretty much true. If you look at the academic usage and so on where
are we actually using it and that's fine because mips feels familiar and that means people can
get to work faster. There are differences and that's fine. But it means now I have a 32 bit embedded
that has consistent, mostly support for the way that the memory model works, the way that it
does address things, the compilers, the tool change field, do a device. Which means I can go and take
my design and for the most part use someone else's risk five 32 bit core because this is an isa
an isa is a contract and when you go and implement that contract you have guarantees of how things
will work. You don't have guarantees on how the implementation may do things at a order of
versus an order course is a classical thing where my performance characterization, my visibility
of the machine in terms of how I get an output changes. But the actual underlying output itself
does not change. If I'm saying I'm doing an FMA, the answer to that FMA is consistent and I will always
get the same behavior if you implement things properly before you go through and get to the machine.
So, the meat of the discussion. What is RVB? RVB is the risk five embedded specification.
You'll see it change every few years as the committees get together and we add new instructions,
new extensions and say now we are iterating on this specification. We are adding new guarantees
for what you as the developer as a software person as the hardware person can implement with consistency.
What are your guarantees there? What's in it? Well, how do we read and decipher this?
Risk five B for basic is how I read it for embedded 23 profile. So, this is the set of ratified specification
that was based on okay what instructions are I going to have as a guarantee? You can
essentially map this to things like arm VA or arm V8 or V8.2, V8.3 and so on all the way
now to 9.4. You have consistencies and when I have my compiler and when I'm developing software
I can just add my flag of these are the profile I'm targeting and then it because you can target that
profile it also means that you can target those instructions. They're also guaranteed super
sets of instructions. So, I am guaranteed that if I'm targeting RV823 it also guarantees that I can
target everything in RV822 all everything in RV820 so on so forth. I should have been saying
to be there but it's because I never deal with the embedded spec. What is RV8? RV8 is the general
purpose risk five application profile. This is the one that everyone basically wants and has been
crying out for for years. How do we go through and have a real CPU? Something that I would be able to
put in this laptop or in my desktop or in my server. These are the application class processors
when you're designing a spec that means that you're making certain underlying assumptions
of what the machine can and will be used for and that's what the application spec is.
So, it's a general purpose-ice target. It has everything from your floats, it has your doubles,
it has your vectors, it has your compress, it has your atomics, it has your memory models
and simple things like multiplication, integer support. This is a general purpose-ice that
can use for any in all cases. It does not however prescribe what that use case needs to be.
That can be a small core that's just powering up a Raspberry Pi like device and we're seeing a lot
of those. What I would refer to as glorify TV set top boxes, which is where the chips for the original
Raspberry Pi came from. These are meant for small machines. At the same time, hey, you look at
any C, any C, the big HPC provider from Japan. They have taken their vector engines, their vector
cores, of what you should be crased out of vector computers and they're porting those to risk
5, specifically the application profile and their intention is to do an in order core with
really wide vectors. And what that allows them to do is, hey, I don't need to design an isa.
I don't need to redesign all the compilers in the world in terms of how do I support those
and how the operating systems address the machine. Instead, they can get to the work of
how do I actually extract performance from the machine. How do I make sure the compilers understand
how wide my vectors are and what are the implications thereof? Risk 5 compressed. We're going to
I'm going to start getting a little bit spicier in a second. The idea of a compressed instruction set
is very simple. There are certain use cases where code density matters. When I say code density,
remember that all risk 5 instructions are 32 bits. That is the fundamental decision. And when
you're designing a core, when you're designing a decoder for the hardware, what that means
is I guarantee consistency in the size of my encodes. But there are cases, think of I'm actually
for work right now at a cruel joke, having to write a boot ROM in the mask. That's actually going
to be printed in silicon. It turns out silicon is really honking expensive. So having instructions
that are compressed that are only 16 bits means that I can quote unquote fit twice as many instructions.
Which means I'm not going to run out of space or I don't need to increase the amount of space
on my actual lithograph, like on my actual chip. So it has its use cases there.
There are also arguments that I won't refer to as reasonable. That mean that if you're looking
at an eye cache, an instruction cache, being able to fit more instructions in there without having
to go to a design that is fully micropoded or that executes its own internal, I say its own internal
language that does direct execution of the off codes. Well if I'm storing those all in the eye
cache and I can fit twice as many instructions in the eye cache, that means my probability of a
cache it goes up significantly. That is a very reasonable argument for when and where to use compressed.
But what's the cost? So the cost, yes, that's too fast from that. So the underlying cost here
is when I think about the machine, think about the encoding of an instruction. I have two bytes.
I have 16 bits. Oh, the camera only fits here. Sorry, I thought it was the whole front.
What that means though is now if I have a set of bytes that represents an off code, the 32 bit off
code. If I take that and then I say I'm going to do a compressed version,
think about the encodings what I now put two of those instructions directly beside each other.
Because now I don't know necessarily with the front side, if what I'm executing is two
risk-five compressed instructions, necessarily, or one single 32 bit instruction because I have a variable
boundary. And this is the biggest complaint you'll get out of all the x86 core designers,
is we have to do variable length instructions because you don't know what you're getting.
Am I getting a VX instruction at EVX instruction, a classical instruction, so on and so forth?
You also have the unfortunate reality that the promise of a risk-machine or a risk-isah is we're
going to do very simple instructions that allow you to do anything you're trying to do.
We're going to try to avoid complexity. What that means though is as new things come along,
we need more fundamental building blocks. We need simple tools to be able to get the compiler to
target different new cases, the assembly programmer and so on, the interfaces. But because of this
problem of two off-codes being right beside each other in the encoding, you very quickly run into
the scenario where am I overloading an off-code? The solution to that very quickly becomes well,
now I have to reserve a significant portion of the off-code space, all the possibility is of encoding,
to make sure that I don't have an overlap. I don't have a malformed instruction being executed.
Net of net though, we only have 32 bits to encode all possible off-codes at risk-5,
could or would ever want to use if we want to keep that promise of consistent usage of being able
to stay in that 32-bit space without also having to move to a 64-bit space on the instruction off-codes side.
Which means now I actually have to go through and the committee has done this and say this entire
portion of the all potential instructions that could ever be encoded has to be thrown away.
For a use case that I don't believe is frankly reasonable. This was the meme that I made as a joke
that got me to write this talk in the first place. It's a problem. Specifically,
I think we're going to get into a little bit more of the engineering now, but my biggest problem
with the way that compressed was added is that RVA 2023 mandates risk-5 compressed as part of
the application profile. When I'm designing and when I was designing in a previous life a high
performance risk-5 core, I was we had to deal with things that were forced on us from people that
thought engineering technical decisions was ultimately a marketing and business question for risk-5
international and risk-5 architecture. The silliness and frankly stupidity of being able to say
that the way that we design the machine, the actual fundamental interface of how the machine must
and will work now and into the future for successful architecture is actually a marketing decision.
I think that offloads the reality that we have people that are giving their lives and their careers
to try to build real chips for real people to serve real use cases, and yet the interfaces that
allows us to define that machine are considered marketing plus, not okay. So architectural discussion,
non-consistent front end design and variable length decode. The way that we've made processors
fast one of many in the last decades is by moving to what's known as an out-of-order machine with
massively wide front end decodes. You get an instruction and you cement, you have when you receive
that instruction, I don't actually execute it. I receive data that is the implication that the machine
needs to run. What is the operation that you are asking the machine to provide to you?
That is what an instruction fundamentally is, but what that means is now I can decouple the actual
execution of that instruction from its decoding, and that allows you to do things like reordering.
It also allows you to do things that was brought up during the FFM Pactalk of instruction fusion,
because this is an implementation question. I can do, I can look that someone's doing a
gather and then a store. Well, okay, why am I not pipelining that? The instructions might not be
back and forth, but I can do the dependency analysis, the same way we do the dependency analysis
and compilers, to say, well, I can go and I can fuse these blocks together, I can schedule these
blocks in order right here, but I can also do the same thing for power, because when you're building
a high performance design met for mobile applications, I know the heuristics on my race to sleep.
I know that if I'm going to execute certain instructions, say on the vector side,
it takes about, call it a hundred to 150 cycles for that unit to wake up. When that happens,
that's going to burn a lot of power. So if I go and I execute a single or two or three vector
instructions or Cindy instructions, and then I execute that and I go back to move the data in the
primary part of the core, it's still going to take 150 cycles for that to power back down.
It's very easy and an out of order core to instead decide, hey, I can look at my instruction stream,
schedule all these independent instructions to be in the same block and then turn the frequency
back down. I can burn a lot less power because I'm not wasting power idle in a high power state.
This is one of the tricks we do for saving power, and you'll see this all over the place we're
now because of risk-five compressed. What it means is I have variable length input.
I cannot as a machine designer predict the way that interfaces will be handed to me.
Now trivial example is cash lines. Cash lines are powers of two, they're 32-bit aligned, right,
64-bit aligned implementation detail here, but now what happens when I have an odd number of
compressed instructions. Remember compressed instructions are 16 bits.
So now I have to have the weird, terrible case where if I have three column three compressed instructions
in a row and followed by one non-compressed instructions, because the compressed instructions by
definition cannot hold the entire encoding space of the entire machine or else we would do everything
in 16 bits, right. What it means is now I've got 16, 32, 48, but now at the 49th bit,
my instruction now has to be crossing a boundary if I have a 64-bit cash line say.
So now when I go to execute that, if I'm doing a pointer chasing pattern effectively in the machine,
now the next half of my instruction at decode stage will be split across a different cash line.
And sheuristically, 50% of the time that I have any ristified compressed instructions in that
machine, I have to deal with this. But it's not that easy, it's not that simple. Because one of the
ways we've made machines fast over the past 30 years is we've gone to massively wider front ends,
massively wider. What that means is I'll be decoding up to say 8, 10, 12 instructions at the same time
as a big, strided load. And then I go through, I do my dependency analysis, I do my temporal analysis,
I reorder them, I execute them, I retire them, and then the user gets math. Great.
But now think about that 48-bit example in the way that things can be unaligned.
Notice that now you have the case where for everything except the first port of the machine,
you now have non-known size entry ports at every single boundary if you're trying to do a consistent,
long load. So now every single portions of my decode has to be off by one or off by two,
the other way. I never know how wide I'm going to be. I also now don't know how many instructions
I'm getting. Because in the case where I'm getting 16 normal instructions, 32-bit encoded instructions,
I could also be getting S and 16 just now. I could be getting 32 compressed instructions,
which means now the delay of the entry into my front end. I have twice as much work to do on the
same load, which means my heuristics, I don't know for my instruction scheduling yet.
The natural conclusion there is let's make a bigger front end. Let's add more deco capabilities.
Let's go and amortize more space in the machine. But that's area. That's power. That's gates.
That's SRAM. All these things that are really expensive. I don't know about you, but I would
much frankly use that area and that power to go into better branch prediction or to save power
to the user and give them better battery life when they pull out their phone. These are real
and use cases. You also go and talk to the people that would have been using this because
risk fund compresses effectively thumb but worse for the people that have dealt with arm assembly.
Yeah, great. Because I care. But you do end up in the case naturally there. We're okay.
If we're implementing it, it's because we have users. Because you don't implement something for
nobody. So then if the use case was, okay arm has it, arm must have a good reason for it.
I follow the very natural following question of does arm still have thumb.
It's been defricated. This isn't available anymore. This was known to be happening before
risk five compressed was even ratified. We knew it was going away and the primary reason
to make this exist was to have feature parity with arm. So if arm doesn't care about it,
we can't find our own users that are justifying it within the spec. And the only thing that
really happened was one implementation already had it and was like, well, we already put
engineering resources into it. That's not good enough. That's not good enough folks.
So we'll come back to RBC later. Am I? How much time do I have left by the way?
15? Okay, perfect. I want to leave some time for questions.
Risk five vector. Sometimes we want to do math and we want to do a lot of math.
The point of vector is to be very similar to arm SV, the scalable vector extensions.
Let's go do the risk five vector extensions. As a design consideration,
it is a vector length agnostic design. The way the machine executes is intentionally such
that the user does not need to worry about how wide the machine is when writing code.
They may choose to worry about the size of the machine, but they don't have to.
What this looks like is I go and I say execute on this block of memory.
I'm not telling you how big that block is. Yeah, because it can be dynamic.
And I'm saying this is the precision and run these instructions.
Mentally think of it as vertical lanes. This is just like the vector process. There's a
old, which is why any season is implementing it. This says I'm going to have a consistent stream of
instructions where the same input, same type of input is always getting the same
instruction executed upon it. I'm not going to care about where the machine is. I just go and say,
great, here's some data, run instructions on it. That sounds actually really nice.
That sounds actually great, because what it means is from the open source community and the package
standard packaging community. What it allows me to do is I don't have to worry about the implementation
that my user is going to get. I can just give them code and it will run as
performantly as that machine is capable of executing. So reasonable goal, right? Why do we want,
why did this come to be as a need? Well, think about it. Right now in the x86 world,
which is where I come from, we have a case where 80 x by 12 is awesome, like truly.
But I never know if my user is going to have it. Well, I don't know if that user is going to have
it, because 10 years ago when I was designing some of these algorithms, AVX-512 didn't exist,
right? I got my timeline a little bit off there. But what it meant is I can't take advantage of the
new machine that does new things. For a use case of RVV and a vector length agnostic architectures
and design choices is in five years' time when silicon gets faster, when vector engines get
wider and bigger and deeper. Well, the machine can just automatically go and say, well,
I don't care if it's 128 bits when I was originally designed. My machine does 10 24 bits
and it can reorder, and because it's just a block of memory with no operations operating on them,
that's great. I don't have a problem. It'll just get faster. This assumes that the machine,
the way the machine's work and the assumptions you may 10 years ago are still true.
Fundamentally, because as the machine's change, as we went from in order to out of order,
in order to super scale it out of order machines, to branch predictions, the way you extract
performance out of the machine has also drastically changed. And the point I'm driving to is
the promise of it'll just get faster automatically, when you don't, when you fundamentally
cannot know what is coming, is a false assumption that doesn't actually help anyone. It doesn't
hold up to second order scrutiny. But this is supposed to be the good part. The goal is a reasonable
one, offloading complexity to the hardware. There are a lot of software people where I'm an assembly
here. I wear that as a badge of honor. I know a lot of incredible programmers that they just want
to get shit to work. They want to work on the desktop environment. They want to work on a browser,
and that's fine. The machine is there to serve them. And if this takes complexity away from the
compiler implementers, it takes complexity away from the general purpose software implementers.
That's a great and noble goal. I just don't know that it holds up to scrutiny.
It wouldn't be a risk-wide vector mention if I didn't talk about the foolishness of this article.
Specifically, SIMD instructions considered harmful by some guy that nobody's heard of.
Patterson for those in the back. This is a fundamental design decision. When you look at X86, X86 did
SSC. Well, they did MMA Max, but no one wants to talk about that anymore. They did SSC. They did AVX-1, AVX-2,
AVX-3, which never saw the light of day. Then they went to AVX-512. AVX-5-4 was really good, but it was a
mess, and now we're getting AVX-10, and that's a very reasonable standard. What is the premise of AVX?
Or if an arm's neon, is I have a fixed-sized boundary. I have 128 bits, and those 128 bits
can address 64 bits, be they integer, unsigned floats. They can do the same thing in 32 bit,
and as of recently you can do the same thing in 16-bit entries, and it's 8 bit on the integer side.
Great. I know the exact size of my types. I know the exact size of my register.
Why is that interesting? Notice earlier, when I was talking about vectors, I would keep going vertical.
Vertical pipeline, without dependency chance. Running XP. I'm running an FMA consistently.
I can go and I can pipeline that very simply. It turns out a lot of high-performance software
doesn't actually do that. That's great when you have an HPC background, and you want the number
one on the top 500 super-computer. That's not actually useful when you want to get real work done.
Because in the real work, you have dependency chains. You're doing hashes. You're doing all these
computations that have dependencies. I'm bringing all different types of data together, and I'm doing
that dynamically. I'm doing logical operators. In the case where you don't have logical, when you're trying to
do these manipulations, you make the decision fundamentally that because there are dependencies in the
vector, I need to be able to manipulate those entries. I need them to work together.
So when you're trying to do something where the machine takes care of everything, and you're just
doing linear algebra all day, you build a bloss machine, and this is a bloss machine. This is
DAXP all day all night. That's not the code we actually run. So, they're not so good part in more
detail, architectural discussion. Implied state in out-of-order machines. You can do vector-length
agnostic machines that are good. Arms SVE design is actually quite good. It's quite tasteful. It's not
my preferred style, but that's fine. We can have differences opinion, but still respect good implementations.
One of the major issues with RVP, and it was brought up during the FMTEP and Peg talk earlier,
is VMAX and so on, where your vector-length can change underneath you. What does RVVDU? RVV tells you
that DAXP shalt implement vectors of either 128 bit, 256 bits, 1024 bits, all the way up to 2K.
It also has this wild instruction called LMO, length multiply. LMO is a way to create a virtual
vector register of powers of two larger than the actual physical register. So, I can have an RVV128
implementation, and the user can set LMO equals 8, and then to software, you're interfaced into the
machine, you now have 124 bit registers. Okay, why would you do this? You would do this when you're
in a late, you're trying to amortize latency and go for peak throughput. Because what this tells
the machine is when I'm reordering my buffers, when I'm reordering my vectors, well now I can just
simply do decomposition and pipeline through, and because LMO is very large, that means my vectors
are very large, which means I have guarantees on how many instructions I'm going to run,
and the same way I was looking at the power analysis earlier, I'll be able to do batches of things
together than when I'm finished shipped them off. I can do those same tricks, but better.
It's a great idea. Until, you realize that the implied state can change,
because it's not actually encoded in the instruction itself. My vector FMA does not know
that it's operating on LMO 8 or LMO 2 or LMO 1. The machine must track this, and you have no
consistent guarantees, and I consider this a bug in the ISO, others consider it a feature.
You have no explicit guarantees on when LMO will change, which now means that when I reorganizing,
and I'm doing my vector pipelining across the entire machine, I don't know if my implied vector
right now at any given time is 128 bits, 256, 512, all the way to 2K, or if you have a 2K
native implementation all the way to 16K virtual. I have to track all of those implied dependency
states across the whole machine at all times, and I have no, because I can only look ahead so far.
I don't know what the next instruction stream is going to be. I have no guarantees on what that's
going to look like, and this is why hardware designers go mad. So, I wanted to leave a lot of
time for questions, and I'm kind of coming up to the five minute mark. So, what do we want? I want
to kill off the sea extensions broadly, but I want to learn from where we came from, and be more
willing to change opinions, if and when things don't work out. When I gave a talk on it for
easy build years ago on EVX 10, I got this amazing quote from Tom Forsyth. Tom Forsyth is one of
the architects of five. He did EVX 512. An ISO is the train tracks to which we chain our screaming
future colleagues. We have a specification. That specification is out in the wild now, which means
users are depending on it. I cannot change the semantics of the machine without a hard break.
Without telling everyone, the software you previously compiled is all gone dead dusted.
Think of what that means now for all the package maintainers, all the software developers.
Sure, it's great when all of your software is open source, but I also don't know how many people in
the room are like Gen 2's outlets that want to go and recompile everything every week for more
than new optimization flags. That's not a reasonable idea. So, then the question becomes now we have this
spec. How and when are we going to improve it? How do we learn? The first part is, I didn't put.
Rescribe is going to continue to evolve. It's an open source community driven project. That's a good
thing. As it evolves though, having more humility and being able to engage more broadly with the
industry with other instructions that's be that open power, be that nips, be that RMB, that X86,
so on and so forth. If you hit yourself, I tell you I'm being able to interact with these machines
and learn from what worked and what didn't. What were the contracts that those machines were
enforcing and where were they useful and where did they get in the way? That's what I'm actually
asking for from the broader risk by community. And also maybe the Monday morning spec meetings where
you do five hours of matrix discussions, so that's going to go away. Let's get a little bit of
annoying for those. Let's have some questions. Or did I board everyone to sleep on Saturday morning?
I'm so sorry.
What has some, I've seen some, some alternatives to the, uh, to the unique way things work,
in particular with OBV, which kind of way do you think things are going?
So the question is, you've seen, we have RBV, but there's alternatives being developed,
pushed, opened up. What do I think of them? I have to, that's a nuanced question.
The nuance being, I'm working on open sourcing and alternative to RBV right now.
And I don't want it to be super biased where I'm just saying, hey, this is the thing you should
be doing, what are you doing, not doing this, like, come on. Now, I think more broadly it's a
design paradigm question. I am a fan and almost every really good programmer I know
is in favor of fixed length packed 70, because of the consistency guarantees it gives you.
Because it means the machine can be simpler, the tracking infrastructure can be simpler,
the dependency chain can be simpler in the machine, and also me as a programmer, I can
reason about those interfaces, right? I'm not mentally offloading the complexity to the machine
in a way that I will never understand and can only holistically determine at the end.
So being able to present consistent interfaces is something I think RBV needs,
getting rid of LML, I think is a good idea, but that's out there, right? It's out in the wild.
Um, implied state is just nasty. I think vector length agnostic is interesting, but it's
more academic and it's usage than I think actual implementations. There's a reason Apple still doesn't
support SVE on their arm course, and they set up a bastardized thing called SSEE specifically
because of the way it works. Um, yeah, and there's other alternatives. I would really like a fixed
length Cindy. I would love an AVX 10.2 that's actually just in risk five. Give me good
consistency, swizzle support, give me good compression, give me masked predication, which I didn't
have time to cover predication. Um, but effectively, if you've ever heard of a mask register for
lane selection, that's what predication is, that gets a lot easier to implement when you're doing
dynamic data changes in a SIMD machine, then in a vector machine. Um, so there's lots to go.
They're probably best for a deer. So I mean, that very seriously. So as a user, the biggest promise
I make to you when I give you hardware is you give me software. I run your software. The interface,
the application binary interface, the compiler standard and so on, says that shout, not that may,
that shout support, risk five compressed, which means, is it reasonable for me to build hardware
for you to just compile as normal? The compiler determines, oh, actually, there's a reason here to
generate a compressed instruction, and then suddenly I fault. You're using compliance software,
you're writing it in ISO C23, because you like yourself. You go through with a standard
compiler that fully implement things. That goes to the machine. You hit go, you hit enter,
and it breaks is not okay. That is breaking the trust contract to a hardware and software.
Now, I think it's more tasteful if you go through and you just disable them on the command line.
You can do that. I think your code will be better, but because of the reality of
their part of the spec, I don't have the choice of not implementing them. I can make them slow,
but you need to implement them. Sorry. Thank you, about the time.
Right, thank you. Yeah, thanks everybody.