Re: [PATCH v2 00/93] TCI fixes and cleanups

[Richard Henderson <richard.henderson@linaro.org>]

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~