On Saturday, January 25, 2020, Richard Henderson < richard.hender...@linaro.org> wrote:
> On 1/24/20 1:38 PM, Aleksandar Markovic wrote: > > On Friday, January 24, 2020, Richard Henderson < > richard.hender...@linaro.org > > <mailto:richard.hender...@linaro.org>> wrote: > > The thing I'm concerned about here is any future maintenance of this > file. One > > would surely prefer to edit the original decodetree input than this > output. > > > > > > Here is the deal: This dissasembler is meant to reflect the > documentation of a > > particular ISA, and as the documentation largely stays constant (except > adding > > some insignificant errata), the disassembler will stay virtually > constant, we > > wouldn't like even to touch it, and we like it this way. > > No, this is neither right nor proper. > > To review the code in this form is significantly harder than in its > decodetree > form. That is in fact the whole point of the decodetree form: otherwise > we'd > still be writing these sorts of parsers by hand. > > While there's no license on this new file (another problem), if as assumed > this > is GPL 2+, then you are in violation of the GPL. From section 3: > > # The source code for a work means the preferred form of > # the work for making modifications to it. > > You cannot with a straight face claim that the generated c is the preferred > form for making modifications. > > Finally, suppose we improve decodetree.py, so that it produces code with > which > the compiler produces better code, for some metric of better. We would > want > this disassembler to benefit as well. > > I think you got some things upside-down. A tool developent and usage should be driven by the needs of users of a tool, and not dictated by the author. Users should be free to use the tool in any way they seem suitable, including its modification. > r~ >
