expected implications of Zacas in RVA23

[sorear]

The Zacas development option is largely vacuous as specified, since there isn't a line item requiring the AMOCASW and AMOCASD PMAs for any region of memory, an implementation where the instruction traps unconditionally would be legal.

Assuming that is an oversight, does the Zacas development option intend to provide AMOCASQ or AMOCASD for main memory? The former is not considered sufficient for use by compiler developers (https://github.com/llvm/llvm-project/pull/77814#issuecomment-1894198154).

[ved-rivos]

The profiles should require AMOCAS[W|D|Q] PMA support for main memory when Zacas is supported. I believe this is missing in the RVA23U64 specification.

On the trap-and-emulate question, a trap-and-emulate scheme is allowed to be slow but not incorrect. An implementation that does trap-and-emulate would claim the relevant PMA for the memory where it emulates the operation. However, a trap-and-emulate implementation that does not provide the AMO property would be a buggy implementation and not conforming to the ISA specification.

[sorear]

I meant trap-and-die, not trap-and-emulate.

[ved-rivos]

I meant trap-and-die, not trap-and-emulate. I misunderstood.

We would want to have a Ziccamoc under development options: Ziccamoc Main memory regions with both the cacheability and coherence PMAs must support AMOCASQ when Zacas is implemented.

[sorear]

That answers the main question, thanks.

Do you also expect to have a development option along the lines of

Ziccda Unmasked unit-stride vector loads and stores with vstart = 0, whole register vector loads and stores, and floating point loads and stores are single-copy atomic if they are operating on a 2*XLEN/8-byte region of main memory with 2*XLEN/8-byte alignment

(This could be simplified for RVA23 since we assume RV64 and !Q.)

?

[ved-rivos]

Ziccda Unmasked unit-stride vector loads and stores with vstart = 0, whole register vector loads and stores, and floating point loads and stores are single-copy atomic if they are operating on a 2XLEN/8-byte region of main memory with 2XLEN/8-byte alignment

A single copy atomic 2*XLEN/8 load/store should be a separate ISA extension and should be discussed separately as it would not be a profile defined extension. Profile defined extensions are used to constrain optional behavior in specified ISA but not specify new ISA behavior.

[sorear]

Profile defined extensions are used to constrain optional behavior in specified ISA but not specify new ISA behavior.

I see this as basically what Ziccif does, defining atomicity behavior of a standard execution phase that isn't explicitly called out as optional in the base specification.

[kasanovic]

Original issue closed with https://github.com/riscv/riscv-profiles/commit/db49fccbe84705598af772d1056fa176af602132. Please open separate issue for new extension proposal.