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~
