This is the mail archive of the
mailing list for the GCC project.
Re: Why are GCC Internals not Specification Driven ?
- From: NightStrike <nightstrike at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Seima Rao <seimarao at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sun, 18 Dec 2016 13:19:33 -0500
- Subject: Re: Why are GCC Internals not Specification Driven ?
- Authentication-results: sourceware.org; auth=none
- References: <CAESP5aq7R=zxozDPTSJMnKWLF_TkyVCu6UssKPz97SoOXyz4Cg@mail.gmail.com> <email@example.com>
On Sun, Dec 18, 2016 at 11:37 AM, Andrew Haley <firstname.lastname@example.org> 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.