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~