Re: Removing ARCNET stuffs

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On 1 June 2015 at 12:54, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 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.

Yes.  Lets think of Static Single Assignment as the pure academic theory.

LLVM[Lattner et.al.] and GIMPLE[Novillo et.al.] are real world
implementations of that theory.
https://gcc.gnu.org/projects/tree-ssa/#ssa has a good diagram and is a
relevant read.

PCC, to the best of my knowledge is still in the [very early] planning
stages.  One of its design choices would be to go pure SSA.  Another
option, closer to GCC (RTL), would be to retain existing code-gen
passes.  Tough choices.

> 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.

I'm being fast and loose.  My reading of the code was that debug info
was being generated by the back of the front end (very roughly
"gimplify" in this diagram of GCC
https://gcc.gnu.org/projects/tree-ssa/#ssa).   It was pretty much hard
wired printfs, and explained to me why "-g -O" wasn't supported.

> 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 :-)

Exactly :-(

Andrew

>
>  > (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