Ambiguity in Access Memory Command: Relationship between DXLEN, aamsize, and Argument Width

[nadime15]

The specification contains an ambiguity regarding how the Access Memory abstract command determines its Argument Width, specifically the relationship between DXLEN, the aamsize field, and the data register mapping table.

Section 3.7 states:

"The argument width depends on the command being executed, and is DXLEN where not explicitly specified."

Table 3.2 "Use of Data Registers" shows:

• 32-bit Argument Width: arg1 is in data1
• 64-bit Argument Width: arg1 is in data2-data3
• 128-bit Argument Width: arg1 is in data4-data7

The Access Memory command includes an aamsize field:

0 = 8-bit memory access
1 = 16-bit memory access
2 = 32-bit memory access
3 = 64-bit memory access
4 = 128-bit memory access

The specification does not clearly state:

1. Is Argument Width always equal to DXLEN for Access Memory?

   • If yes: On a DXLEN=32 system, arg1 is always in data1, regardless of aamsize.
   • This raises the question: Can aamsize exceed DXLEN? Can a 32-bit system do 128-bit memory accesses?

2. Does aamsize "explicitly specify" Argument Width and override DXLEN?

   • If yes: Setting aamsize=4 forces arg1 into data4-data7, even on a 32-bit system
   • This seems illogical (why use 128 bits for a 32-bit address?)

3. Are there constraints on valid aamsize values based on DXLEN?

   • Must aamsize ≤ DXLEN?
   • Can a hart access memory wider than its native word size?

The specification contains a comment:

aamsize does not affect Argument Width. #420

which suggests this issue may have been previously discussed, but the resolution is not reflected in the current text.

My interpretation is that its actually possible to perform 128-bit reads on a 32-bit system by fetching, for example, four 32-bit chunks (or however the halt handles it). The aamsize field determines how many data* registers are used. This raises the question: if aamsize is 0 or 1, does that imply we only use data0 for arg0 and data1 for arg1, and so on?

[pdonahue-ventana]

This turned out to be a more interesting question than I initially anticipated. I had prepared a bunch of answers to your questions, generally agreeing with your final paragraph. Then I found this message from January 2019 (two months before I became involved in RISC-V):
https://lists.riscv.org/g/tech-debug-archive/message/676?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C%2Caamsize%2C20%2C2%2C0%2C31326942

Now I've reconsidered my initial answers and came up with the following.

1. Is Argument Width always equal to DXLEN for Access Memory?

Yes. The abstract memory access command does not explicitly override the default DXLEN argument width. It only specifies the memory access width.

If yes: On a DXLEN=32 system, arg1 is always in data1, regardless of aamsize.

Yes.

This raises the question: Can aamsize exceed DXLEN? Can a 32-bit system do 128-bit memory accesses?

No. The spec doesn't prohibit this but, because there's no way to specify arg1 that's larger than 32 bits, larger aamsize doesn't make sense. All features of abstract memory accesses are optional (including whether to support abstract memory accesses at all) so I assume that no implementation would support non-sensical commands.

2. Does aamsize "explicitly specify" Argument Width and override DXLEN?

No. It specifies the memory access size but not the argument width.

3. Are there constraints on valid aamsize values based on DXLEN?
   Must aamsize ≤ DXLEN?

Yes to both. See the aamsize>DXLEN answer above.

Can a hart access memory wider than its native word size?

No. It also can't do aamvirtual=0 and access 34-bit physical addresses on RV32 because arg0 isn't wide enough (though M-mode software can't do such an access, either).

This raises the question: if aamsize is 0 or 1, does that imply we only use data0 for arg0 and data1 for arg1, and so on?

Because the argument size is DXLEN, this would do a 8-bit or 16-bit memory access and use the low 8 or 16 bits of the argument as described in the description of the write field.