* Re: [9fans] compilers - was GUI toolkit for Plan 9
@ 2002-02-27 2:38 Russ Cox
0 siblings, 0 replies; 8+ messages in thread
From: Russ Cox @ 2002-02-27 2:38 UTC (permalink / raw)
To: 9fans
> Intel will live to regret this.
Too bad the other processor makers will be dead.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
@ 2002-02-27 9:28 Bengt Kleberg
0 siblings, 0 replies; 8+ messages in thread
From: Bengt Kleberg @ 2002-02-27 9:28 UTC (permalink / raw)
To: 9fans
> Delivered-To: 9fans@cse.psu.edu
> From: Mike Haertel <mike@ducky.net>
> Intel will live to regret this.
Last time (yesterday, but I am unable to find the link) I read about
'new' chips (ie 64-bit chips for general purpose computing) the
conclusion was:
Alpha: very good, but but dead since the new owner Intel will not
develop it.
Mips: good, but but dead since it has been re-targeted for
embedded/games.
PowerPC: good, but dead since it is already too complex
Sparc: middeling, but dead since Sun does not have the money to develop
next generation
Itanium: the only game in town (apart from what AMD will/might do, if
they can afford)
So, basically, Intel might regret it, but they will be the only one alive.
> The idea that "hardware/software co-design" is Good has to rank
> among the great fallacies of computer science and the computing
> industry in the last two decades. It may allow elegant solutions
> to isolated problems, but problems are never isolated. Eventually
> either the hardware or the software will need to be replaced, and
> the more cross-dependencies there are the harder this will be.
> Economically it's also really stupid: you are limiting your customers
> to the *intersection* of those who like your hardware and those who
> like your software.
Lets assume that Intel limits its customers to 1. This one beeing
Microsoft. Do you still think that all other customers will continue to
stay away?
bengt
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
@ 2002-02-26 22:17 jmk
0 siblings, 0 replies; 8+ messages in thread
From: jmk @ 2002-02-26 22:17 UTC (permalink / raw)
To: 9fans
On Tue Feb 26 16:36:18 EST 2002, matt@proweb.co.uk wrote:
> Has anyone even tried to run plan9 on a Crusoe?
Not personally, but I know people who have done it.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] GUI toolkit for Plan 9
@ 2002-02-26 20:28 presotto
2002-02-26 21:34 ` [9fans] compilers - was " Matt H
0 siblings, 1 reply; 8+ messages in thread
From: presotto @ 2002-02-26 20:28 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
You're right, there's plenty of blame to go around. More
than once I was hoist on my own petard with C aliasing
and saved by lots of 'volatile's. Not surprisingly I
was screwed more than once by tail recursion optimizations
on Sparc's (fun with register files) by lcc. Ditto with
instruction ordering on MIPS. In all cases turning off
optimization fixed the problem, regardless of where the
fault lay. Hence, I can understand Rob's worry about
optimization being an option rather than a requirement.
Programmers tend to know that they are treading where
lesser mortals fear to go when they up the optimization
level. Especially with C, we are trained largely by
what works and what doesn't. Moving from the VAX to the
68020 uncovered lots of null references that were going
unnoticed in the past. Ditto for other coding outside
the spec. If nothing slaps you down, you get complacent.
Hence, we tend to accept the resulting errors and just
back off optimization when it fails. We often don't report
the bug because
1) not knowing the compiler writer, its often hard
to say, ``When I use the -O256 flag, my 150,000 line program
acts funny'' and expect to get any satisfaction.
2) we're afraid after 2 weeks of debugging it'll turn out
to be our fault
3) once your code has been rewritten by a machine, its
often incredibly hard to figure out what's broken
4) its not my job, man
If things don't make it through with optimization turned
off, then we report bugs because then we know its not
our fault and have no recourse (except the first day
trying to program around it). Hence, optimizing compilers
tend to self select for retaining bugs.
[-- Attachment #2: Type: message/rfc822, Size: 2966 bytes --]
From: Mike Haertel <mike@ducky.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 11:47:19 -0800 (PST)
Message-ID: <200202261947.g1QJlJ043207@ducky.net>
From 9fans-admin@cse.psu.edu Tue Feb 26 11:06:34 2002
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 14:05:49 -0500
>However, it seems to be an
>accepted consequence amongst compiler writers to trade off
>possible incorrect code generation against probable speed
>gains. I've been burned numerous times by upping the optimization
>level in compilers including gcc. This is not a new development.
>It was just as true 30 years ago with the fortran and PL1 compilers
>I used.
I'm not convinced that it's necessarily the compiler writers at
fault in many of these cases. Certainly there are compiler and
optimizer bugs, and probably the more optimization you apply the
more likely you are to tickle these bugs. You can blame the compiler
for those.
But, at least in the case of C, there are numerous cases where
people write code that is semantically undefined according to the
detailed rules of the C standard, but does what they want under
particular compilers or levels of optimization. (E.g. how many of
you have assumed that local variables not declared volatile will
hold their values across a longjmp?)
So who to blame? The compiler writer, who assumes the code being
compiled is standards-conforming? The standards committee, who get
to decide which programming idioms will have defined behavior?
The programmer, who often doesn't really understand the rules of
the language? The authors of programming textbooks, who often
downplay or omit these issues entirely?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
2002-02-26 20:28 [9fans] " presotto
@ 2002-02-26 21:34 ` Matt H
2002-02-26 22:06 ` Theo Honohan
2002-02-27 0:21 ` Mike Haertel
0 siblings, 2 replies; 8+ messages in thread
From: Matt H @ 2002-02-26 21:34 UTC (permalink / raw)
To: 9fans
Okay, I'm no compiler writer or even very proficient C coder but all this
talk of turning optimizations off concerns me. Not because of the threat
of "badly" generated code but because the chip makers (well Intel is the
only one I really read about) are pushing the responsibility for
optimization out of the silicon and into the compiler. (providing I
understand what I read!)
In my minimal contact with C I've regarded optimizations with scorn,
because like disk compression schemes a lá DoubleSpace, my first
encounters were tainted by failure. All optimizations did then (MS C ver 3
on win3.1 i think) was crash quickly.
Does anybody know how runtime optimizations such as those in the Crusoe
chip fair at this? If optimization is tricky at compile time sounds like
doing it at runtime must be hairy. Has anyone even tried to run plan9 on a
Crusoe?
M
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
2002-02-26 21:34 ` [9fans] compilers - was " Matt H
@ 2002-02-26 22:06 ` Theo Honohan
2002-02-27 0:21 ` Mike Haertel
1 sibling, 0 replies; 8+ messages in thread
From: Theo Honohan @ 2002-02-26 22:06 UTC (permalink / raw)
To: 9fans; +Cc: theoh
Matt H wrote:
>
> Does anybody know how runtime optimizations such as those in the Crusoe
> chip fair at this? If optimization is tricky at compile time sounds like
> doing it at runtime must be hairy. Has anyone even tried to run plan9 on a
> Crusoe?
This is quite an interesting issue. It's actually a lot easier to
write a clever interpreter (like the Crusoe chip + software) that
optimizes code at runtime than it is to write an offline "binary
translator". The most obvious examples are the case of runtime code
generation, or self-modifying code; your static analysis of the
code you're translating has to be smart enough to see that coming.
An interpreter that recognizes and optimizes chunks of code
that get called repeatedly is much easier to write.
Incidentally, if your job involves having to explain these issues to
your boss, it's time to go... :-(
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
2002-02-26 21:34 ` [9fans] compilers - was " Matt H
2002-02-26 22:06 ` Theo Honohan
@ 2002-02-27 0:21 ` Mike Haertel
2002-02-28 15:11 ` AMSRL-CI-CN
1 sibling, 1 reply; 8+ messages in thread
From: Mike Haertel @ 2002-02-27 0:21 UTC (permalink / raw)
To: 9fans
>Okay, I'm no compiler writer or even very proficient C coder but all this
>talk of turning optimizations off concerns me. Not because of the threat
>of "badly" generated code but because the chip makers (well Intel is the
>only one I really read about) are pushing the responsibility for
>optimization out of the silicon and into the compiler. (providing I
>understand what I read!)
Intel will live to regret this. It's one thing to design a processor
that provides support for numerous compiler optimizations; it's quite
another to design a processor that *requires* them *all* to get even
adequate performance on a broad spectrum of code.
Anybody want to port 8c and Plan 9 to the Itanium?
(Ok, you can all stop laughing...)
The idea that "hardware/software co-design" is Good has to rank
among the great fallacies of computer science and the computing
industry in the last two decades. It may allow elegant solutions
to isolated problems, but problems are never isolated. Eventually
either the hardware or the software will need to be replaced, and
the more cross-dependencies there are the harder this will be.
Economically it's also really stupid: you are limiting your customers
to the *intersection* of those who like your hardware and those who
like your software.
However they might curse the oddities of the x86 ISA, I am sure the
Plan 9 developers are grateful for the fact that all x86 implementations
are designed with a goal of getting at least adeqaute performance
without recompiling.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
2002-02-27 0:21 ` Mike Haertel
@ 2002-02-28 15:11 ` AMSRL-CI-CN
2002-02-28 16:55 ` Thomas Bushnell, BSG
0 siblings, 1 reply; 8+ messages in thread
From: AMSRL-CI-CN @ 2002-02-28 15:11 UTC (permalink / raw)
To: 9fans
"Mike Haertel" <mike@ducky.net> wrote in message
news:200202270021.g1R0L0s43681@ducky.net...
> The idea that "hardware/software co-design" is Good has to rank
> among the great fallacies of computer science and the computing
> industry in the last two decades.
Unfortunately, performance expectations for new processors require
rather complex architectures involving multiple concurrent pipelines,
etc. making efficient use of the architectures difficult; therefore more
responsibility is placed on the code generators. This seems inevitable.
There are C compilers whose "code" is actually gate configurations
for FPGAs, etc. which is of course this idea taken to an extreme.
In earlier days of computing, little attention was usually paid to the
requirements of HLLs when designing ISAs, and sometimes what
the IS architects guessed would be helpful really wasn't (e.g. PDP-11
MARK instruction). (There were a few notable exceptions, e.g.
Burroughs [56][57]00 models.) The result was that major parts of
processors were not used at all by HLLs, which was bad economics.
This lack of input from compiler developers was widely recognized,
and by the early 1980s several processor manufacturers had changed
their procedures so that the hardware guys and compiler guys talked
to each other early enough to influence the design (of both).
These days, it is generally assumed that most programming is going
to be in C, so attention is focussed on supporting C to the possible
detriment of other languages..
> However they might curse the oddities of the x86 ISA, I am sure the
> Plan 9 developers are grateful for the fact that all x86 implementations
> are designed with a goal of getting at least adeqaute performance
> without recompiling.
? Intel's x86 architecture was designed to be used from assembly
language, not HLL, and it is pretty bad when judged by its support
for HLLs. Even the more recent MMX etc. extensions aren't well
suited for use from HLLs except via machine-specific asm hooks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] compilers - was GUI toolkit for Plan 9
2002-02-28 15:11 ` AMSRL-CI-CN
@ 2002-02-28 16:55 ` Thomas Bushnell, BSG
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Bushnell, BSG @ 2002-02-28 16:55 UTC (permalink / raw)
To: 9fans
"AMSRL-CI-CN" <gwyn@arl.army.mil> writes:
> Unfortunately, performance expectations for new processors require
> rather complex architectures involving multiple concurrent pipelines,
> etc. making efficient use of the architectures difficult; therefore more
> responsibility is placed on the code generators. This seems inevitable.
GCC has a generic mechanism for describing pipelined architectures
that is pretty good.
Thomas
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-02-28 16:55 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-27 2:38 [9fans] compilers - was GUI toolkit for Plan 9 Russ Cox
-- strict thread matches above, loose matches on Subject: below --
2002-02-27 9:28 Bengt Kleberg
2002-02-26 22:17 jmk
2002-02-26 20:28 [9fans] " presotto
2002-02-26 21:34 ` [9fans] compilers - was " Matt H
2002-02-26 22:06 ` Theo Honohan
2002-02-27 0:21 ` Mike Haertel
2002-02-28 15:11 ` AMSRL-CI-CN
2002-02-28 16:55 ` Thomas Bushnell, BSG
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).