Re: Smstateen for Zcmt

Jeff Scott

Why are Zcmt opcodes using FP opcodes?  Is this a final decision by the committee?




From: tech-privileged@... <tech-privileged@...> On Behalf Of Greg Favor via
Sent: Monday, May 16, 2022 2:32 PM
To: Allen Baum <allen.baum@...>
Cc: Tariq Kurd <tariq.kurd@...>; markhimelstein <markhimelstein@...>; tech-privileged <tech-privileged@...>
Subject: [EXT] Re: [RISC-V] [tech-privileged] Smstateen for Zcmt


Caution: EXT Email

On Mon, May 16, 2022 at 12:19 PM Allen Baum <allen.baum@...> wrote:

Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp


Then my earlier parenthetical comment is relevant:  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)


Off-hand (maybe naively) I would imagine that implementations will either implement the D extension or the Zcmt extension - as a fixed choice.  RVA-compliant implementations must implement D, so this is a non-issue for such designs.  It is only non-RVA embedded designs that either care about code size reduction enough to want Zcmt and don't care about having DP FP, or vice-versa.  If there was ever such a design that wanted to support both, even though only one of the two extensions could be used by software in a given system using that design, then a custom enable/disable bit could be used by that design.



Join to automatically receive all group messages.