Re: Projects for beginners

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Wed, Jan 31, 2001 at 08:12:09AM +0100, Hans-Peter Nilsson wrote:
> > From: "Zack Weinberg" <zackw@stanford.edu>
> > Date: Tue, 30 Jan 2001 20:42:06 -0800
> 
> > Here's my list of GCC-related projects that could usefully be
> > attempted by beginners to GCC.
> 
> Yay!  Way to go!
> 
> Here's my little contribution:
> 
> > Port cleanup:
> 
>    Convert porting-macros definition and usage from
>      #ifdef MACRO
>        ... code ...
>      #endif
>    to
>      #ifdef MACRO
>        if (MACRO)
>          ... code ...
>      #endif

So it can be toggled at runtime when necessary?

I might go farther: in defaults.h

#ifndef MACRO
#define MACRO 0
#endif

then in source

    if (MACRO) {
      ... code ...
    }

This increases the likelihood of silly mistakes in rarely-used code
getting caught by the compiler.  It's also often more readable.

> >   Convert md files that use cc0 so they don't anymore.
> > 	- This is apparently doable with some stereotyped insn
> > 	patterns.  You'd need to understand RTL, but it strikes me as
> > 	a good learn-by-doing project.  See
> > 	http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00643.html.
> 
> Beware, this *may* need more infrastructure.  I sure would like
> a few more pointers on how to do it.  I took a quick glance at
> that time but didn't find everything handy to start doing it for
> CRIS, specifically regarding a few details:
>  - How to eliminate the cc0-setting part when condition codes
>    are set usefully by a previous insn in this new framework.
>  - How to handle sCC patterns.
...

This is where I admit that I have never been able to understand any of
the multiple different ways of handling condition codes in GCC.
There's the pure cc0 approach, the every-insn's-a-parallel approach
taken by the x86 back end, the cbranch stuff which I totally agree
needs more documentation, and the pure flag registers approach which
apparently only works on machines where that is the hardware.

My basic problem is that the comparison RTXes mean different things
when they're used to set condition registers, from when they're used
to examine condition registers.  I.e. these are not the same thing:

  (eq (reg:SI 12) (const_int 0))
  (eq (cc0) (const_int 0))

but I've never really been able to understand just what the latter one
means.

I *think* that the cbranch stuff lets you have

(set (pc) (if_then_else (eq (reg:SI 12) (reg:SI 13))
                        (label_ref 42)
                        (pc)))

as one insn, i.e. at least before insn splitting there's no condition
code register at all.  But I Could Be Wrong.

> If there's someone with the answers, I'll consider doing it for
> CRIS (awaiting approval) so that it could perhaps be used as a
> template in addition to the thumb bits within the arm port when
> getting rid of cc0 in other ports.
> 
> I guess this is actually a call for documentation of that
> appraised "cbranch" stuff.  Maybe an item for the GCC-related
> projects, unless the cbranch author or equivalent steps forward.

Emphatic agreement.

zw