[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of some Arm features
From: |
Pierrick Bouvier |
Subject: |
Re: Status of some Arm features |
Date: |
Wed, 20 Nov 2024 16:02:42 -0800 |
User-agent: |
Mozilla Thunderbird |
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