On 24/01/13 19:55, Diego Novillo wrote:
...
Agreed.
I do see, however, a few areas where Clang/LLVM have gone that I do
not think GCC is currently thinking of entering: "toolability" (for
the lack of a better term). Clang's design follows a different path
than g++. It's not just a code generating parser, it is a pure parser
that also generates code. The difference makes it suitable for any
kind of tool that needs to understand C++: static analyzers, code
re-formatters, syntax highlighters, and other similar tools.
Additionally, it is designed as a library, so it can be embedded into
applications.
I don't know enough yet but GCC seems to be partitioned, this back and
front end, there's some point where there's no GIMPLE and then there is,
whenever I've got a big code-blob and need to do something with it where
I cannot copy and paste the bits I want to keep, you know, you can't
just take the good parts, I've turned to Biology:
When DNA replication happens (or protein synthesis - please biologists
don't be bionazis) the DNA is not 'unzipped' for very long and doesn't
leave the safety of the membrane around the nuclease (this time last
year, I would have known the name!) so instead it is transcribed.
An enzyme latches onto the 3`UTR end and moves to the 5`UTR end,
unzipping the DNA and rezipping it in it's wake, and it transcribes the
DNA bases to the complimentary base in RNA, rather than the compliment
to DNA's Adenine (thymine) RNA has Uracil. Fun fact.
Anyway this fragile DNA structure that can't leave the nuclease or be
split up (GCC) can be traversed by this enzyme and spit off useful
strands of RNA that expresses the data of the DNA.
No fact checking - hope it wasn't to bad, and worthy of writing, with
GCC why not add the ability to "siphon" off useful structures and output
a form that can be independent of the DNA that is GCC (serialised form)
The thing that'd do this would be inside GCC so would have access to all
context and whatever data is available. I think that was a superb metaphor.
That is a need that g++ cannot currently satisfy. With plugins, one
could do something along those lines, but they are heavier, and are at
the mercy of the full compiler. Additionally, g++ has very low
fidelity wrt the input program; it breaks down the original C++ input
almost immediately.
I don't quite follow, as opposed to? (Sorry if dumb question)
That is not necessarily a bad thing for g++. But, to effectively
compete in those areas, it will need to be significantly re-organized.
LLVM has similar properties, at least as far as the middle end of the
compiler is concerned. GCC still has an edge wrt backend portability.
Diego.
Alec
