On 2023/10/13 0:06, Richard Henderson wrote:
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.
Get it. Thanks
Whether it is worthwhile to adjust interfaces from CPUState to
ArchCPU, I don't know.
OK. Let's just wait for a good reason to do that.
Zhiwei
r~
