[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 00/93] TCI fixes and cleanups
From: |
Richard Henderson |
Subject: |
Re: [PATCH v2 00/93] TCI fixes and cleanups |
Date: |
Thu, 4 Feb 2021 13:52:58 -1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 2/4/21 10:02 AM, Stefan Weil wrote:
> Am 04.02.21 um 10:58 schrieb Peter Maydell:
>> Not listed, but also a problem:
>> * it's a configure-time choice, not a runtime choice
>
> That's the feature which I also desire most.
Well... that depends on how you see tci being most used.
If, like John Glaubitz, you want to use tci for odd systems that don't have a
native backend, then a configure-time choice is appropriate.
If you're trying to use tci as a cross-check to the native tcg backend, then a
command-line choice could be appropriate. With the bits done below, it could
be just two extra files compiled, which I suppose is light-weight enough.
If you're trying to use tci as a true interpreter for a single-use TB... then
nothing about tci in its current form is appropriate. Of course, I also
believe that our single-use TBs should not be single-use -- because of mttcg,
we can no longer reuse the memory from them, and therefore we might as well
just keep them around, properly hashed.
> Technically it was not possible to
> have native and interpreted TCG in the same code some years ago when I tried
> to
> implement this, but that might have changed as TCG has evolved a lot.
It is still not possible.
However. There are a number of things that I would like to change about tcg
that would make that more practical.
In particular, and most importantly, tcg should be sufficiently partitioned
from any target that it should be built once.
* There are a number of constants that tcg gets from
target/foo/cpu.h as defines. We could just as easily
receive those constants via some structure. The code
that is generated in the end should be the same.
This is a prerequisite to having multiple guest cpus
at the same time. The canonical example of course are
the Xilinx boards that have both Arm and MicroBlaze cpus.
* There are a number of constants that target/ gets from
tcg, but shouldn't. These are mistakenly used by arm
and tricore (probably by my hand), and represent premature
optimization in the front end in both cases, IMO.
(Even though I'm probably guilty of all instances.)
We'll know we've got all of these fixed when
touch tcg/i386/tcg-target.h
rebuilds no files outside of tcg/.
Having these constants in some structure is a
prerequisite to having a native tcg backend live
along side any kind of tci, including the pure
interpreter form.
> I disagree on the #ifdefs which can help to understand TCG better in my
> opinion, so for me they have a useful side effect of being also documentation.
Surely not. Documentation is documentation; ifdefs are clutter, to be used
only when there is no alternative.
I think what you actually want is the structure described above, where all of
the TCG_TARGET_HAS_* knobs are data, and you can change them ad hoc -- even
from within gdb.
r~
- [PATCH v2 88/93] tcg/tci: Implement movcond, (continued)
- [PATCH v2 88/93] tcg/tci: Implement movcond, Richard Henderson, 2021/02/03
- [PATCH v2 89/93] tcg/tci: Implement andc, orc, eqv, nand, nor, Richard Henderson, 2021/02/03
- [PATCH v2 90/93] tcg/tci: Implement extract, sextract, Richard Henderson, 2021/02/03
- [PATCH v2 91/93] tcg/tci: Implement clz, ctz, ctpop, Richard Henderson, 2021/02/03
- [PATCH v2 92/93] tcg/tci: Implement mulu2, muls2, Richard Henderson, 2021/02/03
- [PATCH v2 93/93] tcg/tci: Implement add2, sub2, Richard Henderson, 2021/02/03
- Re: [PATCH v2 00/93] TCI fixes and cleanups, no-reply, 2021/02/03
- Re: [PATCH v2 00/93] TCI fixes and cleanups, Peter Maydell, 2021/02/04