The use of the zcb extension may need to rely on the zba and zbb extensions.

[yulong18]

Recently, I was doing an executable test about zcb extension for qemu, that is writing a c file and using gcc to compile it into an executable file.

I found that the c.zext.b instruction can be generated normally when --with-arch=zca_zcb. However, the c.sext.b, c.zext.h, c.sext.h, c.zext.w instructions cannot be generated, and additional zba、zbb extensions are required. It means that we must use -with-arch=zba_zbb_zca_zcb.

Therefore, we want to discuss the implementation strategy or spec modification of the zcb extension, because the spec only states that it depends on the zca extension.

[tariqkurd-repo]

Hi - the spec is correct - Zba/Zbb aren't required.

It should be possible to use c.sext., c.zext. without the 32-bit equivalents being available.

Tariq

[pz9115]

In general, compiler should not generate compressed form instructions directly.

The problem come from the compressed form instruction is deal in assembler, there should have a non-compressed form instruction input come from compiler.

However, if we don't have zba or zbb, there are none such non-compressed form instruction like "sext.b sext.h zext.h" generated.

[Xinlong-Wu]

I found that the c.zext.b instruction can be generated normally when --with-arch=zca_zcb. However, the c.sext.b, c.zext.h, c.sext.h, c.zext.w instructions cannot be generated, and additional zba、zbb extensions are required. It means that we must use -with-arch=zba_zbb_zca_zcb.

The Spec has point out that

in c.sext.b section. I'm not sure dose it helps?

[yulong18]

I will try it again.

[Silabs-ArjanB]

Hi @tariqkurd-repo,

I think the confusion arises here because of the 'prerequisites' sections in the spec:

• c.sext.b states 'Zbb must also be configured'
• c.zext.h states 'Zbb must also be configured'
• c.sext.h states 'Zbb must also be configured'
• c.zext.w states 'Zba must also be configured'
• c.mul states 'M or Zmmul must be configured'

Above you state:

Hi - the spec is correct - Zba/Zbb aren't required.

It should be possible to use c.sext., c.zext. without the 32-bit equivalents being available.

I agree that we should not never require Zba or Zbb to be present while still having support for c.sext.b , c.zext.h , c.sext.h , c.zext.w. Therefore I think the specification should state 'None' as prerequisites for these instructions.

For c.mul I would agree that M or Zmmul is a prerequisite, meaning that if Zcb is supported without supporting M or Zmmul, then c.mul is not supported.

[Silabs-ArjanB]

Hello @tariqkurd-repo ,

As agreed here I will describe how we interpreted the Zc specification with respect to the remarks like '... must also be configured':

If our core is configured to support Zcb, then:

• If the core supports M or Zmmul, then c.mul is treated as a legal instruction.
• If the core does not support M or Zmmul, then (only) c.mul is treated as an illegal instruction, but the other Zcb instructions are still treated as legal instructions.
• The core supports c.sext.b, c.zext.h, c.sext.h as legal instructions no matter if the core supports Zbb or not.

The reason for this implementation is that it is really cheap to support c.sext.b, c.zext.h, c.sext.h, whereas supporting the full Zbb is much more expensive. Similarly, supporting c.mul is almost as expensive as just supporting M/Zmmul, so we are fine with this dependency, as long as it does not imply that we are only allowed to use Zcb if we also implement M/Zmmul (otherwise it prevents us from using Zcb on low end cores).

The c.zext.w instruction does not apply to our RV32I core, so I don't have a strong opinion on whether Zba should be mandated or not.

[tariqkurd-repo]

@aswaterman @jhauser-us can you confirm if Zcb without Zbb allows the core to include c.sext.b, c.zext.h, c.sext.h (and c.zext.w for RV64).

I think that was the intention - as these instructions are cheap and useful whereas all of Zbb takes more area for a small embedded core.

Can you confirm the specification here?

Thanks!

[aswaterman]

In general, it's legal to provide more instructions than a spec requires. The practical problem is that there is no name for the configuration "Zcb without Zbb + c.sextb + ...", meaning that compilers wouldn't be able to make use of these extra instructions.

(TBH, I don't think this is a terrible state of affairs, since providing Zba and Zbb can also be justified on the basis that they reduce code size.)

[tariqkurd-repo]

thanks @aswaterman . @Silabs-ArjanB so to get C.MUL you need M/Zmmul and to get c.sext.b etc you need Zbb.

So if you have Zcb and don't have M/Zmmul or Zbb you only get c.not, c.lbu, c.lbu, c.lhu, c.sb, sh

is that clear now?

[Silabs-ArjanB]

Hello @tariqkurd-repo , okay, that is clear, thanks! (We will change our implementation)

[tariqkurd-repo]

If that's what's in the spec, then please do that. I misremembered. Tariq

…

On Fri, 29 Apr 2022, 13:07 Arjan Bink, ***@***.***> wrote: Hi @tariqkurd-repo <https://github.com/tariqkurd-repo>, I think the confusion arises here because of the 'prerequisites' sections in the spec: - c.sext.b states 'Zbb must also be configured' - c.zext.h states 'Zbb must also be configured' - c.sext.h states 'Zbb must also be configured' - c.zext.w states 'Zba must also be configured' - c.mul states 'M or Zmmul must be configured' Above you state: Hi - the spec is correct - Zba/Zbb aren't required. It should be possible to use c.sext., c.zext. without the 32-bit equivalents being available. I agree that we should not never require Zba or Zbb to be present while still having support for c.sext.b , c.zext.h , c.sext.h , c.zext.w. Therefore I think the specification should state 'None' as prerequisites for these instructions. For c.mul I would agree that M or Zmmul is a prerequisite, meaning that if Zcb is supported without supporting M or Zmmul, then c.mul is not supported. — Reply to this email directly, view it on GitHub <#159 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOCTJAF5WPJGUYYV5MEF67LVHPGHBANCNFSM5UF7NMRQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>