Re: [9fans] GUI toolkit for Plan 9

Re: [9fans] GUI toolkit for Plan 9

[sape]

phaet0n@hotmail.com asked:
   I am wondering if anyone is developing,
   or planning, a GUI toolkit for Plan 9?
   If not, does anyone have any good design
   ideas, especially centring around Plan 9
   features? Are there any good papers on
   this topic?

We have an experimental GUI library at the labs.  It's called libcontrol.
Rob Pike did most of the design and I took over its maintenance and
changed it in various ways.

It relies heavily on the thread library.  The controls (our widgets) are
managed by a control thread.  Operations on controls are sent to
this thread via a Channel of char*, e.g.,
	chanprint(controlset->ctl, "controlname operation parameters");
We have basic controls such as buttons, textbuttons, labels, sliders, texts
and editable windows.  In addition we have metacontrols for composition:
radiobuttons, rows of controls, columns of controls, and stacks of controls.
A stack consists of overlayed controls -- only the top one is visible.
Obviously, you can make rows of columns, or columns of rows, etc.
Stacks, columns, and rows help in doing automatic layout, initially, or
upon resize.
Controls report events via a per-control event channel.  These event
channels can be rewired, for instance, to have the events of a slider
be wired into a text or edit control, turning a slider into a scroll bar.

We have a modest number of applications using it now and there has been
a rumor that maybe acme will once upon a time become a libcontrol user.

	Sape

Re: [9fans] GUI toolkit for Plan 9

[okamoto]

>a rumor that maybe acme will once upon a time become a libcontrol user.

It'd be great if we could have one.

By the way, an example of our newest user interface is here:

http://basalt.cias.osakafu-u.ac.jp/plan9/planvui.ps

Kenji

PS. I'll be in Houston the next week, so my response will be delayed.

Re: [9fans] GUI toolkit for Plan 9

[Roger Peppe]

> this should almost be in the FAQ. try "du -a . | grep foo". i've also
> found "grep foo `{du -a . | awk '{print $2}'" to be very useful.
> variations can reproduce most or all of find.

i find the following little shell script saves typing; i use
it all the time,

e.g.
grep '^menuhit' `{find /sys/src/lib* '\.c$'}


% cat /bin/find
#!/bin/rc
if (~ $#* 1 0) {
	echo 'usage: find <dir>... <re>' >[1=2]
	exit usage
}
a=()
while (! ~ $#* 1) {
	a=($a $1)
	shift
}
du -a $a | sed 's/^[^ 	]*[ 	]//' | grep $1

Re: [9fans] GUI toolkit for Plan 9

[forsyth]

plain
	panic iunlock
is produced by the bootstrap 9load if it attempts to
unlock something that wasn't locked.
it could be ether; it could be ata/scsi.

Re: [9fans] GUI toolkit for Plan 9

[Russ Cox]

> i am not an expert on the formal definitions of C, but the code
> rob (from rsc?) posted earlier certainly seemed reasonable (i'm
> refering to the x=sqrt(3.0) stuff). can someone confirm?

it's hard to fault gcc for that.  gcc was compiling for an
environment where double was the highest internal precision,
and got tripped up because the linux guys set the default
internal precision to long double.

Re: [9fans] GUI toolkit for Plan 9

[nigel]

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

du -a . | grep ...

panic iunlock can be caused by two things:

	if(l->key == 0)
		print("iunlock: not locked: pc %luX\n", getcallerpc(&l));
	if(!l->isilock)
		print("iunlock of lock: pc %lux, held by %lux\n", getcallerpc(&l), l->pc);

i.e. iunlocking something not locked at all, or iunlocking something
that was locked.

lock = spin lock
ilock = disable interrupts and spin lock

the real interest is the pc printed out, because it tells you where the iunlock()
was called from. You can consult the kernel image to find out where this
is.


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

From: Martin C.Atkins <martin@mca-ltd.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Mon, 4 Mar 2002 19:29:54 +0530
Message-ID: <20020304192954.33a0cb67.martin@mca-ltd.com>

On Mon, 4 Mar 2002 10:07:09 GMT "Thomas Bushnell, BSG" <tb+usenet@becket.net> wrote:
> martin@mca-ltd.com (Martin C.Atkins) writes:
> 
> > I'm sorry that I can't remember *any* attribution, but I thought it
> > was "common wisdom/knowledge" that gcc only really worked properly
> > with -O turned on. That the optimiser "optimised away the bugs put in
> > by the code generator". This is going back a few years, so it may be
> > things have "improved"?
> 
> One of the dangerous things about FUD is that people continue to
> repeat it, when it was never true, without attribution except as
> "common wisdom".

That's as may be. But it never occurred to me that this might be FUD
(until you kindly pointed it out). Rather, I thought it was a
curiosity about the way that gcc's code generation worked (and not
*inherently* incorrect, so long as one didn't regard compiling
without -O as "compiling"), and - more importantly - a hint as to how
to avoid unnecessary pain (to me, as a user of gcc, at that time, and
still now).

(After all, I'm still really a Linux lurker. Also, having lost most
of yesterday trying to get Plan 9 to install on a new machine without
destroying it's partition table (I tried 3 times before giving up and
zeroing the disk), I'm not too well disposed to Plan9 right now.
Although to be fair, it's working great now..... - BTW: What *does*
"panic iunlock" mean (I think that was it), apart from "You're
stuffed - go and hit your head on a nearby wall, and then start
over..."? First time I thought it was because I had done something
silly, but the second time I *hadn't* done the silly thing....
Still, at least the good side effect is that I no-longer have Windows
on the machine :-) )

BTW: what's the Plan9 equivalent of Unix's "find . -name ... -print"? 
(always a good fallback for a beginner :-)

Martin
-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] GUI toolkit for Plan 9

[Martin C.Atkins]

Thanks Nigel,

On Mon, 4 Mar 2002 14:02:41 0000 nigel@9fs.org wrote:
> du -a . | grep ...

Great hack! Thanks also to the other who pointed this out.

> 
> panic iunlock can be caused by two things:
> 
> 	if(l->key == 0)
> 		print("iunlock: not locked: pc %luX\n", getcallerpc(&l));
> 	if(!l->isilock)
> 		print("iunlock of lock: pc %lux, held by %lux\n", getcallerpc(&l), l->pc);
> 

Actually I don't remember a pc - is this because it happened before Plan9 proper
got going? I.e. long before the "root is from..." question. (Possibly at about
the "using sdC0!..." line), but I don't remember for sure. As I remember the message
was simply:
	panic iunlock

I suppose the real fustration was that there didn't seem to be anything I could
do about it, short of re-installing from scratch (and having the installer
screw up my partition table - again!)

> i.e. iunlocking something not locked at all, or iunlocking something
> that was locked.
> 
> lock = spin lock
> ilock = disable interrupts and spin lock
> 
> the real interest is the pc printed out, because it tells you where the iunlock()
> was called from. You can consult the kernel image to find out where this
> is.
> 
> 

Anyway, like I said... It's working great now!

Martin
-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] GUI toolkit for Plan 9

[anothy]

// ...what's the Plan9 equivalent of Unix's "find . -name ... -print"? 

this should almost be in the FAQ. try "du -a . | grep foo". i've also
found "grep foo `{du -a . | awk '{print $2}'" to be very useful.
variations can reproduce most or all of find.
ア

Re: [9fans] GUI toolkit for Plan 9

[anothy]

// So far I know of one optimization bug in the 8c compiler
// and none in GCC.  Do you have some you know about but
// aren't reporting?

being a very infrequent user of gcc, and having no emotional
energy invested it its status, i've not been keeping lists of any
strange doings, nor even looking into them fully to determine
whether they're bugs or no. however, a quick google turns up
lots and lots of responses for various queries on gcc optimizer
bugs. further, curious as to what the official bug repository for
gcc bugs is, i wandered over to gcc.gnu.org and noticed they
have an gnats db there. a quick search for non-closed optim.
bugs returns 156 results (the majority of which are in the open
state). that says nothing of previous ones which have been
fixed. given the probability of duplication of bug reports or
people simply being wrong, i imagine the real number is much
lower than 156, but substantially above 1.

i am not an expert on the formal definitions of C, but the code
rob (from rsc?) posted earlier certainly seemed reasonable (i'm
refering to the x=sqrt(3.0) stuff). can someone confirm?
ア

Re: [9fans] GUI toolkit for Plan 9

[anothy]

// However, one way to decrease the risk is simply to spend more
// effort in care and fixing bugs.  Merely adding a new component
// need not increase risk; it simply means that if you want to bring
// the risk down to where it was before, you have to expend more
// effort.

exactly. but even the gcc folks don't have infinite time/effort. and
i'd assert that the time it takes to maintain a fixed bug likelyhood
increases nearly geometrically (certainly much more than linearly)
with the volume of code.

i do not dispute that the gcc maintainers spend alot of effort
trying to find and eliminate bugs. i simply don't think they spend
enough (because they don't _have_ enough) given the size and
complexity of their code.

i'm certainly willing to grant that agressively-optimizing
compilers like gcc have their place, and i don't think anyone here
has disputed that (comments about gcc specifically are a different
issue entirely). what i think people (including me) take issue with
is your early assertion that 8c (&c.), for _not_ being in that family,
is a "cute toy" (your words).

i think you're under the impression that people here are somehow
making "an argument for why GCC is somehow *bad* for having
such optimizations" (again, you). rather, what i think people are
arguing is that GCC is bad for including optimizations beyond the
maintainer's ability to keep bugs to near-zero.

perhaps (as in maybe) the assertion that compiler optimizers
explicitly consider it an acceptable tradeoff to introduce potential
bugs for probable speed improvements is a bit strong, but the
fact remains that that's what they do, implicitly. while i'd be hard
pressed to find anyone say that outright, you can certainly tell
where a person's priorities lay by where they spend their time.
ア

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

anothy@cosym.net writes:

> i do not dispute that the gcc maintainers spend alot of effort
> trying to find and eliminate bugs. i simply don't think they spend
> enough (because they don't _have_ enough) given the size and
> complexity of their code.

Really?  So far I know of one optimization bug in the 8c compiler and
none in GCC.  Do you have some you know about but aren't reporting?

> i think you're under the impression that people here are somehow
> making "an argument for why GCC is somehow *bad* for having
> such optimizations" (again, you). rather, what i think people are
> arguing is that GCC is bad for including optimizations beyond the
> maintainer's ability to keep bugs to near-zero.

If people had some actual claims about how many bugs they think there
are, that would be useful.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[bwc]

When do we get to the point of diminishing returns using optimizing compilers?
Do people actually think that large sources are as free from bugs as
smaller sources are?  Is it worth the uncertainty of fancy compilers
to have your application run 0.09 instead of 0.10 seconds?

N. Wirths guidelines:

	- Use straightforward techniques
	- Simple compilers are more reliable compilers
	- Generate good code for the frequent case;
		don't optimize the exceptions
	- Generate good code from the beginning;
		don't generate bad code and optimize later
	- Don't let the compiler repair poor programming style
	- Generate predictable code
	- What is difficult to compile is usually also difficult to understand
	- Instead of applying more sophisticated compilation techniques,
		simplify the language
	- Strive for short compilation times
	- A compiler is also an educational tool;
		it should inhibit bad programming style
	- Write the compiler in its own language

Hanspeter Mossenbock, `Compiler Construction: The Art of
Niklaus Wirth', The School of Niklaus Wirth: The Art
of Simplicity, 2000, dpunkt.verlag GmbH, pp 55-68. ISBN 1-55860-723-4

 Brantley

Re: [9fans] GUI toolkit for Plan 9

[dmr]

 > I think 3B2 code deserves its own place in hell.  Poring over
 > the ESS#5 code, someone found that there were lots of
 > strcmp(p, "f(") == 0 checks (I may have gotten the exact
 > string wrong but it's close).  It took us a while to figure
 > out why.  Apparently, location 0 on the 3b had the 3 bytes
 > 'f' '(' '\0', someone noticed that when programs blew up
 > they were pointing to "f(", and the worlds most amazing
 > kludge for detecting nil pointers was born.

Happily, it wasn't actually 5ESS, only Unix.

	Dennis

Re: [9fans] GUI toolkit for Plan 9

[David Gordon Hogan]

> Anyone thought of using a file system instead of the actual
> libcontrol design? I mean, stuff like:

Yes, Geoff Langdale did something like this a number
of years ago.  I don't know what happened to it.

Re: [9fans] GUI toolkit for Plan 9

[Fco.J.Ballesteros]

Anyone thought of using a file system instead of the actual
libcontrol design? I mean, stuff like:

mkdir /mnt/gui/panel
echo 'align center' >/mnt/gui/panel/ctl
mkdir /mnt/gui/panel/button
echo 'press me' >/mnt/gui/panel/button/label
cat /mnt/gui/panel/events
and the like.

that would be cool to build silly guis for things like the ipaq
with just silly shell scripts behind the gui.

Re: [9fans] GUI toolkit for Plan 9

[anothy]

lucio said:
	Adding code to a computer program increases the
	probability of its being incorrect.  Prove me wrong.
then tb responded:
	Your argument is bogus, then.  If *that's* all you mean,
	then you have an argument against *ever* adding *any*
	feature to *anything*, since you would be getting
	"probably gains" and earning "possible incorrect behavior".

tb's extention of lucio's argument does not logically follow. in a
strict logical sense, this is probably because lucio isn't even
_making_ an argument (so it can't be bogus). one can indeed
make some inferences from lucio's assertion (tb: do you argue
with the assertion?), however. it seems tb reads lucio to be
implying something along these lines:
	adding code to a program increases its probability of
	being incorrect, THEREFOR you shouldn't add any code
	to any programs
but i think what lucio, and probably most of the people on the
8c side of the recent 8c/gcc discussion, meant is more like:
	adding code to a program increases its probability of
	being incorrect, THEREFOR you should be sure any gains
	won by this code are greater than this risk.
i don't think anyone here would seriously argue that the
cost/gain decisions should never be made, but rather that the
way the decisions were/are made in gcc is incorrect.
ア

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

anothy@cosym.net writes:

> but i think what lucio, and probably most of the people on the
> 8c side of the recent 8c/gcc discussion, meant is more like:
> 	adding code to a program increases its probability of
> 	being incorrect, THEREFOR you should be sure any gains
> 	won by this code are greater than this risk.
> i don't think anyone here would seriously argue that the
> cost/gain decisions should never be made, but rather that the
> way the decisions were/are made in gcc is incorrect.

Thank you for spelling it out; perhaps I did miss something in the
original statement.

However, one way to decrease the risk is simply to spend more effort
in care and fixing bugs.  Merely adding a new component need not
increase risk; it simply means that if you want to bring the risk down
to where it was before, you have to expend more effort.

Now, the GCC maintainers are willing to spend that effort.  Even if
that's a silly decision and they should be spending their time on
other things, they do spend the effort.

The real irony here is that of all the pseudo-examples tossed around,
there has been only one mention thus far of a compiler designer
introducing a willful bug for the sake of optimization, and that's in
8c.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[presotto]

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

I think 3B2 code deserves its own place in hell.  Poring over
the ESS#5 code, someone found that there were lots of
strcmp(p, "f(") == 0 checks (I may have gotten the exact
string wrong but it's close).  It took us a while to figure
out why.  Apparently, location 0 on the 3b had the 3 bytes
'f' '(' '\0', someone noticed that when programs blew up
they were pointing to "f(", and the worlds most amazing
kludge for detecting nil pointers was born.

I'm beginning to be convinced that, with the exception
of Ken's registerization, bugs in optimizing compilers
are more likely mistakes than knowing attempts to hang
over the edge too far.

I heard a rumor yesterday that I'ld like dispelled if
possible.  It was that the Linux kernel had to be compiled
with optimization turned on to work.  I just tried compiling
my Redhat system without and it crashed but then I
turned optimization on and it still didn't work, so clearly
I'm incompetent.

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

From: "AMSRL-CI-CN" <gwyn@arl.army.mil>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Thu, 28 Feb 2002 14:55:33 GMT
Message-ID: <Gs8z4H.Hwp@arl.army.mil>

<presotto@plan9.bell-labs.com> wrote in message
news:181b9e858518e43368953c1050365780@plan9.bell-labs.com...
> 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.

Long ago, I went through all the user-mode UNIX System V
source code and identified and fixed as many of these kinds
of bugs as I could find.  Unfortunately the system for trouble
reporting was utterly not up to the task of feeding these back
to the official developers.  I think finally most of them got fixed
indirectly via Sun picking them up when Guy Harris helped
merge the System V and BSD sources for them, since he had
my fixed-up System V sources to work from.

Anyway, in the process of doing that work, also in dealing
with some of the code from the AT&T UNIX System
ToolChest, I found that a lot of these VAXisms appeared to
have turned up when AT&T moved the code to 3B2s
(WE32000 architecture), but instead of changing the code to
be truly portable, workarounds were installed under control
of #ifdef u3b conditionals.  Maybe that resulted from some
policy of having to overdocument every change to the base
code unless it was made processor-specific; I don't know.

The biggest culprits seemed to be passing 0 to terminate
execl argument lists and dereferencing argv[i] before testing
for i==argc.

Re: [9fans] GUI toolkit for Plan 9

[Ralph Corderoy]

Hi Dave,

> I heard a rumor yesterday that I'ld like dispelled if possible.  It
> was that the Linux kernel had to be compiled with optimization turned
> on to work.

AIUI that's correct.  gcc only inlines requested functions if -O, or
-O2, etc., has been given.  If there's no `fall back' implementation of
a requested-to-be-inlined function provided then you end up with an
undefined reference, i.e. function foo doesn't exist anywhere.  Linux
puts many such `inline' functions in headers files in place of
pre-processor macros.

    http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_5.html#SEC102

The norm is to -O2 the Linux kernel.

Cheers,


Ralph.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

presotto@plan9.bell-labs.com writes:

> I heard a rumor yesterday that I'ld like dispelled if
> possible.  It was that the Linux kernel had to be compiled
> with optimization turned on to work.  

That has been true for some versions; it's a programmer bug.

Specifically, there are certain kinds of inlining that happen only
when optimizing, and Linux required those to occur.  For example, in
GCC, if you define a function like:

extern inline foo (...) {...}

Then you get a function which will be inlined (but generally only if
optimization is turned on); if it's not inlined, then no code is
output at all for the function.  (You are supposed to link with a
regular static version too.)  Such "extern inline" declarations are
normally put in header files.

Linux had problems like these, where it was using such inlines, but
didn't provide the static version.  So when optimization is turned
off, the inline doesn't happen, and you get an unresolvable external
reference.

There may have been other problems too.  These are all in the category
of programmer errors.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Martin C.Atkins]

Hi,

On Thu, 28 Feb 2002 10:22:23 -0500 presotto@plan9.bell-labs.com wrote:
> I think 3B2 code deserves its own place in hell.  Poring over
> the ESS#5 code, someone found that there were lots of
> strcmp(p, "f(") == 0 checks (I may have gotten the exact
> string wrong but it's close).  It took us a while to figure
> out why.  Apparently, location 0 on the 3b had the 3 bytes
> 'f' '(' '\0', someone noticed that when programs blew up
> they were pointing to "f(", and the worlds most amazing
> kludge for detecting nil pointers was born.
> 

Thank god for Dennis's statement that this wasn't the 5ESS - one
replaced our local exchange just earlier this week! :-)
(and it broke things... Right now one of our lines is dead.
BTW: this is in India, *not* the UK, before people get confused
by my signature...)

> I heard a rumor yesterday that I'ld like dispelled if
> possible.  It was that the Linux kernel had to be compiled
> with optimization turned on to work.  I just tried compiling
> my Redhat system without and it crashed but then I
> turned optimization on and it still didn't work, so clearly
> I'm incompetent.

I'm sorry that I can't remember *any* attribution, but I thought it
was "common wisdom/knowledge" that gcc only really worked properly
with -O turned on. That the optimiser "optimised away the bugs put in
by the code generator". This is going back a few years, so it may be
things have "improved"?

Martin

-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

martin@mca-ltd.com (Martin C.Atkins) writes:

> I'm sorry that I can't remember *any* attribution, but I thought it
> was "common wisdom/knowledge" that gcc only really worked properly
> with -O turned on. That the optimiser "optimised away the bugs put in
> by the code generator". This is going back a few years, so it may be
> things have "improved"?

One of the dangerous things about FUD is that people continue to
repeat it, when it was never true, without attribution except as
"common wisdom".

Re: [9fans] GUI toolkit for Plan 9

[Martin C.Atkins]

On Mon, 4 Mar 2002 10:07:09 GMT "Thomas Bushnell, BSG" <tb+usenet@becket.net> wrote:
> martin@mca-ltd.com (Martin C.Atkins) writes:
> 
> > I'm sorry that I can't remember *any* attribution, but I thought it
> > was "common wisdom/knowledge" that gcc only really worked properly
> > with -O turned on. That the optimiser "optimised away the bugs put in
> > by the code generator". This is going back a few years, so it may be
> > things have "improved"?
> 
> One of the dangerous things about FUD is that people continue to
> repeat it, when it was never true, without attribution except as
> "common wisdom".

That's as may be. But it never occurred to me that this might be FUD
(until you kindly pointed it out). Rather, I thought it was a
curiosity about the way that gcc's code generation worked (and not
*inherently* incorrect, so long as one didn't regard compiling
without -O as "compiling"), and - more importantly - a hint as to how
to avoid unnecessary pain (to me, as a user of gcc, at that time, and
still now).

(After all, I'm still really a Linux lurker. Also, having lost most
of yesterday trying to get Plan 9 to install on a new machine without
destroying it's partition table (I tried 3 times before giving up and
zeroing the disk), I'm not too well disposed to Plan9 right now.
Although to be fair, it's working great now..... - BTW: What *does*
"panic iunlock" mean (I think that was it), apart from "You're
stuffed - go and hit your head on a nearby wall, and then start
over..."? First time I thought it was because I had done something
silly, but the second time I *hadn't* done the silly thing....
Still, at least the good side effect is that I no-longer have Windows
on the machine :-) )

BTW: what's the Plan9 equivalent of Unix's "find . -name ... -print"? 
(always a good fallback for a beginner :-)

Martin
-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] GUI toolkit for Plan 9

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>


> Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
> people use GCC than 8c.  There are two reasons:
> 
> GCC generates better code
> GCC has a more liberal license than 8c.

There is also a third reason:
There are programs that use gcc features not present in any other c
compiler. So one needs atleast to have gcc. And once that is decided,
why bother with yet another c compiler?
(The same thing happens with gmake)


bengt

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

eleberg@cbe.ericsson.se (Bengt Kleberg) writes:

> There is also a third reason:
> There are programs that use gcc features not present in any other c
> compiler. So one needs atleast to have gcc. And once that is decided,
> why bother with yet another c compiler?
> (The same thing happens with gmake)

Yes, that's true.  (Ironically, the GNU Project generally prohibits
the use of gcc-specific extensions in its software in order to
encourage greater portibility.)

Re: [9fans] GUI toolkit for Plan 9

[Richard Uhtenwoldt]

Thomas: 

>> Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
>> people use GCC than 8c.  There are two reasons:
>> 
>> GCC generates better code
>> GCC has a more liberal license than 8c.

Bengt Kleberg writes:

>There is also a third reason:

Fourth reason: when Plan 9's license was liberalized 2 years ago, gcc
was already well entrenched.  before the liberalization I think using
8c would've cost you $400.  

2 years ago, there was already so much invested in gcc that technical
and minor license differences between it and its competitors make
almost no difference.  eg, Intel invested in it to support ia64.  eg,
Glasgow Haskell Compiler and Mercury compiler and probably a lot of
others I do not know about compile to gcc-specific C to take advantage
of the investments made on gcc backends.

So, like Windows 3/95/98/ME, it does not have to be good; 
large network effects keep it popular, good or not.

Re: [9fans] GUI toolkit for Plan 9

[presotto]

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

Bushnell is right.  There's nothing wrong with having heavy duty
optimizations.  Just because you have to use them with caution
doesn't mean they shouldn't be available.  The problem of compiler
complexity is a problem for those developing/maintaining it, not
necessarily for those using it, modulo compile time and you can
get some of that back by backing off the optimization level.
If I had to support GCC I'ld go nuts but as long as someone else is
willing to, why not?  Luckily dhog doesn't have to worry as much
about pulling his hair out.

Having a license that encourages gobs of people to work on
components of the system is nice.  I wish we had such a license
to find out if it is indeed the license that causes that
and not some inherent attraction of the code or system.
A pity that we're held hostage by a lawyer.

Plan 9 held hostage - day 4232

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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Wed, 27 Feb 2002 10:20:36 GMT
Message-ID: <87664jxrsw.fsf@becket.becket.net>

edorman@san.rr.com (Eric Dorman) writes:

> IMHO the real deal is whether it's fast enough to do what you want
> it to do.  No doubt 8c would benefit if it had the same zillions 
> of both paid and unpaid hours gcc has, but that's not saying 
> anything earth-shattering; for this particular app it does reasonably
> well, IMO, given the level of effort put into it.  If somebody 
> wants 8c to go faster then they are welcome to turn the crank 
> to make it happen....

Sure, GCC has available way more person-hours to try and get every
last bit of improvement out of the generated code, and 8c just doesn't
have that much time available.  I think Dan Cross is entirely right in
suggesting that such speed improvements might not be worth the effort
it would take to put them into 8c.

But that's only an argument against adding gobs of hairy optimization
to 8c; it's not an argument for why GCC is somehow *bad* for having
such optimizations.  Indeed, it's really an argument for why dropping
8c is the best thing to do!  But then, 8c does really have a great
advantage in speed-of-compilation.  So both compilers are doing useful
things.

Incidentally, the reason GCC has gobs of people working on it is
pretty darn simple.  It's because GCC has a license which encourages
gobs of people to work on it.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>

> 
> presotto@plan9.bell-labs.com writes:
> 
> > However, it seems to be an accepted consequence amongst compiler
> > writers to trade off _possible_ incorrect code generation against
> > _probable_ speed gains.
> 
> I've never heard someone say that, actually.  Perhaps you could give a
> citation from a compiler writer who said "yeah, this generates
> incorrect code, but hey, it runs fast!"?

I have added _ to emphasize two words that makes the idea clearer. Ie,
it not a question of generating incorrect code, but generating code
that might be incorrect (you know: hard to debug/test for all possible
circumstances...).


bengt

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 11:57:58AM +0100, Bengt Kleberg wrote:
> > 
> > presotto@plan9.bell-labs.com writes:
> > 
> > > However, it seems to be an accepted consequence amongst compiler
> > > writers to trade off _possible_ incorrect code generation against
> > > _probable_ speed gains.
> > 
[ Thomas Bushnell quote adding nothing to the above :-) ]
> 
> I have added _ to emphasize two words that makes the idea clearer. Ie,
> it not a question of generating incorrect code, but generating code
> that might be incorrect (you know: hard to debug/test for all possible
> circumstances...).
> 
I would have used "potential" in the first position, specially as
chips keep changing, I watch in dismay as the binutils mailing lists
tries to follow the ARM and MIPS architecture variations saga :-)

In the second position, I would prefer "likely" because I'm of the
opinion that those who invest in optimisation have a clear-ish idea of
the objectives they are trying to achieve.  That these objectives are
short-lived is hardly their fault :-)

++L

Re: [9fans] GUI toolkit for Plan 9

[Fco.J.Ballesteros]

: But that's only an argument against adding gobs of hairy optimization
: to 8c; it's not an argument for why GCC is somehow *bad* for having
: such optimizations.  Indeed, it's really an argument for why dropping

Once good thing of 8c/8l as they are today is that it's far more easy to
port them that it is to port gcc. IMHO, this is mostly due to the fact that
they are quite simple. So, I'd consider the complexity increase of 8c as
a thing to consider before actually `improving' it. If it gets a bit better
but the price to pay is to make it less simple to port/change, I'd think
twice.

Re: [9fans] GUI toolkit for Plan 9

[Fco.J.Ballesteros]

Calm down Tom, we all know you always have interesting
things to say.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

nemo@plan9.escet.urjc.es (Fco.J.Ballesteros) writes:

> Calm down Tom, we all know you always have interesting
> things to say.

Who are you talking about?

Re: [9fans] GUI toolkit for Plan 9

[forsyth]

> Your concern reminds me of people who are scared of garbage collection
> because they think it will have a bug and free live memory.  

this seems to me to ignore the complexity of both theory and code in
the two cases; i'd have said they were significantly different by
inspection.

for instance, i might well consider working hard to prove (formally or informally)
the bulk of a garbage collector; for non-trivial language i don't
think i'd attempt more than proving correct (or arguing the correctness of)
some of the theoretical foundations and abstract algorithms of an
optimising compiler.

Re: [9fans] GUI toolkit for Plan 9

[presotto]

[-- 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?

Re: [9fans] GUI toolkit for Plan 9

[Eric Dorman]

Who said something about feeding the troll?  Hehe.
I'm in a benchmarky mood since I'm doing the same thing
in baselining our project code in my day job.  

Anyway here's a sort-of integer-ish comparison:

Test case is the ancient Little Smalltalk v3.  The benchmark
is running the compiled interpreter on multiple iterations 
of the test suite.  All tests passed (such as they are :) ).  
This is mostly indexing, switches and indirections.  FP is 
also a test case but the impact of the bytecode interpreter 
is far more significant.

On Plan9, the interpreter use bio(2) so compiles directly under 
8c rather than ape (a port done by myself).  There are no other
changes from the Linux code.  For gcc the environment was 
RH-Linux-7.2 running w/o gui.  The hardware was a 2xP-III @ 1.0Ghz.  
Plan9 netbooted onto the same hardware.  I/O was not tested.  
The application isin't multithreaded so any SMP overhead is 
the OS's own fault :) .. gcc-3.0.3 and -2.96 were used, with 
no significant differences in the results (except as noted).  
-mcpu=i386 was used for all gcc's (note 'i386' vice '386'; see 
gcc -dumpspecs).  With other interpreters (like Squeak Smalltalk,
which gnu-ifies the interpreter to exploit gcc-isims)
playing with -mcpu can get you 2-5% but there is a lot of
coupling between architecture, -mcpu, -O level and etc.  YMMV.

Generally gcc -O was 3% avg faster than 8c for all iteration 
sizes.  gcc -O2 was 7% avg faster than 8c for all sizes.  
Higher -O levels had no significant impact. 

8c -N was 17% slower than 8c.  Oddly gcc-2.96 was 33% slower 
than gcc -O.  gcc-3.0.3 was better, 13% slower than gcc-3.0.3 -O.

Time-to-compile is hard to compare since Linux runs on the local
ATA100 disk while Plan9 runs from a fileserver on switched 
100BaseT, and there really isin't all that much code to 
compile :)  Anyway gcc-3.0.3 clocks in at ~ 3.2 secs ( -j1 ) 
while Plan9 compiles in about a second (NPROC=1).  I don't have 
much faith in these numbers, however; too much variance.  Then
again, gcc-3.0.3 takes > 7minutes to compile itself (all stages 
plus library) -j2, but 8c takes a few seconds at NPROC=2.  My
experiences with gcc have led me to put little faith in the stage[12]
exercise as a verification tool.

IMHO the real deal is whether it's fast enough to do what you want
it to do.  No doubt 8c would benefit if it had the same zillions 
of both paid and unpaid hours gcc has, but that's not saying 
anything earth-shattering; for this particular app it does reasonably
well, IMO, given the level of effort put into it.  If somebody 
wants 8c to go faster then they are welcome to turn the crank 
to make it happen....

Regards,

Eric.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

edorman@san.rr.com (Eric Dorman) writes:

> IMHO the real deal is whether it's fast enough to do what you want
> it to do.  No doubt 8c would benefit if it had the same zillions 
> of both paid and unpaid hours gcc has, but that's not saying 
> anything earth-shattering; for this particular app it does reasonably
> well, IMO, given the level of effort put into it.  If somebody 
> wants 8c to go faster then they are welcome to turn the crank 
> to make it happen....

Sure, GCC has available way more person-hours to try and get every
last bit of improvement out of the generated code, and 8c just doesn't
have that much time available.  I think Dan Cross is entirely right in
suggesting that such speed improvements might not be worth the effort
it would take to put them into 8c.

But that's only an argument against adding gobs of hairy optimization
to 8c; it's not an argument for why GCC is somehow *bad* for having
such optimizations.  Indeed, it's really an argument for why dropping
8c is the best thing to do!  But then, 8c does really have a great
advantage in speed-of-compilation.  So both compilers are doing useful
things.

Incidentally, the reason GCC has gobs of people working on it is
pretty darn simple.  It's because GCC has a license which encourages
gobs of people to work on it.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> 
> Incidentally, the reason GCC has gobs of people working on it is
> pretty darn simple.  It's because GCC has a license which encourages
> gobs of people to work on it.
> 
"Incidentally", he says!  Licence to bloat?

On the NetBSD mailing lists we have a saying: "If you want Linux, you
know where to find it."

Now please go away.

++L

Re: [9fans] GUI toolkit for Plan 9

[Boyd Roberts]

I have wasted more time than I care to remember fighting
with GNU / lunix (sic).  Simple is good, simple works ...

I think the compiler design in Plan 9 was an brilliant
piece of work, not that I'm blind to the flaws, but I
can live with that.

GNU - Gnu's Not Useful

Re: [9fans] GUI toolkit for Plan 9

[Ish Rattan]

On Wed, 27 Feb 2002, Lucio De Re wrote:

> On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> >
> > Incidentally, the reason GCC has gobs of people working on it is
> > pretty darn simple.  It's because GCC has a license which encourages
> > gobs of people to work on it.
> >
> "Incidentally", he says!  Licence to bloat?
>
> On the NetBSD mailing lists we have a saying: "If you want Linux, you
> know where to find it."
>
> Now please go away.

I will second the sentiment.

-ishwar

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> Now please go away.

Naw, this is Usenet!  

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 02:44:34PM -0800, Thomas Bushnell, BSG wrote:
> 
> lucio@proxima.alt.za (Lucio De Re) writes:
> 
> > Now please go away.
> 
> Naw, this is Usenet!  

Like, you own it or something?!

Just keep your licence arguments to yourself, then.

++L

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> Just keep your licence arguments to yourself, then.

I didn't make any argument, I explained a fact that was brought up by
other people.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> On Wed, Feb 27, 2002 at 10:20:36AM +0000, Thomas Bushnell, BSG wrote:
> > 
> > Incidentally, the reason GCC has gobs of people working on it is
> > pretty darn simple.  It's because GCC has a license which encourages
> > gobs of people to work on it.
> > 
> "Incidentally", he says!  Licence to bloat?
> 
> On the NetBSD mailing lists we have a saying: "If you want Linux, you
> know where to find it."

Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
people use GCC than 8c.  There are two reasons:

GCC generates better code
GCC has a more liberal license than 8c.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Matt H]

> Odd that NetBSD uses GCC, isn't it?  No, it's no great wonder why more
> people use GCC than 8c.  There are two reasons:
> 
> GCC generates better code
> GCC has a more liberal license than 8c.

I really don't believe that *you* actually believe that these are anything
like the reasons

You're just being stupid and childishly antagonistic  
(like some other ppl round here!).

I can almost absolutely guarantee that the popularity of plan9 or 8c has
*nothing* to do with the license.

Would you seriously have me believe that if plan9 went public domain
tomorrow then by the end of March it would have 100 more users, 10
even! I doubt even Thomas G Bushnell would be using it!

Can we take it as a given that the people on this list who have any
influence on the people that decide the license actually want it changing
and have tried, without success, to make the change and that going to the
legal department every day and saying "can we make it GPL please? can we?
can we? please? pretty please? pretty please with sugar on" would actually
be counter productive.

And given that, then repeatedly mentioning it is tiresome and has a
negative impact on the morale and development of the plan9 community.

It's getting as bad as all the "don't send html email to this list"
arguments I see every day.

Matt

Re: [9fans] GUI toolkit for Plan 9

[chad]

> From: Matt H <matt@proweb.co.uk>
> ...
> Would you seriously have me believe that if plan9 went public domain
> tomorrow then by the end of March it would have 100 more users, 10
> even! I doubt even Thomas G Bushnell would be using it!

Without much effort, I can think of about half a dozen people at/around
MIT who aren't using Plan 9 right now who would be by the end of March
if `plan9 went public domain tomorrow'.  I suspect that the actual
number is much higher, actually, but that many of them would stop after
a few months.

None of the people I'm thinking of are what I'll call `hard line' free
software bigots.  Some of them simply chose to spend their time on more
`open' projects, while some of them simply cannot accept the ``I give up
my right to legal recourse if Lucent ever does anything bad to me''
clause.

It's natural and laudable to try to defend something that you like and
care for, but let's be honest here - even the core Plan 9 guys wish that
the license were `better'.  ``It is an imperfect world in which we
live.''  While license arguments have become common in some venues, and
I'm sure that they'll erupt here now and then, I (seriously!) suggest
something like:

``Yeah, the license isn't the best right now, but it's been improving
over time, and you can hardly blame `beleaguered' companies like Lucent
for being a little slow to come around.  We're using what we have now,
and in a year or two hoping that it'll get better still again.''

thanks,
chad

Re: [9fans] GUI toolkit for Plan 9

[ozan s yigit]

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

> Incidentally, the reason GCC has gobs of people working on it is
> pretty darn simple.  It's because GCC has a license which encourages
> gobs of people to work on it.

well, lcc has a license that would not be offensive to most people,
but to my knowledge, the same kind of effort is not expanded on it.
except norman wilson, noone uses it in production. so it does not
optimize; there has been a few optimizers that can be wired with lcc
(as i pointed out in the distant past), but noone wants to bother.
there must be another reason why people keep hacking gcc to death.
maybe it is complexity or fame or both; certainly easier to get
name recognition with gcc than with lcc for sure...

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] GUI toolkit for Plan 9

[AMSRL-CI-CN]

<presotto@plan9.bell-labs.com> wrote in message
news:181b9e858518e43368953c1050365780@plan9.bell-labs.com...
> 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.

Long ago, I went through all the user-mode UNIX System V
source code and identified and fixed as many of these kinds
of bugs as I could find.  Unfortunately the system for trouble
reporting was utterly not up to the task of feeding these back
to the official developers.  I think finally most of them got fixed
indirectly via Sun picking them up when Guy Harris helped
merge the System V and BSD sources for them, since he had
my fixed-up System V sources to work from.

Anyway, in the process of doing that work, also in dealing
with some of the code from the AT&T UNIX System
ToolChest, I found that a lot of these VAXisms appeared to
have turned up when AT&T moved the code to 3B2s
(WE32000 architecture), but instead of changing the code to
be truly portable, workarounds were installed under control
of #ifdef u3b conditionals.  Maybe that resulted from some
policy of having to overdocument every change to the base
code unless it was made processor-specific; I don't know.

The biggest culprits seemed to be passing 0 to terminate
execl argument lists and dereferencing argv[i] before testing
for i==argc.

Re: [9fans] GUI toolkit for Plan 9

[Russ Cox]

> > Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> > against fast compilers - I'm actually rather impressed by good
> > compilers - but I do fret about optimizing compilers breaking my code.
> 
> Oh, of course, but that's a matter of writing correct code.

No, it's also a matter of not having buggy optimizers.

> Your concern reminds me of people who are scared of garbage collection
> because they think it will have a bug and free live memory.  

And this is a matter of not having buggy garbage collectors.

In both case you are assuming that the optimizer/garbage
collector itself has no bugs, which is not always a great assumption.

In both cases it's a case of balancing the benefit you gain
from the chance of a negative effect due to bugs in the
optimizer/garbage collector.  If having ten times as many
optimizations comes at the cost of having ten times as many
optimizer bugs, then I'd think twice about it.

In the optimizer case, the number of confirmed gcc optimizer
bugs at any given time seems to be fairly high, high enough
that reasonable people can run into them with annoying
frequency, especially on non-x86 platforms.  (I know of an
undergrad OS course that was using the latest gcc MIPS
compiler and ran into many of these; in that case, though,
there was no hope: turning off optimizations just selected
a different set of code generation bugs.)

Russ

Re: [9fans] GUI toolkit for Plan 9

[presotto]

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

No, it's not really the same.  I've had odd performance changes
when garbage collectors decide to do their thing.  However, they've
never made correct code not work.  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.

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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 17:13:14 GMT
Message-ID: <87664kgoie.fsf@becket.becket.net>

rob@plan9.bell-labs.com (rob pike) writes:

> Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> against fast compilers - I'm actually rather impressed by good
> compilers - but I do fret about optimizing compilers breaking my code.

Oh, of course, but that's a matter of writing correct code.

Your concern reminds me of people who are scared of garbage collection
because they think it will have a bug and free live memory.  

Re: [9fans] GUI toolkit for Plan 9

[Mike Haertel]

 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?

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

presotto@plan9.bell-labs.com writes:

> However, it seems to be an accepted consequence amongst compiler
> writers to trade off possible incorrect code generation against
> probable speed gains.

I've never heard someone say that, actually.  Perhaps you could give a
citation from a compiler writer who said "yeah, this generates
incorrect code, but hey, it runs fast!"?

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 10:07:13AM +0000, Thomas Bushnell, BSG wrote:
> 
> presotto@plan9.bell-labs.com writes:
> 
> > However, it seems to be an accepted consequence amongst compiler
> > writers to trade off possible incorrect code generation against
> > probable speed gains.
> 
> I've never heard someone say that, actually.  Perhaps you could give a
> citation from a compiler writer who said "yeah, this generates
> incorrect code, but hey, it runs fast!"?

That's being intentionally obtuse.  Adding code to a computer program
increases the probability of its being incorrect.  Prove me wrong.

++L

Re: [9fans] GUI toolkit for Plan 9

[Graham Gallagher]

Lucio De Re wrote:
> 
> That's being intentionally obtuse.  Adding code to a computer program
> increases the probability of its being incorrect.  Prove me wrong.

Science of Programming, David Gries, p168

"Doug McIlroy (Bell Laboratories) disagrees with this argument, claiming
that correct programs *are* made from incorrect parts. Telephone control
programs, for example, are more than half audit code, whose business is
to recover from unintended states, and the audit code has been known to
mask software as well as hardware errors."

Re: [9fans] GUI toolkit for Plan 9

[Lucio De Re]

On Wed, Feb 27, 2002 at 11:21:22PM +1100, Graham Gallagher wrote:
> 
> "Doug McIlroy (Bell Laboratories) disagrees with this argument, claiming
> that correct programs *are* made from incorrect parts. Telephone control
> programs, for example, are more than half audit code, whose business is
> to recover from unintended states, and the audit code has been known to
> mask software as well as hardware errors."

Now I'm obtuse.  From the above, I can't decide whether that means
that enough code will catch all possible errors (quis custodet
custodes?) or that one can insanely keep chasing one's own tail.

I think the jury will stay out on that one :-)

I wouldn't mind some clarification as to "this argument" mentioned in
the quote.  I don't have a copy of Gries's book handy :-)

++L

Re: [9fans] GUI toolkit for Plan 9

[Graham Gallagher]

Lucio De Re wrote:
> 
> On Wed, Feb 27, 2002 at 11:21:22PM +1100, Graham Gallagher wrote:
> >
> > "Doug McIlroy (Bell Laboratories) disagrees with this argument, claiming
> > that correct programs *are* made from incorrect parts. Telephone control
> > programs, for example, are more than half audit code, whose business is
> > to recover from unintended states, and the audit code has been known to
> > mask software as well as hardware errors."
> 
> Now I'm obtuse.  From the above, I can't decide whether that means
> that enough code will catch all possible errors (quis custodet
> custodes?) or that one can insanely keep chasing one's own tail.
> 
> I think the jury will stay out on that one :-)
> 
> I wouldn't mind some clarification as to "this argument" mentioned in
> the quote.  I don't have a copy of Gries's book handy :-)

The McIlroy quote was a counterexample to the argument:

"Suppose a program consists of n small components - i.e. procedures,
modules - each with probability p of being correct. Then the probability
P that the whole program is correct certainly satisfies P < p^n".

Re: [9fans] GUI toolkit for Plan 9

[ozan s yigit]

> Science of Programming, David Gries, p168
	...
> "Doug McIlroy (Bell Laboratories) disagrees with this argument, claiming
> that correct programs *are* made from incorrect parts.

my money is on Doug McIlroy. Gries stopped programming a long time ago. :)

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] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> > > However, it seems to be an accepted consequence amongst compiler
> > > writers to trade off possible incorrect code generation against
> > > probable speed gains.
> > 
> > I've never heard someone say that, actually.  Perhaps you could give a
> > citation from a compiler writer who said "yeah, this generates
> > incorrect code, but hey, it runs fast!"?
> 
> That's being intentionally obtuse.  Adding code to a computer program
> increases the probability of its being incorrect.  Prove me wrong.

Your argument is bogus, then.  If *that's* all you mean, then you have
an argument against *ever* adding *any* feature to *anything*, since
you would be getting "probably gains" and earning "possible incorrect
behavior".

Re: [9fans] GUI toolkit for Plan 9

[AMSRL-CI-CN]

"Lucio De Re" <lucio@proxima.alt.za> wrote in message
news:20020227122932.M26250@cackle.proxima.alt.za...
> That's being intentionally obtuse.  Adding code to a computer program
> increases the probability of its being incorrect.  Prove me wrong.

That wasn't what Presotto said, and it's an abuse of the term
"probability".

Re: [9fans] GUI toolkit for Plan 9

[AMSRL-CI-CN]

<presotto@plan9.bell-labs.com> wrote in message
news:ce0ce59eb0d583584480f57dde2bd1a2@plan9.bell-labs.com...
> ... However, it seems to be an
> accepted consequence amongst compiler writers to trade off
> possible incorrect code generation against probable speed
> gains.

The compiler developers I know don't accept that trade-off.
However, C is unique in that there are many "fuzzy" areas of
the language where determining what is and is not permitted
by the compiler is difficult.  That's because of C's heritage as
a systems implementation language and the associated desire
to permit as much optimization as feasible without making the
language untrustworthy when used competently.  The current
rules for C allow a lot of optimization, but there are also rules
for programming so as to not be bitten by the optimizations.

It is certainly true that some over-zealous compiler hackers
have introduced bugs from time to time.  But these are
generally acknowledged to be bugs and are fixed when they
turn up.

Re: [9fans] GUI toolkit for Plan 9

[andrey mirtchovski]

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

> On the other hand, though I hardly use C much (though I compile a lot of it), I
> have had weird behaviour under -O2, which went away when I removed it.  The gcc
> people are always messing with the optimizer.  That personal experience
> combined with reading docs that say things like "the loop unroller is buggy, so
> be careful when you use -O3" (and what's the deal with all this -O6 stuff?  I
> thought -O3 was the "possible overkill, may slow down code more than speed it
> up" setting) has made me paranoid and now when the compiler segfaults or the
> program segfaults (often C generated by a compiler for another language, which
> is probably particularly strangely written), the first thing I do is remove -O.
> And it sometimes fixes the problem.  For example, the sather compiler will
> segfault if compiled with -O.

http://www.netlib.org/benchweb has several integer-intensive cpu
benchmarks.  i downloaded the tower of hanoi to try a few benchy-marks
just to continue yesterday's tests.

i gave up after finding out that the optimized fbsd ran slower than
the unoptimized one (2.95)..  same behaviour was observed with gcc3.0
on linux...  i can only explain this with the recursive structure of
the program...

having such (weird?) results kind-of defeats the purpose of doing 
a  benchmark...  so i never looked at compiling it on p9

if anyone else is interested, the cpu section of the abovementioned
web page has some more programs.  i tried a few but didn't find
anything interesting


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

From: Quinn Dunkan <quinn@bolivar.ugcs.caltech.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Tue, 26 Feb 2002 09:48:39 -0800
Message-ID: <20020226174844.9D73634086@bolivar.ugcs.caltech.edu>


> rob@plan9.bell-labs.com (rob pike) writes:
> 
> > Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> > against fast compilers - I'm actually rather impressed by good
> > compilers - but I do fret about optimizing compilers breaking my code.
> 
> Oh, of course, but that's a matter of writing correct code.
> 
> Your concern reminds me of people who are scared of garbage collection
> because they think it will have a bug and free live memory.  

I've always used gc-ed languages, and I've never had any problems due to buggy
gc (except some surprising performance differences between cmucl on x86 and
cmucl on everything else, since they use different gcs).  Once they get the gc
right they tend to leave it alone.

On the other hand, though I hardly use C much (though I compile a lot of it), I
have had weird behaviour under -O2, which went away when I removed it.  The gcc
people are always messing with the optimizer.  That personal experience
combined with reading docs that say things like "the loop unroller is buggy, so
be careful when you use -O3" (and what's the deal with all this -O6 stuff?  I
thought -O3 was the "possible overkill, may slow down code more than speed it
up" setting) has made me paranoid and now when the compiler segfaults or the
program segfaults (often C generated by a compiler for another language, which
is probably particularly strangely written), the first thing I do is remove -O.
And it sometimes fixes the problem.  For example, the sather compiler will
segfault if compiled with -O.

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

It's too early to be writing mail.  In this:

> I doubt the quality of complation of the kernel has a
> minor effect on runtime of the compiler itself.

I should have said 'major'. My point is that the compiler
will not affect the efficiency of the kernel very much,
as I hope the rest of the post explained better.

-rob

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

> Somehow I doubt 25,000 lines...

As someone who's looked at MIPS's assembly-language code for
FP support in the kernel, I don't doubt this at all.

-rob

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

> Speed is really important, of course, but it's usually thought that
> this is the reason why we want optimizing compilers.  

Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
against fast compilers - I'm actually rather impressed by good
compilers - but I do fret about optimizing compilers breaking my code.
Fancy optimizers have fancy bugs.  I'd happily give up the 10% or 20%
those 25,000 lines of code on the MIPS give me if I knew that would
reduce the probability of bugs.

On Plan 9, the code optimizer is enabled by default.  It's been years
since I turned it off (8c -N) to see if the optimizer was breaking my
code, and much longer than that since it did.

-rob

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> against fast compilers - I'm actually rather impressed by good
> compilers - but I do fret about optimizing compilers breaking my code.

Oh, of course, but that's a matter of writing correct code.

Your concern reminds me of people who are scared of garbage collection
because they think it will have a bug and free live memory.  

Re: [9fans] GUI toolkit for Plan 9

[Dan Cross]

I guess I just don't see the point in investing a lot of time and
effort into writing a really serious optimizer, Tom, if it's not really
needed.  I don't think that anyone is trying to use Plan 9 as a
seriously fast number crunching platform, after all.

Empirically, it's been shown that optimizers buy you roughly a factor
of two in terms of speed increase for most benchmarks (cf. Pugh's
comments on Probsting's law).  While I'm not going to throw away that
factor of two, I'm also not going to go so incredibly far out of my way
to as to invest man years of effort in creating an optimizer that will
give me just a few percent more in terms of performance, and certainly
I'm not going to go out of my wy to build a compiler that optimizes a
problem I'm not really all that concerned with (eg, floating point
intensive applications).

I'm not sure what your argument is, Tom; could you maybe post some data
to back up your claim that an operating system compiled with an
optimizing compiler (and, btw, the Plan 9 C compilers are optimizing
compilers, they just don't break their necks optimizing...) is more
than a few percent faster than one compiled with a non-optimizing
compiler?  Perhaps a literature search will give you a pointer to a
reference paper that backs up your claims?  Otherwise, it seems to me
that this is just speculation on your part.

	- Dan C.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> ...Tom...

Dan has this annoying habit of refusing to address me by my name
(despite having been asked on numerous occasions to do so).  Since his
goal is apparently to be offensive, I'm not going to bother reading or
responding to messages from him which continue to perpetrate the
offense.  I was always taught that it was a minimal human courtesy to
address people by their names.

I only mention this because I don't want someone to think that the
reason I ignore such messages is because I don't have anything to say
to them on content.

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Quinn Dunkan]

> rob@plan9.bell-labs.com (rob pike) writes:
> 
> > Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> > against fast compilers - I'm actually rather impressed by good
> > compilers - but I do fret about optimizing compilers breaking my code.
> 
> Oh, of course, but that's a matter of writing correct code.
> 
> Your concern reminds me of people who are scared of garbage collection
> because they think it will have a bug and free live memory.  

I've always used gc-ed languages, and I've never had any problems due to buggy
gc (except some surprising performance differences between cmucl on x86 and
cmucl on everything else, since they use different gcs).  Once they get the gc
right they tend to leave it alone.

On the other hand, though I hardly use C much (though I compile a lot of it), I
have had weird behaviour under -O2, which went away when I removed it.  The gcc
people are always messing with the optimizer.  That personal experience
combined with reading docs that say things like "the loop unroller is buggy, so
be careful when you use -O3" (and what's the deal with all this -O6 stuff?  I
thought -O3 was the "possible overkill, may slow down code more than speed it
up" setting) has made me paranoid and now when the compiler segfaults or the
program segfaults (often C generated by a compiler for another language, which
is probably particularly strangely written), the first thing I do is remove -O.
And it sometimes fixes the problem.  For example, the sather compiler will
segfault if compiled with -O.

Re: [9fans] GUI toolkit for Plan 9

[William Josephson]

On Tue, Feb 26, 2002 at 05:13:14PM +0000, Thomas Bushnell, BSG wrote:
> rob@plan9.bell-labs.com (rob pike) writes:
> 
> > Ten percent buys you, what, a couple of weeks of Moore's Law?  I'm not
> > against fast compilers - I'm actually rather impressed by good
> > compilers - but I do fret about optimizing compilers breaking my code.
> 
> Oh, of course, but that's a matter of writing correct code.
> 
> Your concern reminds me of people who are scared of garbage collection
> because they think it will have a bug and free live memory.  

No, if that were the case, I'd be forced to conclude that those who
write garbage collectors are significantly better hackers than the
people who write compilers, which I rather doubt.  Last year someone
across the hall spent a long time tracking down completely bogus code
produced by gcc on the mips target -- I think it turned out to be a
bug in loop unrolling, but I don't recall for sure.  I wish I still
had the thirty or forty line C program that gcc couldn't produce valid
alpha assembler for.  I have had problems with commercial compilers,
too, of course.  The fact of the matter is that I have had far more
trouble from optimizing compilers than from garbage collectors,
whether I've written them or someone else has.

Re: [9fans] GUI toolkit for Plan 9

[geoff]

John Mashey (of AT&T then MIPS then SGI then MIPS and now Sensei
Partners) gave talks at the University of Toronto in the 1980s on the
MIPS architecture and why it would kill the evil 386 archtitecture.
At one of his early talks, he talked about the lengths that the MIPS
optimiser could go to because of customer demand (`some of our
customers will perform hideous obscenities for another 5%' is the
quote I recall, though it might have been 10%, it's been a while).  He
said that the MIPS C compiler at that time was 250,000 lines of source
(presumably C). At a later talk, the size had grown to 500,000 lines.
So I wouldn't be surprised if enormous amounts of code are expended on
seemingly minor details.

Re: [9fans] GUI toolkit for Plan 9

[andrey mirtchovski]

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

i did that about a year ago -- p9 and linux on identical hardware.  i
think i did post the results here..  i still have kept a powerpoint
presentation that should have them mentioned too, i can put it
somewhere on the web if you want..

in short, p9 was lagging insignificantly (something like 2 seconds out
of 60) for pov-ray image rendering (no IO)..  for dna sequence matching (fasta
algorithm) it was slower, but i contribute that to the overall
unoptimized IO of the system (i may be wrong)...

compile time was hands down a p9 win...

andrey

ps: it is possible to set-up a p9/linux shootout here, but i'm not
sure whether we may do so :)


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

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GUI toolkit for Plan 9
Date: Mon, 25 Feb 2002 09:39:17 -0500
Message-ID: <71f9dbfbfc8fadc420ee2b20663fb731@plan9.bell-labs.com>

By the way, if someone out there has Linux and Plan 9 running on the
same hardware, I would be genuinely interested in seeing an good
comparison of run-time and code quality.  Thanks.  I didn't define
'dramatically' in my last message because a) there were two different
machines involved and b) the header files involved were quite
different.  (But it was _dramatic_, and the Plan 9 machine is much
slower.)

-rob

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

Also, Plan 9's compilers are known to be weak in floating point, so
make sure you include tests that both include and exclude FP.

-rob

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> Also, Plan 9's compilers are known to be weak in floating point, so
> make sure you include tests that both include and exclude FP.

I think everyone can agree that for systems programming, floating
point is not a very important benchmark, though it is exceedingly
important for many users.

However, one way of implementing zooming user interfaces is very
floating point dependent, so it is perhaps becoming more important
than it used to be.  (My preferred implementation is with exact
rationals, however, so it doesn't really matter to me.)

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

By the way, if someone out there has Linux and Plan 9 running on the
same hardware, I would be genuinely interested in seeing an good
comparison of run-time and code quality.  Thanks.  I didn't define
'dramatically' in my last message because a) there were two different
machines involved and b) the header files involved were quite
different.  (But it was _dramatic_, and the Plan 9 machine is much
slower.)

-rob

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> By the way, if someone out there has Linux and Plan 9 running on the
> same hardware, I would be genuinely interested in seeing an good
> comparison of run-time and code quality.  Thanks.  I didn't define
> 'dramatically' in my last message because a) there were two different
> machines involved and b) the header files involved were quite
> different.  (But it was _dramatic_, and the Plan 9 machine is much
> slower.)

I once did some instrumentation of GCC run times when -O was not being
used, and a *vast* amount of time was being spent processing includes
in the C preprocessor.  (Hence my assertion that optimizing the rest
of the system would do a lot more to speed up compilation than using a
toy compiler would.)

That was on an HP-300 running BSD; I don't know any such information
for more modern computers.

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

> I thought he meant the way it vastly outperformed puny little toy
> compilers like the one in Plan 9.

I've heard this before.  People talk about GCC as though it's fast and
generates particularly efficient code.  Neither of these appears to be
true, at least as of a couple of years ago.  I was teaching a course
and, requiring ANSI C, made the students use the commercial SUN C
compiler instead of GCC. (GCC isn't strict or accurate about ANSI no
matter how many flags you turn on.)  I heard a lot of complaints from
the students that GCC was better so we did a shootout.  The SUN
compiler ran several times faster and the code it produced ran about
10%-40% faster on a variety of benchmarks.  This, of course, was on
the SPARC.

Much longer ago, we did a similar shootout with Plan 9's compiler
against GCC on the MIPS, with similar results, but I hear GCC has
improved somewhat on that architecture.

I just did a sloppy compile-time test of Plan 9's 8c against GCC on a
386 and see that 8c runs dramatically faster.  I don't dispute that
GCC could be generating better code, however; I didn't test that and
8c isn't particularly good.  For me, though, compile time matters more
than quality of code, as long as the code is reasonable.

In summary, GCC is reliable, may generate good code (although there's
evidence it's not stellar), but is slow to compile.  Please define
'outperform'.  I won't dispute 'puny' for the Plan 9 compiler,
although I think 'toy' is unwarranted.

-rob

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> > I thought he meant the way it vastly outperformed puny little toy
> > compilers like the one in Plan 9.
> 
> I've heard this before.  People talk about GCC as though it's fast and
> generates particularly efficient code.  

I've never heard anyone claim that GCC is particularly fast; that's
not a design goal.  

> Neither of these appears to be true, at least as of a couple of
> years ago.  I was teaching a course and, requiring ANSI C, made the
> students use the commercial SUN C compiler instead of GCC. (GCC
> isn't strict or accurate about ANSI no matter how many flags you
> turn on.)  I heard a lot of complaints from the students that GCC
> was better so we did a shootout.  The SUN compiler ran several times
> faster and the code it produced ran about 10%-40% faster on a
> variety of benchmarks.  This, of course, was on the SPARC.

Many years ago, GCC was better (that is, produced more efficient code)
than all available commercial compilers but two; one was the Sun Sparc
compiler, and the other was the MIPS compiler.  The MIPS compiler was
doing inter-function optimizations that GCC is not yet really capable
of.  The Sparc compiler, it happens, had special magic detectors for
certain standard benchmarks, and if you were compiling one of those,
it would spit out pre-made assembly code (it was obvious; the
*formatting* of the code indicated it was not being produced by the
normal codegen of the compiler).  If you tweak the benchmarks
slightly, the Sparc compiler was no longer very much better, though it
still beat by a couple percent.

I believe the MIPS compiler is still superior, but not the Sun Sparc
compiler.  

> Much longer ago, we did a similar shootout with Plan 9's compiler
> against GCC on the MIPS, with similar results, but I hear GCC has
> improved somewhat on that architecture.

Of course, my comment was about toy compilers like the Plan 9 one.
Saying "GCC isn't as good as the Sparc compiler" doesn't mean that the
Plan 9 compiler is anything but a cute toy.

> I just did a sloppy compile-time test of Plan 9's 8c against GCC on a
> 386 and see that 8c runs dramatically faster.  I don't dispute that
> GCC could be generating better code, however; I didn't test that and
> 8c isn't particularly good.  For me, though, compile time matters more
> than quality of code, as long as the code is reasonable.

Really?  Having an optimizing compiler would make *everything* on the
system run faster.  I would bet you that 

"Running 8c on an unoptimized system" is *slower* than "Running GCC
without -O on an optimized system".

Thomas

Re: [9fans] GUI toolkit for Plan 9

[Dan Cross]

Please don't feed the troll....

	- Dan C.

Re: [9fans] GUI toolkit for Plan 9

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> I believe the MIPS compiler is still superior, ...

The story I heard is that it had _twenty five thousand lines_ of code
to do instruction re-ordering [to fill delay slots etc].

What a waste.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

boyd@strakt.com (Boyd Roberts) writes:

> "Thomas Bushnell, BSG" wrote:
> > I believe the MIPS compiler is still superior, ...
> 
> The story I heard is that it had _twenty five thousand lines_ of code
> to do instruction re-ordering [to fill delay slots etc].
> 
> What a waste.

Yes, but actually really quite good at compiling!  

Speed is really important, of course, but it's usually thought that
this is the reason why we want optimizing compilers.  

Re: [9fans] GUI toolkit for Plan 9

[Douglas A. Gwyn]

Boyd Roberts wrote:
> The story I heard is that it had _twenty five thousand lines_ of code
> to do instruction re-ordering [to fill delay slots etc].

Somehow I doubt 25,000 lines, unless most of it was comments
documenting the architecture and algorithm thoroughly.
However, it is certainly true that many of the architectural
features being used on today's processors to speed things up
are hard to exploit efficiently in a code generator, yet not
exploiting them would pretty much defeat their purpose..

Re: [9fans] GUI toolkit for Plan 9

[okamoto]

>1) I am wondering if anyone is developing,
>   or planning, a GUI toolkit for Plan 9?

As Charles pointed out, we have control(2) for that where we are working
for our application.   According to my understanding, we need some more
exercise how we can implement GUI programs for Plan 9.   Plan 9 has different
strategy from those of X applications.  Plan 9 uses concurrent programming
and threads(coroutines) for it.   We are now just trying to use its single threaded 
application, which means we have only four processes for an application, and 
one of which consists of many kinds of threads (= coroutines).   So far as our 
program, we have no problem in this strategy.   However, some much larger 
program may require multi-threaded strategy, which is the point I described 
above.
(for out program, I believe we can make it public in March, we need some
more debugging now, and Yoshitatsu has to write thesis. ^_^)

Kenji

Re: [9fans] GUI toolkit for Plan 9

[rob pike]

> I've been playing with GCC 3.0
> on Linux, and I'm pretty impressed.

What did you find impressive?

-rob

Re: [9fans] GUI toolkit for Plan 9

[plan9]

On Fri, Feb 22, 2002 at 08:29:48AM -0500, rob pike wrote:
> > I've been playing with GCC 3.0
> > on Linux, and I'm pretty impressed.
> 
> What did you find impressive?

The way the lights in my house dimmed when compiling hello_world.c.

Re: [9fans] GUI toolkit for Plan 9

[Thomas Bushnell, BSG]

plan9@sigint.cs.purdue.edu writes:

> On Fri, Feb 22, 2002 at 08:29:48AM -0500, rob pike wrote:
> > > I've been playing with GCC 3.0
> > > on Linux, and I'm pretty impressed.
> > 
> > What did you find impressive?
> 
> The way the lights in my house dimmed when compiling hello_world.c.

I thought he meant the way it vastly outperformed puny little toy
compilers like the one in Plan 9.

Re: [9fans] GUI toolkit for Plan 9

[Dan Cross]

> > I've been playing with GCC 3.0
> > on Linux, and I'm pretty impressed.
> 
> What did you find impressive?

The sheer '57 Cadillac-like size, baby, and the fact that the source
code is actually a stegenographic rendering of a picture of 27 flying
Elvis's parachuting onto the strip.

	- Dan ``Vegas, Baby!  Vegas!'' C.

Re: [9fans] GUI toolkit for Plan 9

[forsyth]

>>   instead. I've been playing with GCC 3.0
>>    on Linux, and I'm pretty impressed. Is
>>    anyone working on getting GNU binutils
>>    and so GCC to generate Plan 9 objects?
>>    That would be a great first step in
>>    getting all that `other code' working.

if the `other code' is at all portable, it's usually not too hard.
as it is, i mean.

Re: [9fans] GUI toolkit for Plan 9

[forsyth]

>>1) I am wondering if anyone is developing,
>>   or planning, a GUI toolkit for Plan 9?
>>   If not, does anyone have any good design
>>   ideas, especially centring around Plan 9
>>   features? Are there any good papers on
>>   this topic?

man 2 control

Re: [9fans] GUI toolkit for Plan 9

[phaet0n]

forsyth@caldo.demon.co.uk wrote:
> >>1) I am wondering if anyone is developing,
> >>   or planning, a GUI toolkit for Plan 9?
>
> man 2 control

Apologies. Could someone put this in the FAQ.
My hardcopy docs are from the initial open
release and don't have man pages for control.

rob@plan9.bell-labs.com (rob pike) wrote:
> > I've been playing with GCC 3.0
> > on Linux, and I'm pretty impressed.
> 
> What did you find impressive?

Just reflecting on the sheer amount of software
that depends on GCC `working'. Toughts of 
targeting it's back-end don't scare me as much
as with the 2.x series. Not that the interface
has changed much, but it's more organized.

One question answered, two to go. This might
be my lucky week...
--

[9fans] GUI toolkit for Plan 9

[phaet0n]

Hello all,

I have a few questions.

1) I am wondering if anyone is developing,
   or planning, a GUI toolkit for Plan 9?
   If not, does anyone have any good design
   ideas, especially centring around Plan 9
   features? Are there any good papers on
   this topic?

2) Someone mentioned freetype a while back.
   Is there any progress on this front? It
   would be really nice if a freetype server
   could publish Plan 9 font bitmaps from
   TrueType or Type 1 font files. Not that
   there's anything wrong with lucida...

3) I asked a while back, and got no reply,
   about Plan 9's object format for a project.
   I presume read the source applied. That
   project fizzled, so I'm generating C
   instead. I've been playing with GCC 3.0
   on Linux, and I'm pretty impressed. Is
   anyone working on getting GNU binutils
   and so GCC to generate Plan 9 objects?
   That would be a great first step in
   getting all that `other code' working.

Awaiting discussion...
--