Re: Removing ARCNET stuffs

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote:
 > >> systems and generates reasonable code.  Unfortunately, and sorry PCC
 > >> (stabs, really?),
 > >
 > > Feel free to add dwarf, the source is out there, and it wouldn't be
 > > especially difficult to do it.  I just haven't had time.
 > > Stabs was "for free" :-)
 > 
 > I'm not so sure (a year back I looked at the code with that in mind),
 > and wonder if any quick hack would end up being opportunity lost.

I have not looked at it, nor have I looked at pcc at all in a long
time, so what I'm missing may just be otherwise obvious context, but:

 > PCC, as a "classic" C compiler, only generates debug information at
 > -O0.  This this is because the stabs code is restricted to the
 > un-optimized code generator path.  Having the backend restricted to
 > DWARF when '-O0' might just be ok, were it not for SSA (static single
 > assignment).
 > 
 > To my mind, and I'm assuming a pure SSA compiler design, having SSA
 > forces issues like: [...]

I'm missing something; SSA is just a style of program representation. 
Are you talking about a hypothetical future where pcc's backend grows
an (additional, or replacement) SSA-based layer? Or is pcc's
optimizing backend already SSA-based (per above, I don't know one way
or the other) and you're talking about making that preserve debug
info?

Either way, it seems like adding DWARF support to the non-optimizing
backend is an orthogonal issue.

Unless, I guess, what you're talking about is throwing away the
existing backend entirely and writing a new SSA-based one, in which
case I'd gently suggest that this is a large project :-)

 > (I've got to admit that I wonder if C is the best language for an
 > optimizing compiler; but then, it is what we have)

It is not, but one can do a lot worse. Plus if you try you end up in
bootstrap hell like e.g. lang/ghc.

-- 
David A. Holland
dholland%netbsd.org@localhost