qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support


From: Andrew Jones
Subject: Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support
Date: Fri, 8 Sep 2023 11:13:54 +0200

On Fri, Sep 08, 2023 at 10:39:45AM +0200, Andrew Jones wrote:
> On Thu, Sep 07, 2023 at 10:51:33AM -0500, Andrea Bolognani wrote:
> > On Thu, Jul 27, 2023 at 08:04:07PM -0300, Daniel Henrique Barboza wrote:
> > > On 7/27/23 10:28, Andrea Bolognani wrote:
> > > > Sorry for being late to the party, and I see that you're already a
> > > > few versions in with the actual patches. Hopefully nothing I write
> > > > here is going to be too disruptive of the work you've already done :)
> > >
> > > We just finished warming up. National anthem starting in a few seconds.
> > > Whole match ahead of us yet :P
> > 
> > Good, because as you can see I'm clearly taking my sweet time in
> > between replies :/ Once again, sorry about that.
> > 
> > > > My question would be, why should this be -cpu rv64,profile=rva23U64
> > > > instead of just -cpu rva23U64? "Base ISA plus a number of extensions"
> > > > pretty much sounds like a named CPU model to me, but I'm sure there
> > > > is more to it :)
> > >
> > > We can do what makes sense since it's a virtual CPU model anyways.
> > >
> > > The advantage of implementing profiles using a new 'profile' flag instead
> > > of using a new CPU model is that we can pile up profiles on top of
> > > each other using the existing generic CPU (rv64) which is also the default
> > > CPU for some time. Implementing a new profile would then be a matter of
> > > adding a new flag instead of a new CPU model.
> > 
> > Is there a concrete use case for layering profiles like that, though?
> > 
> > I've given a quick look to the specification for RVA(20|22|23)U64 and
> > it looks like subsequent version of each profile are completely
> > additive: extensions that were optional are now mandatory, new
> > extensions are introduced as either mandatory or optional. This is in
> > line with what I was expecting going in.
> > 
> > So, why would I want to do something like
> > 
> >   -cpu rv64,profile=rva20u64,profile=rva23u64
> > 
> > when the latter is a superset of the former? It seems that it would
> > achieve exactly the same as
> > 
> >   -cpu rv64,profile=rva23u64
> > 
> > but with extra steps.
> 
> I don't see anything in the profile spec that states we can count on later
> profiles being supersets of older profiles, which means we cannot. Also,

I just found a potential example of why we cannot. A recent mail thread[1]
stated some vendors are considering dropping support for the C extension
on "higher end" platforms. If this were to happen, then a profile may be
proposed where C is optional. In that case, platforms that still have C
could state they are compatible with the older profiles where it's
mandated and also the new profile where it's optional, whereas the
platforms that don't have C will only state the new profile.

[1] https://groups.google.com/a/riscv.org/g/fw-exchange/c/qxnKKS4jhLk

Thanks,
drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]