[9fans] splitting the compiler

[9fans] splitting the compiler

[paurea]

As I see it we have three sets of constraints here:
1) - being fast compiling
2) - generating fast code (even if it breaks...? )
3) - being portable

We can make the first and the second not exclusive by having -O flags so
while developing (you want fast compiling and no new bugs generated by the compiler) you don't use 2. The issue here is the 3rd constraint. If you add 
a complex optimizer the code is less portable. 

I think the only way out of that is having two independant compilers
(the may share a lot of codebase) say, 8c and 8co (optimized). The
idea is that 8c compiles 8co, 8c is portable, fast and simple.
8co is slow but generates fast code.

Not that I am writing any compiler, it is just a suggestion. :-)

By the way, I have just recompiled XFree86 tree and it has taken me
three quarters of an hour. That is not the path to follow!!!.
-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] splitting the compiler

[Thomas Bushnell, BSG]

paurea@gsyc.escet.urjc.es writes:

> We can make the first and the second not exclusive by having -O
> flags so while developing (you want fast compiling and no new bugs
> generated by the compiler) you don't use 2. The issue here is the
> 3rd constraint. If you add a complex optimizer the code is less
> portable.

I'm pretty familiar with GCC internals, and it's pretty darn
portable.  But perhaps there's a whole level of portability I'm
missing.  Could someone with familiarity with both compilers (GCC and
8c) say [in some detail] what kind of portability 8c has that GCC
lacks, so I could understand it better.

Thomas

Re: [9fans] splitting the compiler

[ozan s yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

> I'm pretty familiar with GCC internals, and it's pretty darn
> portable.  But perhaps there's a whole level of portability I'm
> missing.

original poster meant retargeting (i think). with (say) lcc, all one has
to worry about is a relatively straight-forward code generator. a student
targeted it for ns32000 in about a week. i would expect no more time for
8c, but estimate three to six months for gcc.

oz
-- 
www.cs.yorku.ca/~oz	 | don't count your chickens in glass houses
york u. computer science | until the cows come home. -- david vestal

Re: [9fans] splitting the compiler

[Thomas Bushnell, BSG]

ozan s yigit <oz@blue.cs.yorku.ca> writes:

> "Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:
> 
> > I'm pretty familiar with GCC internals, and it's pretty darn
> > portable.  But perhaps there's a whole level of portability I'm
> > missing.
> 
> original poster meant retargeting (i think). with (say) lcc, all one has
> to worry about is a relatively straight-forward code generator. a student
> targeted it for ns32000 in about a week. i would expect no more time for
> 8c, but estimate three to six months for gcc.

Hrm, I retargeted GCC (back in the days of version 1) for the old
Clipper chip in about a month.

Thomas

Re: [9fans] splitting the compiler

[ozan s. yigit]

Thomas Bushnell:
 
> Hrm, I retargeted GCC (back in the days of version 1) for the old
> Clipper chip in about a month.
> 
> Thomas

is that after you figured out how to use RTL? were you around people who
knew and you could ask? in the version 1 days, adults were reduced to tears
with the fumes coming from RTL :) sometimes free costs so much...

oz
---
a technology is indistinguishable from | electric: oz@cs.yorku.ca
its implementation.   -- Marshall Rose | or ozan.yigit@sun.com

Re: [9fans] splitting the compiler

[Thomas Bushnell, BSG]

"ozan s. yigit" <oz@cs.yorku.ca> writes:

> is that after you figured out how to use RTL? were you around people who
> knew and you could ask? in the version 1 days, adults were reduced to tears
> with the fumes coming from RTL :) sometimes free costs so much...

No, I just read the internals manual an looked at examples in the code

Re: [9fans] splitting the compiler

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

oh yes, i'd forgotten about the Clipper.
i did Ka Kc and Kl for the Fairchild/Intergraph Clipper chip in a week
(1992/3 Plan 9), but i wasn't working very hard.  the Plan 9 assembler
is nearly always at most an afternoon's effort.  the time for the
compiler varies quite a bit.  the Clipper architecture was
straightforward.  the compiler was easy.
most of the time was spent on the linker.  Kl got to
compensate for all the processor pipeline/scoreboard bugs.  dreadful.
nice architecture but buggy implementation.


[-- Attachment #2: Type: message/rfc822, Size: 2358 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] splitting the compiler
Date: Thu, 28 Feb 2002 16:53:08 GMT
Message-ID: <87bse9h7ni.fsf@becket.becket.net>

ozan s yigit <oz@blue.cs.yorku.ca> writes:

> "Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:
> 
> > I'm pretty familiar with GCC internals, and it's pretty darn
> > portable.  But perhaps there's a whole level of portability I'm
> > missing.
> 
> original poster meant retargeting (i think). with (say) lcc, all one has
> to worry about is a relatively straight-forward code generator. a student
> targeted it for ns32000 in about a week. i would expect no more time for
> 8c, but estimate three to six months for gcc.

Hrm, I retargeted GCC (back in the days of version 1) for the old
Clipper chip in about a month.

Thomas

Re: [9fans] splitting the compiler

[Matt H]

> many (i'd have said nearly all) of the worthwhile fancier global
> optimisations are perfectly portable, however much code they take to
> implement. 

As I said before, all of this concerns me for the future speed
imporvements on the next round of hardware. In the Itanium tech reviews
here :

http://www.extremetech.com/article/0,3396,s=1005&a=22477&app=7&ap=8,00.asp

it mentions :

"Intel's formally stated goal was to shift complexity out of the processor
logic and to the compiler. "

 From what I know of Intel it could well be conciously making this move as
part of it's destructive competitive instincts with regard to both AMD and
other compiler vendors.

This article :
http://www.open-mag.com/754088105111.htm

does a shoot out between Intel's C++ compiler and GCC, reporting that for
the OBLcpu benchmark suite Intel's compiler, on average, produced code
that ran 47% faster than GCC! (and sometimes 100% faster).

Intel's compiler, of course, made full use of SIMD instructions but,
significantly, showed a similar improvement over GCC when targetting
Athlons!

I'm glad 8c compiles quickly. Although I was disappointed the first time I
compiled a kernel. I went to make a cup of tea while it compiled only to
return for my cup and the bugger had already finished!

M

Re: [9fans] splitting the compiler

[forsyth]

>>We can make the first and the second not exclusive by having -O flags
>>so while developing (you want fast compiling and no new bugs generated
>>by the compiler) you don't use 2.  The issue here is the 3rd
>>constraint.  If you add a complex optimizer the code is less portable.

many (i'd have said nearly all) of the worthwhile fancier global optimisations are
perfectly portable, however much code they take to implement.   indeed, it's often
much easier to do them in a high-level intermediate representation
than a low-level machine-oriented one because there is much more context available.
arguably, some of the fancier optimisations are often compensating for
the low level of the programming language, and it's sometimes much
better to address that directly.   (very high-level languages can pose their
own different problems for compilation, of course.)

furthermore, the least buggy optimising compilers i've used
have had most of the optimiser on by default.  it's the rarely-invoked
things that tend to introduce bugs (in my experience, and that
of Linux, i've observed, with gcc).

as someone observed, for system implementation languages like C--and
come to think of it, it was even true of less system-y FORTRAN and Pascal, certainly
Ada--what the language definition actually guarantees is often a
significant subset of what programmers simply assume they can rely
upon.  readable language definitions that spell out these points
clearly would help, but that often conflicts with the desire for
(notional) precision or flexibility in implementation.  by contrast
with many users of a language, most compiler writers tend to know the
definition fairly well, except perhaps for enormous langauges,
but authors of compilers that are intended to
offer big code improvements (for particular classes of programs) are
even more like shyster lawyers with an eye for the fine print.