Re: Status of some Arm features

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 11/19/24 09:14, Peter Maydell wrote:
> On Tue, 19 Nov 2024 at 16:52, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>>
>> On 11/19/24 02:09, Peter Maydell wrote:
>>> On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org> wrote:
>>>> I'm currently reviewing the QEMU Arm documentation, and I have a
>>>> question about the status of following features:
>>>>
>>>> 8.0:
>>>> - FEAT_DoubleLock, Double Lock
>>>
>>> This is actually an "anti-feature" :-)  It is optional from v8.0
>>> and it must not be implemented from v9.0. We implement the handling
>>> of it based on the DOUBLELOCK fields in ID_AA64DFR0 and DBGDEVID
>>> (so it does the right thing on older named CPU types) and don't
>>> advertise it in "max".
>>>
>>
>> Despite this singularity on versions implementation, should we list that
>> in our documentation?
> 
> Yeah, I think we reasonably could.
> 

I'll add it in my upcoming series then.

>>>> 8.2:
>>>> - FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)
>>>
>>> This isn't a feature for CPU implementations; it's a feature for
>>> assemblers and disassemblers, which have to recognize BFC and
>>> REV64 mnemonics as being ways to write special-case flavours
>>> of the BFM and REV instructions.
>>>
>>
>> Reading the feature description [1] or the A-profile manual:
>> FEAT_ASMv8p2 introduces the BFC instruction to the A64 instruction set
>> as an alias of BFM. It also requires that the BFC instruction and the
>> A64 pseudo-instruction REV64 are implemented by assemblers.
>>
>> I understand it's both introducing the BFC instructions *and also*
>> ensure that BFC and REV64 are implemented by assemblers.
>> Is my interpretation wrong?
> 
> For an implementation, there is no BFC instruction. If you look
> at the Arm ARM entry for BFC, it says "This instruction is an alias
> of the BFM instruction", which means it exists only for
> assemblers and disassemblers and assembly authors.
> (And if you look at the BFM instruction, there is no subset of the
> encoding that is gated on any feature; so there is no extra
> behaviour of BFM that got added here.)
> 

Thanks, I have been confused by the presence of BFCI and BFM 
instructions, making me think we implemented something specific.
It's more clear now.

> These "alias" instructions are there to make the assembly be
> a bit easier to read. The only unusual thing about this alias
> is that it wasn't in the architecture right from the start,
> which I think is why it got a FEAT_ name: to flag up that
> if you're writing asm or if you're an assembler author then
> you need to do something here. But if you're creating an
> implementation of a CPU, then there's nothing to do, because
> you already implemented the handling of BFM as part of ARMv8.0.
> 
> For an example of an alias that was present from v8.0, look
> at "MOV (to/from SP)". This is an "ADD (immediate)" instruction
> under the hood, but you can write it in assembly source as
> "MOV SP, Xn", and the assembler will put in the same bit pattern
> as if you'd written "ADD SP, Xn, #0". In QEMU (or in a hardware
> implementation) we don't need to do anything for "MOV SP, Xn",
> because our implementation of "ADD (imm)" will catch it.
>

Got it, thanks.

>>>> 8.4:
>>>> - FEAT_CNTSC, Generic Counter Scaling (hw/timer/sse-counter.c)
>>>
>>> This is optional, and we don't implement it yet. (There's an
>>> open ticket for it in Linaro JIRA at
>>> https://linaro.atlassian.net/browse/QEMU-309 )
>>>
>>
>> Ok. For my personal knowledge, does the implementation in
>> hw/timer/sse-counter.c is related to it?
> 
> I elaborated a bit on that in my other email -- they're
> doing a similar thing, but sse-counter.c is M-profile.
> 
> -- PMM