Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
'Religious', hmm. As in 'if we'd not had this attitude we'd have many fewer front-ends and back-ends than we do now'. That seems more, I don't know, *pragmatic* to me.
Posted Oct 18, 2006 19:50 UTC (Wed) by GreyWizard (guest, #1026)
Posted Oct 20, 2006 6:24 UTC (Fri) by viro (subscriber, #7872)
Unlike gcc, implementing new class of checks is not a monumental
project. Including massive modifications of type system, etc.
Being free to tweak any code in a frontend working with gcc backends
might be nice in theory, but having it orders of magnitude harder
to tweak than it would have to be somewhat detracts from that freedom.
Stanford Checker *is* a monumental project. A modified gcc frontend.
Guess what? We _can't_ tweak on it. At all. At most we can try
to convince the nice guys from that group to add something new (and
run it over our code). And no, I'm not being sarcastic - they are
generally nice and reasonable. In compliance with the license, too.
Posted Oct 23, 2006 18:46 UTC (Mon) by GreyWizard (guest, #1026)
Posted Oct 24, 2006 0:03 UTC (Tue) by viro (subscriber, #7872)
Posted Oct 25, 2006 23:01 UTC (Wed) by nix (subscriber, #2304)
Posted Oct 25, 2006 23:36 UTC (Wed) by viro (subscriber, #7872)
Note that "your library is a derivative of my library, you get to
play nice wrt license" is entirely different kind of story. But
in that respect GPL is not something special - e.g. LGPL would
have the same effect.
If anything, I would expect any losses to be in weird backends for
embedded CPUs from hell, but considering the usual quality (and
bitrot rate) of those I'm not sure that I'd call it a loss... BTW,
ought to recheck if patches from FRV tree had finally got merged
into -HEAD; the last I've heard was "4.3 might be able to recognize
FRV-specific constraints in the kernel; it's too late for 4.2"...
Posted Oct 25, 2006 23:00 UTC (Wed) by nix (subscriber, #2304)
And, yes, it *is* easier to hack on a project that contains a frontend for
the parsing part of (most of) one language than it is to hack on a
frontend for a multi-platform optimizing compiler. Of course it is. sparse
doesn't even *have* a middle end to speak of, let alone a back end, so
naturally the constraints are less extreme. (Also, it has many years' less
But there aren't any `games' being played in the GCC source to make it
harder to separate the front and back ends: on the contrary, the
separation is finally becoming vaguely complete, and the pushback against
RMS's stand against explicit .so-based frontend/backend separation has not
stopped for a long time (and won a recent victory, no less: RMS is
shifting on this). Even then, the age of the ports is a problem: there are
many backends for which nobody is quite sure why particular architectural
decisions were done anymore, nor whether they'd break if changed.
(The largest remaining barrier is all the implicit assumptions inside
reload about how the incoming RTL will be shaped, and the implicit
assumptions in all the ports about how to generate that RTL. It's unclear
which of those assumptions are critical, and which are accidents of
(Joe, feel free to correct me if I'm talking rubbish: I'm merely an
interested observer of the GCC development scene, really. I mean I've got
plenty of local patches to the tree but I've never dared submit them
because they're awful.)
Posted Oct 26, 2006 0:08 UTC (Thu) by viro (subscriber, #7872)
OK, now you've got me curious; I was refering to aforementioned
"RMS's stand", but my impression was that it had been blocking
cleanup efforts (== lead to increased and harder to fix mess)
and that its rationale had been at least related to such scenarios
As for sparse... There is a kinda-sorta-not-really attempt at
backend, but no, I wouldn't expect it to really work unless somebody
puts serious effort into resurrecting it. Jeff Garzik is making
threatening noises of that sort once in a while, but that's about
it. There is linearizer and it does get more attention than
backend, but I hadn't looked at it lately.
Of course the lack of ancient cruft helps; no arguments here.
However, it had been my impression that RMS did at least slow
the cleanup, so IMO the point still stands. And if the Stanford
has moved away from gcc, well... then we have nothing gcc-derived
(and used) in that area at all...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds