On 10/11/23 22:59, LIU Zhiwei wrote:
On 2023/10/11 13:31, Philippe Mathieu-Daudé wrote:
On 11/10/23 05:25, LIU Zhiwei wrote:
On 2023/10/11 1:04, Richard Henderson wrote:
On 10/9/23 05:42, LIU Zhiwei wrote:
On 2023/10/9 19:02, Philippe Mathieu-Daudé wrote:
When CPUArchState* is available (here CPURISCVState*), we
can use the fast env_archcpu() macro to get ArchCPU* (here
RISCVCPU*). The QOM cast RISCV_CPU() macro will be slower
when building with --enable-qom-cast-debug.
If so, maybe we have to do this qom cast somewhere.
No, I don't think so. Or at least not in these places.
Yes. Perhaps, we should remove all RISCV_CPU macros using after the qom
objects realized.
Do you think we should remove the RISCV_CPU using in riscv_cpu_exec_interrupt? Although
it is not so hot. I think there is no reason to use it there.
I have some note in my TODO to check replacing CPUState by ArchCPU in
TCGCPUOps (like the cpu_exec_interrupt handler you mentioned).
IMHO, this will make it harder for heterogeneous SOC support. ArchCPU is not a target
agnostic struct.
ArchCPU is a target-agnostic typedef of a structure with no visible definition.
C is perfectly happy to manipulate pointers to such structures.
Whether it is worthwhile to adjust interfaces from CPUState to ArchCPU, I don't
know.
r~
