On Mon, Dec 19, 2016 at 4:15 PM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 19 December 2016 at 10:17, Seima Rao wrote:
>> I was referring to one of three approaches:
>>
>> i) Write a Specification document and a matching testsuite
>>
>> ii) Document _all_ data and code together with file formats
>> (e.g. dumps).
>>
>> iii) Both (i) & (ii)
>>
>> (i) is easy
>
> I disagree.
>
> A functional specification would either be constantly out-of-date or
> would be a lot of effort to maintain (think how many different
> architectures GCC generates code for, and how often the instruction
> sets for the major architectures change). There would be some
> advantages to having the document in place, but only if it was
> maintained very thoroughly, which is unlikely to happen IMHO.
>
> We have testsuites. The output formats are defined by other documents
> we don't control (ABI specifications, processor instruction set
> references). The "UI" is defined by the manual.
>
> Duplicating this information in other documents would be a lot of
> effort and is not very compatible with the way GCC is developed. There
> is no top-down design committee that oversees GCC development and
> would act as gatekeepers to specification changes.
>
> The source code, the testsuite and the manual are the specification for GCC.
>
>> (ii) is difficult
>> (iii) doesnt sell the product well
>
> What product is being sold here?
GIMPLE/GENERIC, RTL & .md are languages, arent they?
So, basically there is a need for grammars and semantics.
However, leaving it at just that doesnt sound that good.
Where is the code, the most important part?
That code can be in a new testsuite that tests out the
specification of these four languages but the primary driver
remains GCC. That is, inorder to test out .md file,
we certainly should need GCC. Those instantly
seeking info about the file format can download
the source and study all of them.(this doesnt
take away the credit from the maintainer of
that component).
One advantage is that it gives a good overview on
where all the strengths and the weaknesses
of the choices made in the four(I state this because GCC
keeps on moving forward from one internal,
to abandoning it and adopting a new one, ...).
It can also help enforce some stability of the internals.
Inline assembly != gas, so this can also be specified
in a target independent way.
C++ already does this:
The shortest possible grammar for asm by any
vendor could be:
extern "asm" {
// the grammar here specifies a large 'C' string but nothing else
}
This passes through the string to the Assembler and does nothing else.
GCC extensions *should* have grammar and semantics and how they
fit to the Language they are extending. A bit like Boost.org
Target HW architecture separation can be achieved by
stating that post asm, all bets are passed on to 'gas'
and binutils 'gas' documentation becomes a new
forked off project separate from GCC.
Sincerely,
Seima Rao.
