Re: Smstateen for Zcmt

John Hauser

Greg Favor wrote:
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.
Actually, there's no conflict between Zcmt and the D extension.
The conflict is between Zcmt and the C extension, because it's the
C extension that defines the compressed instruction encodings reused by
Zcmt. To summarize:

Zcmt + D is possible
Zcmt + C isn't possible
Zcmt + Zca + Zcb + D is possible

Zca + Zcb is a subset of C.

We'd like to stamp out the notion that the Zcm* extensions are
incompatible with D.

However, because the RVA profiles also require C, most of what Greg
wrote still applies, if you just substitute "C" instead of "D".

Jeff Scott:
Why are Zcmt opcodes using FP opcodes?
The Zcm* extensions repurpose only the 16-bit (compressed) encodings
for D instructions, not the 32-bit encodings.

Is this a final decision by the committee?
It's not final, but a lot has already gone into choosing this tradeoff;
I doubt we can be persuaded to change it.

- John Hauser

Join to automatically receive all group messages.