Hello, Richard.
I am a little taken aback by your tone. I hope we can communicate in much
friendlier maner, as we used to do.
>You have just this year added yet another encoding scheme for nanomips. Your
>statement "well tested over many years" is a bit of a stretch.
I wrote "mostly stable mature", not "all stable mature".
>If you do not wish to work on this, that's your prerogative. But I don't think
you should be arbitrarily shutting down experimentation on this line before it
has a chance to show results.
I am not preventing anyone from experimenting. I just want to warn Philippe
about high-level view that the code in question, although not the nicest,
works, and is planned to be maintained with minimal changes. The focus of MIPS
target is on adding new architectures and ASEs, and (I correct myself) it could
be that decodetree would kick in in such cases - but not for mature code
driving older architectures. It just doesn't make enough sense.
Thanks,
Aleksandar
________________________________________
From: Richard Henderson <richard.hender...@linaro.org>
Sent: Monday, November 12, 2018 9:58:05 AM
To: Aleksandar Markovic; Philippe Mathieu-Daudé; Bastian Koppelmann; Peer
Adelt; Richard Henderson
Cc: qemu-devel@nongnu.org; Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC PATCH 08/11] target/mips: Add a decodetree stub
On 11/12/18 6:37 AM, Aleksandar Markovic wrote:
>> Subject: [RFC PATCH 08/11] target/mips: Add a decodetree stub
>
> There is no plan to use decodetree for MIPS target. MIPS decoding engine is
> mostly stable mature code that was well tested over many years, and there is
> no
> point in introducing such drastic change to the code that works.
This attitude is unnecessarily obstructionist.
The reorganization of the instruction implementation that is implied by a
transition to decodetree is exactly what you and I talked about some months ago.
The ability to use multiple decodetree parsers to vector directly to the
instruction implementations would help unify code across multiple encoding
schemes. (There 4 now: mips, mips16, micromips, nanomips; and mipsr6 is
different enough that it could be considered a 5th encoding.)
In a sample transition of 10 insns that Phillipe sent me via private email this
weekend, I noticed an existing bug in MULT{,U} that fails to enforce rd == 0 on
cpus that have only one accumulator -- any bets there are no more to be found?
You have just this year added yet another encoding scheme for nanomips. Your
statement "well tested over many years" is a bit of a stretch.
If you do not wish to work on this, that's your prerogative. But I don't think
you should be arbitrarily shutting down experimentation on this line before it
has a chance to show results.
r~
