This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC, OOP, and GC...


On Jan 25, 2004, <aspiesrule@mcleodusa.net> wrote:

> GCC source is _very_ hard to read at times

Even more so after you remove the line wrapping that is in part
intended to make it more readable :-)

> 4.x, a change to OOP would be a _very_ good idea.  With OOP, we could move 
> most (if not all) of the RTL and tree tests into accessor methods

Guess what, we're already using accessor methods.  It's just that we
don't always create new accessor methods when we want to test for a
more complex condition that shows up in a single place.

In fact, IMHO accessor methods are the very opposite of OOP.  OOP is
mostly about moving intelligence into the objects, whereas accessor
methods just give an OOP-look to the non-OOP practice of violating
abstraction barriers by accessing internal details of objects.  Using
accessor methods for stuff that is actually there is just exposing
information about the internals of the object in a way that looks more
OOP.  In OOP, it's the very notion of exposing such internals that is
wrong.  If an internal reorganization of the representation of the
object would require a change in the accessor interface, the accessor
method gives you no benefit whatsoever, it's just syntactical (if not
run-time) overhead.  And it turns out that the accessor macros we have
now accomplish the very goal you're suggesting.

Sure enough, creating actual code that encapsulate common test
patterns would be a win in terms of maintaining the overall compiler.
But that's still not OOP, it's just modularization.

OOP would be to be able to ask an arbitrary piece of rtl say `do you
set a hardware reg?' and let it figure things out by itself, using
dynamic dispatching.  I.e., a parallel would know to descend into the
various parallels; a set would test it SET_DEST, a clobber would test
its operand, etc.  But would this really be a win?


> would allow us to change RTL structures without having to touch all of the 
> code that uses or manipulates RTL, for example

We already use accessors for everything, so we *could* modify the
internal structures without modifying code all over.  Which is not to
say it would be efficient to say adopt compressed rtl, which was
suggested some time ago.  Higher-level accessors could do it more
efficiently, for sure.  But it's already be possible.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]