Why are GCC Internals not Specification Driven ?
Hi, For regular users of gcc who want to delve into the insides(guts) of the compiler, it is disappointing that there exist no complete specification of internals in a phase order manner. Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly), GCC extensions internals, ... and gnu's own debugging tied to gcc (if such exist nowadays), ... are not documented in a specification driven way. Has gcc become proprietory/commercial ? Or has it become illegal to publish specification models of gcc internals ? Does this make the product sell less ? Curious as an old gcc afficianado. :-| p.s. Higher then GENERIC also sounds desirable. Sincerely, Seima Rao.
Re: Why are GCC Internals not Specification Driven ?
On Sun, Dec 18, 2016 at 11:49 PM, NightStrike wrote: > On Sun, Dec 18, 2016 at 11:37 AM, Andrew Haley wrote: >> On 18/12/16 02:33, Seima Rao wrote: >>> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly), >>> GCC extensions internals, ... and gnu's own debugging tied to gcc >>> (if such exist nowadays), ... are not documented in a specification >>> driven way. >> >> That's interesting. Can you explain what you mean by a specification- >> driven way? > > I believe he's referring to top down system design, where you start > from requirements (a la IEEE 830 or IEEE 29148), make design documents > that meet those requirements, model them with something like IEEE 1016 > (which is basically UML), and only at the end provide implementation. > On GCC, the implementation tends to come earlier in the process. At > least, there's probably no UML representation of GCC's design. 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 (ii) is difficult (iii) doesnt sell the product well Sincerely, Seima Rao.
Re: Why are GCC Internals not Specification Driven ?
On Mon, Dec 19, 2016 at 4:15 PM, Jonathan Wakely 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.
Re: Why are GCC Internals not Specification Driven ?
On Tue, Dec 20, 2016 at 1:48 AM, DJ Delorie wrote: > > Seima Rao writes: >> Has gcc become proprietory/commercial ? > > By definition: no, yes. It's been this way since the beginning, and > hasn't changed in decades. > >> Or has it become illegal to publish specification models >> of gcc internals ? Does this make the product sell less ? > > This sounds like you're trying to start an argument, instead of asking a > simple question. It is certainly not illegal to publish our > specifications, and we certainly *do* publish many of our specifications > (have you read the internals manual? You don't say whether or not you > did, but that would be a key bit of information to have disclosed). > Whether the product "sells" or not is rarely a driving factor for our > project. Most of us work on it because we need it to work better for > our own purposes. > > If you have specific questions about our documentation or development > process, please ask them. Please do not ask vague, leading, and > emotionally loaded questions. RTL and Gimple are documented. Are they > documemented well? That depends on your needs. Are they documented as > well as they could be? Probably not, but good enough for us so far. > > And as always, if you want to improve the situation, by all means feel > free to volunteer to do so ;-) Got your point that GCC is more inclined as a reference then a specification driven technology. Sincerely, Seima Rao.
