[9fans] Good enough approximation for ape/pcc

[9fans] Good enough approximation for ape/pcc

[Fernan Bolando]

is this a good enough approximation of the pcc compiler in plan 9?

gcc -ansi -pedantic -std=c89

this is just to assist me in porting some stuff into my plan9 box

,Fernan

--
Public PGP/GnuPG key (http://www.fernski.com)
pub 1024D/3576CA71 2006-02-02 Fernan Bolando
Key fingerprint = FDFE C9A8 FFED C1A5 2F5C EFEB D595 AF1C 3576 CA71

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> this is just to assist me in porting some stuff into my plan9 box

Just use pcc directly.  All the relevant differences are in
#include files, not compiler flags.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Fernan Bolando]

On 4/8/06, Russ Cox <rsc@swtch.com> wrote:
> > this is just to assist me in porting some stuff into my plan9 box
>
> Just use pcc directly.  All the relevant differences are in
> #include files, not compiler flags.
>

did you mean use gcc directly?
I am not sure If I understood you correctly but to clarify my original question.

Sometimes when I dont have access to my plan 9 system and my only computer
is a linux box I want to check if a piece pf code will compile under ape.

is there a way to use gcc so that it will behave more like the ape tools?


--
Public PGP/GnuPG key (http://www.fernski.com)
pub 1024D/3576CA71 2006-02-02 Fernan Bolando
Key fingerprint = FDFE C9A8 FFED C1A5 2F5C EFEB D595 AF1C 3576 CA71

Re: [9fans] Good enough approximation for ape/pcc

[uriel]

Writing code that will compile with ?c is just matter good style, ie.,
not (ab)using cpp, not using gcc extensions and so on; see
/sys/doc/comp.ps for details. Ape doesn't not even come into the
picture, no sane C code should ever need to use cpp(1)

Figuring out if the builtin preprocessor will handle your code should
be obvious, but if you really want to test, you could use the port of
the compilers that is part of Inferno.

And if you have the disgrace of having to write software under lunix,
I would recommend using the p9p libs and doing native ports
to Plan 9. Or just use Limbo and Inferno and be happy.

Ape is an unfortunate historical aberration, lets leave it at that and
not write new code that depends on it.

uriel

> On 4/8/06, Russ Cox <rsc@swtch.com> wrote:
>> > this is just to assist me in porting some stuff into my plan9 box
>>
>> Just use pcc directly.  All the relevant differences are in
>> #include files, not compiler flags.
>>
>
> did you mean use gcc directly?
> I am not sure If I understood you correctly but to clarify my original question.
>
> Sometimes when I dont have access to my plan 9 system and my only computer
> is a linux box I want to check if a piece pf code will compile under ape.
>
> is there a way to use gcc so that it will behave more like the ape tools?
>
>
> --
> Public PGP/GnuPG key (http://www.fernski.com)
> pub 1024D/3576CA71 2006-02-02 Fernan Bolando
> Key fingerprint = FDFE C9A8 FFED C1A5 2F5C EFEB D595 AF1C 3576 CA71

Re: [9fans] Good enough approximation for ape/pcc

[David Leimbach]

On 4/7/06, uriel@cat-v.org <uriel@cat-v.org> wrote:
> Writing code that will compile with ?c is just matter good style, ie.,
> not (ab)using cpp, not using gcc extensions and so on; see
> /sys/doc/comp.ps for details. Ape doesn't not even come into the
> picture, no sane C code should ever need to use cpp(1)
>

Does pcc do C99?  Anyone know how much or how little?

Dave

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> Does pcc do C99?  Anyone know how much or how little?

See /sys/src/cmd/cc/c99.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[David Leimbach]

On 4/7/06, Russ Cox <rsc@swtch.com> wrote:
> > Does pcc do C99?  Anyone know how much or how little?
>
> See /sys/src/cmd/cc/c99.
>
> Russ
>
>
Awesome thanks!

Re: [9fans] Good enough approximation for ape/pcc

[Lluís Batlle i Rossell]

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

Russ Cox wrote:
>>Does pcc do C99?  Anyone know how much or how little?
>
>
> See /sys/src/cmd/cc/c99.
I'm courious, why has been __func__ declared unwanted?

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3311 bytes --]

Re: [9fans] Good enough approximation for ape/pcc

[quanstro]

__func__ looks like preprocessor magic, but must actually be implemented
as a magic variable in the compiler.  imho, i think the standards committee
missed that one.  it's pretty ugly.

is there a good argument for having __func__?  it's not generally in the 
plan 9 style to put stuff like that in code.  

i suppose you're expected to know how to read kmesg output and sic acid 
after the offender.  ☺

- erik

On Sat Apr  8 17:41:43 CDT 2006, viriketo@gmail.com wrote:

> Russ Cox wrote:
> >>Does pcc do C99?  Anyone know how much or how little?
> > 
> > 
> > See /sys/src/cmd/cc/c99.
> I'm courious, why has been __func__ declared unwanted?
> 

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> i suppose you're expected to know how to read kmesg output and sic acid 
> after the offender.  ☺

you're supposed to be able to run stk() in acid.
i have yet to see a compelling use for __func__.
formatting an assert message doesn't count,
since assert will leave you a broken process to
debug.

russ

Re: [9fans] Good enough approximation for ape/pcc

[Scott Schwartz]

| formatting an assert message doesn't count,
| since assert will leave you a broken process to

What about when formatting a message that you want to return or print,
but not kill the process?

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> What about when formatting a message that you want to return or print,
> but not kill the process?

it's easy to make up examples, but
i've never seen this in practice.
if you're writing the print statement,
you *know* which function you're in.
it's only useful inside macros,
which are mostly deprecated.

it would often be useful to be able to
format a given pc as a function name
for use in prints about your caller,
but that's a whole different can of worms.

russ

Re: [9fans] Good enough approximation for ape/pcc

[Scott Schwartz]

| if you're writing the print statement,
| you *know* which function you're in.

But why should I have to type the particular value several times?
What if I change the name of the function later?  Isn't that what
variables are for?

| it's only useful inside macros,
| which are mostly deprecated.

Nah, even simple function calls can use it.

   check(a, b, c, __func__);

It's true, it would be nice to find out the caller from within check(),
but this achieves most of the utility with a much simpler implementation.

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> But why should I have to type the particular value several times?
> What if I change the name of the function later?  Isn't that what
> variables are for?

Not variables named __func__.  That's just disgusting.  Sorry.

> Nah, even simple function calls can use it.
>
>    check(a, b, c, __func__);
>
> It's true, it would be nice to find out the caller from within check(),
> but this achieves most of the utility with a much simpler implementation.

The Plan 9 C libraries already provided a mechanism
for finding the caller - getcallerpc(2).  And almost all
the times I want to print the caller it's while debugging
some commonly called library routine, where it's impractical
to change all the call sites.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Scott Schwartz]

| The Plan 9 C libraries already provided a mechanism
| for finding the caller - getcallerpc(2).

What happens when there is no caller because the function got inlined?
Obviously with compiler support you could get the right effect, but
wouldn't it be a bit more work?

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> | The Plan 9 C libraries already provided a mechanism
> | for finding the caller - getcallerpc(2).
>
> What happens when there is no caller because the function got inlined?

Doesn't happen.  One of the many nice things about the Plan 9 compilers.

In fact, I just added two instructions to an assembly routine in
libmp *only* so that stack traces would work when starting in that
routine.  I probably slowed it down by some miniscule fraction of
a percent, and I certainly made the code a few bytes bigger.  A lose/lose,
except that now the code is more debuggable, and that's the ultimate win.

> Obviously with compiler support you could get the right effect, but
> wouldn't it be a bit more work?

Dealing with all this crap while working on plan9port has soured me
even more on the current state of mainstream programming.
I learned to program using 16-bit DOS compilers.  And they were better!
I could rant about this and tell war stories for hours.  The short
version is this.

Gcc does all these kinds of optimizations and more.  I can't imagine
what they're optimizing for.

    gcc-developer time?  many hours went into writing that code.
    compile time?  gcc is certainly getting slower
    correctness?  the code may be correct but the debugging output
       (stack traces from gdb) gets less and less reliable
    my time?  i've lost hours upon hours because of the increase
       in compile time and the unreliability of the debugging environment
    generated code speed?  it's not cpu intensive in the first place,
       or i would have said -O99 or something like that

So let's see.  For negligible benefit that I indicated wasn't worth
the effort via a compiler flag, they've wasted hours of their
own time and hours of my time.  Sounds like a bad deal to me.

In a gcc world, I'm sure __func__ and its ilk make tons of sense.
I want no part of such a world.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[lucio]

> Gcc does all these kinds of optimizations and more.  I can't imagine
> what they're optimizing for.
>
>     gcc-developer time?  many hours went into writing that code.

On the contrary, they are protecting their "job" just like any other
employee, by making themselves indispensable.  I don't think it's
necessary or a conscious decision on their part, but it's that aspect
of human nature that eventually defeats any attempt at benevolent
social engineering.  Call it "the tragedy of the commons", if you need
a label.

++L

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

distrust anthing with more than one underscore.

i've seen  ...

#define iniline __inline__

more than once, and don't care what it means.
the ps2 linux port is crazy.  trying to align things.

brucee

On 4/10/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > Gcc does all these kinds of optimizations and more.  I can't imagine
> > what they're optimizing for.
> >
> >     gcc-developer time?  many hours went into writing that code.
>
> On the contrary, they are protecting their "job" just like any other
> employee, by making themselves indispensable.  I don't think it's
> necessary or a conscious decision on their part, but it's that aspect
> of human nature that eventually defeats any attempt at benevolent
> social engineering.  Call it "the tragedy of the commons", if you need
> a label.
>
> ++L
>
>

Re: [9fans] Good enough approximation for ape/pcc

[Paul Lalonde]

[-- Attachment #1.1: Type: text/plain, Size: 1914 bytes --]

You should see the bare machine then... Sony's GCC is even more hooped.

And the PS3 version is no better, with huge dependence on "restrict"
for any sort of performance, especially on SPU.  And don't  It's made
me go back to coding assembly instead.  And its structure packing so
interferes with good data layout I want to cry.

(Shameless plug follows)

That said, Neoptica (www.neoptica.com - the startup I'm involved
(committed?) with) is looking for a world-class systems/compilers
person to join our team; we're working on novel approaches to exploit
multi-core architectures, GPUs, and fast bi-directional busses to
improve the visuals in next-games.  The systems job add isn't posted
yet, but should be soon - for the flavour through, think Brook
(http://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf), Sequoia
(http://graphics.stanford.edu/~kayvonf/papers/sequoia_draft.pdf), and
EAGL (http://www.cs.brown.edu/~tor/sig2002/ea-shader.pdf)


Paul

On 10-Apr-06, at 1:37 AM, Bruce Ellis wrote:

> distrust anthing with more than one underscore.
>
> i've seen  ...
>
> #define iniline __inline__
>
> more than once, and don't care what it means.
> the ps2 linux port is crazy.  trying to align things.
>
> brucee
>
> On 4/10/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
>>> Gcc does all these kinds of optimizations and more.  I can't imagine
>>> what they're optimizing for.
>>>
>>>     gcc-developer time?  many hours went into writing that code.
>>
>> On the contrary, they are protecting their "job" just like any other
>> employee, by making themselves indispensable.  I don't think it's
>> necessary or a conscious decision on their part, but it's that aspect
>> of human nature that eventually defeats any attempt at benevolent
>> social engineering.  Call it "the tragedy of the commons", if you
>> need
>> a label.
>>
>> ++L
>>
>>


[-- Attachment #1.2: Type: text/html, Size: 6169 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 193 bytes --]

Re: [9fans] Good enough approximation for ape/pcc

[quanstro]

i don't think that's it.

i think the gcc folks have different goals.  they seem very interested in
lots of very sophisticated optimizations and support for every odd corner case.
(of course odd corner cases are exponential in sophisticated optimizations.)

i think their lack of success is indicitive that the problem they're solving is hard,
and they don't quite understand why it is so hard.

- erik

p.s. linux is doing the same thing. they've added 22 (by my count) system
calls this year alone.  all are performace hacks or corner-case jobs.

On Sun Apr  9 23:24:33 CDT 2006, lucio@proxima.alt.za wrote:
> > Gcc does all these kinds of optimizations and more.  I can't imagine
> > what they're optimizing for.
> >
> >     gcc-developer time?  many hours went into writing that code.
>
> On the contrary, they are protecting their "job" just like any other
> employee, by making themselves indispensable.  I don't think it's
> necessary or a conscious decision on their part, but it's that aspect
> of human nature that eventually defeats any attempt at benevolent
> social engineering.  Call it "the tragedy of the commons", if you need
> a label.
>
> ++L
>

Re: [9fans] Good enough approximation for ape/pcc

[Brantley Coile]

> i think the gcc folks have different goals.  they seem very interested in
> lots of very sophisticated optimizations and support for every odd corner case.

Or they might just like writing stuff for the compiler, personal
entertainment.  Or they like seeing their names on gcc.gnu.org
projects pages.  Or they really think that all this work makes some
difference.  I don't know anyone who works on the beast, so I've no
real clue as to why people continue to spend time on this monster.
Let's just move Ken's C compiler everywhere.

Re: [9fans] Good enough approximation for ape/pcc

[Ronald G Minnich]

Brantley Coile wrote:

> Or they might just like writing stuff for the compiler, personal
> entertainment.

bingo.

I know one or two of the guys, or used to. It was all about optimize,
measure, optimize some more. The big picture got lost.

It's humorous to see the inline madness, on machines with 512KB caches yet:
[rminnich@q linux-2.6.16]$ grep -r -i 'static inline' . |wc
   21262  142677 1810997

yep, 21262 instances of 'static inline'. Even better:

[rminnich@q linux-2.6.16]$ grep -r -i 'static inline' include/ | wc
    8249   54789  689506

so, like, 13K of them are NOT in .h. Which is worse, the fact that the
code is replicated all over the place, via .h, or there are .c files
with static inline in them? yikes.

I was talking to the afterburner guys some months ago.

them. "How many inb are there in Plan 9?"
me. "Oh, one, maybe two"
them. "What about the inline and asm stuff?"
me. "The, uh, what? Oh yeah, people used to do that stuff in the 70s and
... oh .. the 21st century too ... hmmm ... they like to bang their head
between two blocks I guess."

There's lots of other bad stuff that happened too. Linker-sets, for
example. Or, oh, the stuff like:
if (likely(a != b)) {eatme();}

The world went mad.

ron

Re: [9fans] Good enough approximation for ape/pcc

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 10-Apr-06, at 7:09 AM, Ronald G Minnich wrote:
>
> There's lots of other bad stuff that happened too. Linker-sets, for
> example. Or, oh, the stuff like:
> if (likely(a != b)) {eatme();}

Although I'm willing to claim that branch prediction hints do belong
somewhere, although probably in only in assembly.
One processor I'm dealing with has something like a 19 cycle branch
miss penalty, on a machine where it's memory is only 7 cycles away,
and with 4-way SIMD-in-a-word stuff.  You can put your entire loop
into those 19 cycles, and the compiler had better get the (explicit,
coded, not predicted) branch hint right.   I have a piece of TLB-like
code that likewise needs the common case to be detected for "free"
for efficiency (12 cycle lookup for a hit, >2000 for a miss), and the
compiler does get it wrong, there being no loop involved.
Yuck.

What's the right high-level way to deal with branch prediction?  I'm
guessing there isn't one...

Worst quote from Sony: "Think in assembler, but code in C++"

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEOnB1pJeHo/Fbu1wRAs8nAJ0W/5NJTZa5mWz3FLT33JcF2l8UWgCgvEv3
ILl+kIjLRWTJlsnBlMM/3Ig=
=yMJR
-----END PGP SIGNATURE-----

Re: [9fans] Good enough approximation for ape/pcc

[andrey mirtchovski]

> One processor I'm dealing with has something like a 19 cycle branch
> miss penalty, on a machine where it's memory is only 7 cycles away,
...[snip]...
> Worst quote from Sony: "Think in assembler, but code in C++"


that's an interesting processor you're describing there :)

Re: [9fans] Good enough approximation for ape/pcc

[Andrew Simmons]

>Or they might just like writing stuff for the compiler, personal
>entertainment.

I was recently told about the following compiler option. I honestly thought
it was an April Fool's joke:

-Weffc++
This option warns about C++ code which breaks some of the programming
guidelines given in the books "Effective C++" and "More Effective C++" by
Scott Meyers. For example, a warning will be given if a class which uses
dynamically allocated memory does not define a copy constructor and an
assignment operator. Note that the standard library header files do not
follow these guidelines, so you may wish to use this option as an
occasional test for possible problems in your own code rather than
compiling with it all the time.

Re: [9fans] Good enough approximation for ape/pcc

[Andy Newman]

On Tue, 2006-04-11 at 10:07 +1200, Andrew Simmons wrote:
> I was recently told about the following compiler option. I honestly thought
> it was an April Fool's joke:
>
> -Weffc++

The "joke" is more that to use the language safely/correctly pretty much
requires such an option.   There is a mini-industry of "don't do that"
books as the g++ switch shows. Having now done a lot of C++ I find it
quite unbelievable what people will put up with and claim to be good
(but hey they pay me for it).  Although C++ does provide a few niceties
it creates a whole slew of problems of its own which need to be fixed
with all manner of convoluted constructs and practices. Don't get me
started on the library, they're only now figuring out that it mostly
sucks.

Re: [9fans] Good enough approximation for ape/pcc

[David Leimbach]

On 4/10/06, Andy Newman <andy@silverbrookresearch.com> wrote:
> On Tue, 2006-04-11 at 10:07 +1200, Andrew Simmons wrote:
> > I was recently told about the following compiler option. I honestly thought
> > it was an April Fool's joke:
> >
> > -Weffc++
>
> The "joke" is more that to use the language safely/correctly pretty much
> requires such an option.   There is a mini-industry of "don't do that"
> books as the g++ switch shows. Having now done a lot of C++ I find it
> quite unbelievable what people will put up with and claim to be good
> (but hey they pay me for it).  Although C++ does provide a few niceties
> it creates a whole slew of problems of its own which need to be fixed
> with all manner of convoluted constructs and practices. Don't get me
> started on the library, they're only now figuring out that it mostly
> sucks.
>
>
>
Here here!  And this is from a guy who used to think that C++ was
pretty much it.  I learned it early on (right after QBASIC on DOS, and
before I learned C believe it or not...).  Concurrency,
exception-safety, clearness of error messages, networking, memory
management.  I don't think *any* of these problems have been
adequately handled in C++ in a way that doesn't require you to think
of the possible side-effects and consequences of any lines of code you
may write.

It's really pretty scary to think how much C++ is probably out there,
and written in a hurry.  It's possible to write good C++ code, just
not likely to fall into it by accident.

One would think that even middle managers could just look at the
volumes of books on the subject of being careful about C++ and realize
that if there is an industry around writing high quality code in just
one language, that maybe that's not the best tool to use in all cases.

Interesting example...

SomeContainer::iterator it = SomeContainerObject.begin();

for (; it != SomeContainerObject.end(); ++it)

is probably a lot faster than

for(; it != SomeConatinerObject.end(); it++)

And I'd bet that not much more than half of the so-called C++
programmers out there in the world know why this is.

Dave

Re: [9fans] Good enough approximation for ape/pcc

[Roman Shaposhnick]

On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote:
> Interesting example...
>
> SomeContainer::iterator it = SomeContainerObject.begin();
>
> for (; it != SomeContainerObject.end(); ++it)
>
> is probably a lot faster than
>
> for(; it != SomeConatinerObject.end(); it++)
>
> And I'd bet that not much more than half of the so-called C++
> programmers out there in the world know why this is.

  If the punch line here is, in fact, what I think it is, then
  a good optimizing compiler should be able to make these two
  pretty close in terms of performance.

  I've been doing optimizing compilers at Sun for quite some time
  now (C/C++ and Fortran) and one thing that I constantly talk
  to our customers about is that in todays world of opaque CPU
  design they actually don't know whether 'a = a + 1;' is slower
  or faster than 'a++;'. So the best advice I can give them
  is to:

     1. Express semantics, not how to generate code
     2. Pick a compiler vendor you can trust.
     3. Make Performance Analysis part of your debugging.


Thanks,
Roman.

Re: [9fans] Good enough approximation for ape/pcc

[David Leimbach]

On 4/10/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote:
> > Interesting example...
> >
> > SomeContainer::iterator it = SomeContainerObject.begin();
> >
> > for (; it != SomeContainerObject.end(); ++it)
> >
> > is probably a lot faster than
> >
> > for(; it != SomeConatinerObject.end(); it++)
> >
> > And I'd bet that not much more than half of the so-called C++
> > programmers out there in the world know why this is.
>
>   If the punch line here is, in fact, what I think it is, then
>   a good optimizing compiler should be able to make these two
>   pretty close in terms of performance.

Perhaps... but only if the iterator is a real pointer.  If the
iterator itself is an object the compiler can't be smart enough to
know all the side effects of the overloaded ++(int) (yes that's how
you overload postfix ++ in C++, even though there is no integer
argument).  In fact, unless the compiler understands that the
overloaded postfix ++ has the same semantics as postfix ++ on a
regular C-style datatype (like int, char etc), there's no way I want
my compiler to optimize anything :-).

So if I wrote my own datatype and implemented the same semantics that
you'd expect for postfix ++ you'd likely find the following
pseudocode:

copy the iterator;
increment *this;
return the copy.

Do you really want to do that at the end of every loop iteration?  And
what if I add some other logic between increment *this and return the
copy, like some mutex locking/unlocking or whatever... the compiler is
helpless to help my code here, and I throw out a copy in every loop.

>
>   I've been doing optimizing compilers at Sun for quite some time
>   now (C/C++ and Fortran) and one thing that I constantly talk
>   to our customers about is that in todays world of opaque CPU
>   design they actually don't know whether 'a = a + 1;' is slower
>   or faster than 'a++;'. So the best advice I can give them
>   is to:
>
>      1. Express semantics, not how to generate code
>      2. Pick a compiler vendor you can trust.
>      3. Make Performance Analysis part of your debugging.

With C++ you need to understand the side effects of the language.  You
could add profiling and logging to your copy constructor for that
iterator above, but you might not understand why you're making so many
copies, throwing them away and having to run both a constructor and a
destructor at the bottom of the loop.

C hasn't inflcited anything like this on it's user base that I've
seen.  There's apparently very good money in knowing these little
esoteric bits about C++ though :).

Dave

>
>
> Thanks,
> Roman.
>

Re: [9fans] Good enough approximation for ape/pcc

[Andrew Simmons]

>There's apparently very good money in knowing these little
>esoteric bits about C++ though :).

For a depressingly typical example the following site is enlightening:
http://www.gotw.ca/gotw/

The good news is that things are going to get a whole lot more complicated,
because, obviously, the way to make C++ easier to use is to add more features:
http://www.artima.com/cppsource/cpp0xP.html

Are there any plans to add a -Wtpop switch to the Plan 9 compilers?

Re: [9fans] Good enough approximation for ape/pcc

[quanstro]

the c++0x page kills me.  their trick is as old and specialized as 

	A = πr⁲

sure their example looks slick, but there's a lot of sophistication lurking
in that simple-looking factor, π, or in their case, auto.  and it would be too trivial
to find another example that wouldn't look so simple.

- erik

On Mon Apr 10 20:31:36 CDT 2006, andrew.simmons@monitorbm.co.nz wrote:
> 
> >There's apparently very good money in knowing these little
> >esoteric bits about C++ though :).
> 
> For a depressingly typical example the following site is enlightening:
> http://www.gotw.ca/gotw/
> 
> The good news is that things are going to get a whole lot more complicated, 
> because, obviously, the way to make C++ easier to use is to add more features:
> http://www.artima.com/cppsource/cpp0xP.html
> 
> Are there any plans to add a -Wtpop switch to the Plan 9 compilers?
> 

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

limbo's ":=" works like that ...

i := 0;    # declares i as in an int and assigns 0 to it
r := ref Boo;    # declares r to be scarey

brucee

On 4/11/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> the c++0x page kills me.  their trick is as old and specialized as
>
>        A = πr⁲
>
> sure their example looks slick, but there's a lot of sophistication lurking
> in that simple-looking factor, π, or in their case, auto.  and it would be too trivial
> to find another example that wouldn't look so simple.
>
> - erik
>
> On Mon Apr 10 20:31:36 CDT 2006, andrew.simmons@monitorbm.co.nz wrote:
> >
> > >There's apparently very good money in knowing these little
> > >esoteric bits about C++ though :).
> >
> > For a depressingly typical example the following site is enlightening:
> > http://www.gotw.ca/gotw/
> >
> > The good news is that things are going to get a whole lot more complicated,
> > because, obviously, the way to make C++ easier to use is to add more features:
> > http://www.artima.com/cppsource/cpp0xP.html
> >
> > Are there any plans to add a -Wtpop switch to the Plan 9 compilers?
> >
>

Re: [9fans] Good enough approximation for ape/pcc

[Skip Tavakkolian]

> limbo's ":=" works like that ...

when i first looked at limbo, it took me a while to realize what a neat concept
this is.  also, has a nice consistent syntax in relation to ':' and '='

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

rob had a aimple example of some java that ":=" could help.

brucee

On 4/11/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> > limbo's ":=" works like that ...
>
> when i first looked at limbo, it took me a while to realize what a neat concept
> this is.  also, has a nice consistent syntax in relation to ':' and '='

Re: [9fans] Good enough approximation for ape/pcc

[Charles Forsyth]

> rob had a aimple example of some java that ":=" could help.

i think almost any example would do: i started off writing Java using the
	Typename variable = expression;
	...
style but java declarations are cluttered, and it becomes so hard
to see the part that does the work, that i reverted to C's style of
declaring all variables at the top of the block.   it's still hard to
see class-level functions and variables beyond all the annotations.
syntax colouring produces visual results that sadly i find all too similar to
those ``credits completed in an entirely different style at great
expense and at the last minute''; and thus i still can't read the code properly.

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

i weep for you.

brucee

On 4/11/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > rob had a aimple example of some java that ":=" could help.
>
> i think almost any example would do: i started off writing Java using the
>        Typename variable = expression;
>        ...
> style but java declarations are cluttered, and it becomes so hard
> to see the part that does the work, that i reverted to C's style of
> declaring all variables at the top of the block.   it's still hard to
> see class-level functions and variables beyond all the annotations.
> syntax colouring produces visual results that sadly i find all too similar to
> those ``credits completed in an entirely different style at great
> expense and at the last minute''; and thus i still can't read the code properly.
>
>

Re: [9fans] Good enough approximation for ape/pcc

[Lluís Batlle]

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

2006/4/11, Andrew Simmons <andrew.simmons@monitorbm.co.nz>:

> The good news is that things are going to get a whole lot more
> complicated,
> because, obviously, the way to make C++ easier to use is to add more
> features:
> http://www.artima.com/cppsource/cpp0xP.html


IMO There's a way too changed "auto" keyword (from C sense).

[-- Attachment #2: Type: text/html, Size: 675 bytes --]

Re: [9fans] Good enough approximation for ape/pcc

[Roman Shaposhnick]

On Tue, Apr 11, 2006 at 01:26:49PM +1200, Andrew Simmons wrote:
> The good news is that things are going to get a whole lot more complicated,
> because, obviously, the way to make C++ easier to use is to add more
> features:

  A colleague of mine, who is a chair of ANSI C++ Committee, told me once
  that the most bizarre feature requests come from the committee members
  who happen to be independent C++ consultants. Industry representatives
  usually just shake their heads in disbelief.

Thanks,
Roman.

P.S. Now, if I were an independent C++ consultant, I wouldn't push too hard,
after all -- even they should remember what happened to the Tower of Babel.

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> P.S. Now, if I were an independent C++ consultant, I wouldn't push too hard,
> after all -- even they should remember what happened to the Tower of Babel.

The people at Babel had one really good language that
everyone understood, and they were highly productive.
This reminds you of C++ programmers?

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Roman Shaposhnick]

On Tue, Apr 11, 2006 at 05:37:48PM -0500, Russ Cox wrote:
> > P.S. Now, if I were an independent C++ consultant, I wouldn't push too hard,
> > after all -- even they should remember what happened to the Tower of Babel.
>
> The people at Babel had one really good language that
> everyone understood, and they were highly productive.
> This reminds you of C++ programmers?

  That actually does remind me of C++ circa '90(*). From then on, it
  was all downhill.

Thanks,
Roman.

(*) I believe '90 was a year ARM got published give or take a year or two ;-)

Re: [9fans] Good enough approximation for ape/pcc

[Roman Shaposhnick]

On Mon, Apr 10, 2006 at 05:07:03PM -0700, David Leimbach wrote:
> On 4/10/06, Roman Shaposhnick <rvs@sun.com> wrote:
> > On Mon, Apr 10, 2006 at 04:18:56PM -0700, David Leimbach wrote:
> >   If the punch line here is, in fact, what I think it is, then
> >   a good optimizing compiler should be able to make these two
> >   pretty close in terms of performance.
>
> Perhaps... but only if the iterator is a real pointer.

  Or a carefully written one.

> So if I wrote my own datatype and implemented the same semantics that
> you'd expect for postfix ++ you'd likely find the following
> pseudocode:
>
> copy the iterator;
> increment *this;
> return the copy.

  Good. The punch line is exactly what I though it would be ;-) I mean,
  with C++ you never know.

> Do you really want to do that at the end of every loop iteration?  And
> what if I add some other logic between increment *this and return the
> copy, like some mutex locking/unlocking or whatever... the compiler is
> helpless to help my code here, and I throw out a copy in every loop.

  I guess I made a stronger statement that I wanted to. I was more concerned
  about somebody using prepackaged iterators (STL for example) not
  realizing the difference between ++a and a++. Somehow I feel that if a
  person took time to *explicitly* write the copy/return sequence (like
  you did in your example) than it would take a really unexperienced
  C++ programmer to not recognize the difference.

  Now, prepackaged iterators are usually part of the C++ environment, hence
  they can exploit all sorts of optimization opportunities available
  in that particular system (yes these are mostly pragmas, but hey -- they
  are invisible to an end user).

  Once again, don't get me wrong -- I'm not claiming that a properly written
  implementation will always equate ++a with a++ in terms of performance,
  but in certain cases it might.

> >   I've been doing optimizing compilers at Sun for quite some time
> >   now (C/C++ and Fortran) and one thing that I constantly talk
> >   to our customers about is that in todays world of opaque CPU
> >   design they actually don't know whether 'a = a + 1;' is slower
> >   or faster than 'a++;'. So the best advice I can give them
> >   is to:
> >
> >      1. Express semantics, not how to generate code
> >      2. Pick a compiler vendor you can trust.
> >      3. Make Performance Analysis part of your debugging.
>
> With C++ you need to understand the side effects of the language.  You
> could add profiling and logging to your copy constructor for that
> iterator above, but you might not understand why you're making so many
> copies, throwing them away and having to run both a constructor and a
> destructor at the bottom of the loop.

  I disagree somewhat. My point was -- that C++ is no longer the only
  thing you are supposed to understand inside and out if you really
  want to know what happens when your code gets executed. Modern hardware
  is very much that way too. Which means that it doesn't really matter
  what language you use -- you never really sure about performance
  implications of even the simplest of constructs (anybody who have touched
  Itanium even with a six foot pole would understand ;-)).

  My point was -- there's no way you can survive without #3 anyway, which
  means that instead of worrying about everything at a coding level -- just
  code away (and yes I agree -- understanding language semantics helps a
  great deal) the most clean code you can possibly afford and rely on
  performance analysis to catch surprises.

Thanks,
Roman.

Re: [9fans] Good enough approximation for ape/pcc

[Charles Forsyth]

i rather strongly feel that the c99 people ought to have found
something really constructive to do instead.

Re: [9fans] Good enough approximation for ape/pcc

[geoff]

> What if I change the name of the function later?  Isn't that what
> variables are for?

No, that's what sam's x//c// is for.  Put

x/(^|[^a-zA-Z0-9_])OLD[^a-zA-Z0-9_]/ x/[a-zA-Z0-9_]+/ c/NEW/

in lib/sam.cmds and snarf and paste it into your sam command window as
needed.  It's quick and easy.

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> did you mean use gcc directly?

i meant pcc.

> I am not sure If I understood you correctly but to clarify my original question.
>
> Sometimes when I dont have access to my plan 9 system and my only computer
> is a linux box I want to check if a piece pf code will compile under ape.

you could ask tip9ug or one of the other net systems nicely for an account.
and then use drawterm.

> is there a way to use gcc so that it will behave more like the ape tools?

no.

russ

Re: [9fans] Good enough approximation for ape/pcc

[Fernan Bolando]

On 4/8/06, uriel@cat-v.org <uriel@cat-v.org> wrote:
> Writing code that will compile with ?c is just matter good style, ie.,
> not (ab)using cpp, not using gcc extensions and so on; see
> /sys/doc/comp.ps for details. Ape doesn't not even come into the
> picture, no sane C code should ever need to use cpp(1)
>
> Figuring out if the builtin preprocessor will handle your code should
> be obvious, but if you really want to test, you could use the port of
> the compilers that is part of Inferno.
>
> And if you have the disgrace of having to write software under lunix,
> I would recommend using the p9p libs and doing native ports
> to Plan 9. Or just use Limbo and Inferno and be happy.
>
> Ape is an unfortunate historical aberration, lets leave it at that and
> not write new code that depends on it.

My skills are not always good enough to port everything to plan9 natively.

I am also apprehensive to port some stuff natively because, some of the stuff
that where ported native IMO had far too much structural change that it would
be difficult to merge back to the orginal code.
I dont want to end up using code from projects that I like and not be able
to contribute to it.( assuming I have something to offer )

New codes should be written in p9p or plan9 native, But for other poeples
project they should be the one to decide I guess.As I understand it
this was the main reason ape was created

How do you guys handle this type of situation?

--
Public PGP/GnuPG key (http://www.fernski.com)
pub 1024D/3576CA71 2006-02-02 Fernan Bolando
Key fingerprint = FDFE C9A8 FFED C1A5 2F5C EFEB D595 AF1C 3576 CA71

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> New codes should be written in p9p or plan9 native, But for other poeples
> project they should be the one to decide I guess.As I understand it
> this was the main reason ape was created
>
> How do you guys handle this type of situation?

They don't.  They just like to talk.

APE is still used for porting large software packages to Plan 9,
like TeX, Python, and Ghostscript, just to name a few.  But the
only real way to find out whether something will compile with
APE is to try it.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

when ansi was going crazy, many years ago, i gave a talk
at AUUGM about "safe C".  most of the audience understood,
despite my tequilla girl and my silly hat.

write it clean and portable ... ifdefs are so 80s.

brucee

On 4/8/06, Russ Cox <rsc@swtch.com> wrote:
> > New codes should be written in p9p or plan9 native, But for other poeples
> > project they should be the one to decide I guess.As I understand it
> > this was the main reason ape was created
> >
> > How do you guys handle this type of situation?
>
> They don't.  They just like to talk.
>
> APE is still used for porting large software packages to Plan 9,
> like TeX, Python, and Ghostscript, just to name a few.  But the
> only real way to find out whether something will compile with
> APE is to try it.
>
> Russ
>
>

Re: [9fans] Good enough approximation for ape/pcc

[Rob Pike]

> ifdefs are so 80s.

i wish that were so.

-rob

Re: [9fans] Good enough approximation for ape/pcc

[Bruce Ellis]

so do i.  dealing with code that has more lines for the preprocessor
than for the compiler is torture.  writing such code must be a disease.

brucee

On 4/9/06, Rob Pike <robpike@gmail.com> wrote:
> > ifdefs are so 80s.
>
> i wish that were so.
>
> -rob

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

i'm not convinced this is useful.  if your program is sufficiently
complicated to warrent this sort of debugging aid, just printing
the caller's name (or pc) is most likely insufficient.  most likely
you're going to need to know the whole call stack. and likely function
arguments and locals.

i did write a pretty large billing system that announced that
selected functions had been called in the debugging log.  even if we
had been programming to c99 at the time, __func__ would not have been
useful because we also printed out the most helpful arguments to
the functions we were tracing.

- erik

On Sun Apr  9 16:58:17 CDT 2006, schwartz@bio.cse.psu.edu wrote:
> Nah, even simple function calls can use it.
>
>    check(a, b, c, __func__);
>
> It's true, it would be nice to find out the caller from within check(),
> but this achieves most of the utility with a much simpler implementation.
>

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

On Mon Apr 10 09:18:01 CDT 2006, rminnich@lanl.gov wrote:
> Brantley Coile wrote:
> It's humorous to see the inline madness, on machines with 512KB caches yet:
> [rminnich@q linux-2.6.16]$ grep -r -i 'static inline' . |wc
>    21262  142677 1810997
>
> yep, 21262 instances of 'static inline'. Even better:
>
> [rminnich@q linux-2.6.16]$ grep -r -i 'static inline' include/ | wc
>     8249   54789  689506
>
> so, like, 13K of them are NOT in .h. Which is worse, the fact that the
> code is replicated all over the place, via .h, or there are .c files
> with static inline in them? yikes.

the instructive thing about linux is that it doesn't use the c library. this
is because glibc is too big to put in the kernel (and too much of a moving target).

linux/gnu is suffering from a complication feedback loop.

- erik

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

i've considered this.  would it be too much trouble to convert plan 9 object
files to elf? or to write a plan9-to-elf converter?

- erik

On Mon Apr 10 06:36:50 CDT 2006, brantley@coraid.com wrote:
> > i think the gcc folks have different goals.  they seem very interested in
> > lots of very sophisticated optimizations and support for every odd corner case.
>
> Or they might just like writing stuff for the compiler, personal
> entertainment.  Or they like seeing their names on gcc.gnu.org
> projects pages.  Or they really think that all this work makes some
> difference.  I don't know anyone who works on the beast, so I've no
> real clue as to why people continue to spend time on this monster.
> Let's just move Ken's C compiler everywhere.
>

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

paul,

i'm looking for a job.  my professional experience is in distributed
search.  but i wrote quite a few interpreters and optimizers in the
process.  (e.g. given a federated field set, a mapping to a real database
and a query, the query can be rewritten and then simplified in an
abstract fashion.)  i have a b.a. in mathematics from st. olaf college.
(they offered no c.s. degree at the time.)

any interest?

- erik

On Mon Apr 10 09:43:27 CDT 2006, plalonde@telus.net wrote:

> That said, Neoptica (www.neoptica.com - the startup I'm involved
> (committed?) with) is looking for a world-class systems/compilers
> person to join our team; we're working on novel approaches to exploit
> multi-core architectures, GPUs, and fast bi-directional busses to
> improve the visuals in next-games.  The systems job add isn't posted
> yet, but should be soon - for the flavour through, think Brook
> (http://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf), Sequoia
> (http://graphics.stanford.edu/~kayvonf/papers/sequoia_draft.pdf), and
> EAGL (http://www.cs.brown.edu/~tor/sig2002/ea-shader.pdf)

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

sorry.

- erik

On Mon Apr 10 19:41:18 CDT 2006, quanstro@quanstro.net wrote:
> On Mon Apr 10 09:43:27 CDT 2006, plalonde@telus.net wrote:
>
> > That said, Neoptica (www.neoptica.com - the startup I'm involved
> > (committed?) with) is looking for a world-class systems/compilers
> > person to join our team; we're working on novel approaches to exploit
> > multi-core architectures, GPUs, and fast bi-directional busses to
> > improve the visuals in next-games.  The systems job add isn't posted
> > yet, but should be soon - for the flavour through, think Brook
> > (http://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf), Sequoia
> > (http://graphics.stanford.edu/~kayvonf/papers/sequoia_draft.pdf), and
> > EAGL (http://www.cs.brown.edu/~tor/sig2002/ea-shader.pdf)

[9fans] Good enough approximation for ape/pcc

[Andrew Simmons]

 >limbo's ":=" works like that ...

 >i := 0;    # declares i as in an int and assigns 0 to it
 >r := ref Boo;    # declares r to be scarey

Well yes, but didn't Fortran's "=" work like that well before limbo?

C     DECLARE I AS AN INTEGER AND ASSIGN 0 TO IT
        I=0
C     DECLARE A TO BE A SCAREY FLOATING POINT NUMBER
       A=666.0

Re: [9fans] Good enough approximation for ape/pcc

[Brantley Coile]

No.  In Limbo if you say I=0 and you haven't declared `I' then
you get an error.  You only use the `I := 0' when you want to make
a new `I.'

And having lived with FORTRAN, a requirement to declare your variables
was a big advance.  It was hard to find misspelled variables in
FORTRAN because they weren't flaged as errors.  History is a good thing.

>  >limbo's ":=" works like that ...
>
>  >i := 0;    # declares i as in an int and assigns 0 to it
>  >r := ref Boo;    # declares r to be scarey
>
> Well yes, but didn't Fortran's "=" work like that well before limbo?
>
> C     DECLARE I AS AN INTEGER AND ASSIGN 0 TO IT
>         I=0
> C     DECLARE A TO BE A SCAREY FLOATING POINT NUMBER
>        A=666.0

Re: [9fans] Good enough approximation for ape/pcc

[quanstro]

don't get me going.  i once worked on a cad product complete
with a c++ shell and a fortran middle (complete with holorith data
and gobs of computed gotos.)

crunchy on the outside and chewy in the center.

- erik

On Tue Apr 11 05:22:29 CDT 2006, andrew.simmons@monitorbm.co.nz wrote:
>  >limbo's ":=" works like that ...
>
>  >i := 0;    # declares i as in an int and assigns 0 to it
>  >r := ref Boo;    # declares r to be scarey
>
> Well yes, but didn't Fortran's "=" work like that well before limbo?
>
> C     DECLARE I AS AN INTEGER AND ASSIGN 0 TO IT
>         I=0
> C     DECLARE A TO BE A SCAREY FLOATING POINT NUMBER
>        A=666.0
>

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> i've considered this.  would it be too much trouble to convert plan 9 object
> files to elf? or to write a plan9-to-elf converter?

this always seems like a good idea at first but is not,
as least as a solution for plan 9 from user space.

one of the main goals of p9p is to play nice with the
local system.  if you're going to do that you need to
be able to link with the local system libraries, which
means knowing the local system's calling convention,
object file formats, etc.  also debugging format so that
you can generate debuggable binaries.

plan 9 386 .8 files (just to take an example, any architecture
will do) look nothing like unix .o files, so it's not like
you could just change the compiler to generate .o either.
you'd have to merge 8c and 8l into a single program just
to generate a traditional unix .o, and then use the system
linker or maybe write your own.

that's not what i would call a portable system.  better to
have ansi c copies of the source and just use the system
compiler in the first place.  much less to maintain.

the work might be worth it if you were building your own
operating system and wanted it to use a non-gcc compiler
suite.  but at that point you could just load plan 9 binaries
instead of elf binaries and be done.

russ

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

somehow i thought this might be the case.

- erik

On Tue Apr 11 06:58:07 CDT 2006, rsc@swtch.com wrote:
> > i've considered this.  would it be too much trouble to convert plan 9 object
> > files to elf? or to write a plan9-to-elf converter?
>
> this always seems like a good idea at first but is not,
> as least as a solution for plan 9 from user space.
>
[etc]

Re: [9fans] Good enough approximation for ape/pcc

[Charles Forsyth]

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

it would still be useful for other software, and in some ways not too hard to do,
if so much other code didn't depend, often needlessly, on peculiar things in gcc,
as noted in earlier discussion.

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

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Good enough approximation for ape/pcc
Date: Tue, 11 Apr 2006 19:50:17 -0500
Message-ID: <c213b8da0fef7d29740a79d82e6277ee@quanstro.net>

somehow i thought this might be the case.

- erik

On Tue Apr 11 06:58:07 CDT 2006, rsc@swtch.com wrote:
> > i've considered this.  would it be too much trouble to convert plan 9 object
> > files to elf? or to write a plan9-to-elf converter?
>
> this always seems like a good idea at first but is not,
> as least as a solution for plan 9 from user space.
>
[etc]

Re: [9fans] Good enough approximation for ape/pcc

[Aharon Robbins]

How hard would it be to teach kenc to generate .s files and use
the system assembler/loader? Or are there calling convention
issuees as well?

In article <c213b8da0fef7d29740a79d82e6277ee@quanstro.net> you write:
>somehow i thought this might be the case.
>
>- erik
>
>On Tue Apr 11 06:58:07 CDT 2006, rsc@swtch.com wrote:
>> > i've considered this.  would it be too much trouble to convert plan 9 object
>> > files to elf? or to write a plan9-to-elf converter?
>>
>> this always seems like a good idea at first but is not,
>> as least as a solution for plan 9 from user space.
>>
>[etc]

Re: [9fans] Good enough approximation for ape/pcc

[R]

On 4/12/06, Aharon Robbins <arnold@skeeve.com> wrote:
> How hard would it be to teach kenc to generate .s files and use
> the system assembler/loader? Or are there calling convention
> issuees as well?

that would probably mean merging the compiler
and the linker :) and yes there are calling convention
issues as well.

read the Ken Thompson paper about the compiler
(in the distribution).

PS.
someone was trying some time ago to teach gcc
generate native plan9 object file format.
did this get any result ?

Thanks.

Re: [9fans] Good enough approximation for ape/pcc

[Russ Cox]

> How hard would it be to teach kenc to generate .s files and use
> the system assembler/loader? Or are there calling convention
> issuees as well?

There are calling convention differences and you'd also
have to emit debug info, but this would probably not be
too bad an intermediate step.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Charles Forsyth]

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

i must say i don't see the point though.
in many ways, ?[acl] are attractive as a whole. (the
way it is done and the distribution of the work is part
of the point, although it's worth noting that the
arrangement isn't novel to it.)  going back to .s production seems a
retrograde step to me.  indeed, some thought so even
in the 1970s!  it's fairly typical of gnu to have
stuck with it.

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

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Good enough approximation for ape/pcc
Date: Wed, 12 Apr 2006 09:01:37 -0500
Message-ID: <d85a99557c123b033297cca3a93c4897@swtch.com>

> How hard would it be to teach kenc to generate .s files and use
> the system assembler/loader? Or are there calling convention
> issuees as well?

There are calling convention differences and you'd also
have to emit debug info, but this would probably not be
too bad an intermediate step.

Russ

Re: [9fans] Good enough approximation for ape/pcc

[Brantley Coile]

Breaking from a thought habit can be hard.  It's just our habit to
think that we are limited to a single C compiler on our system.  Why
not have two compilers, gcc for linux, and ?[acl] for other stuff?  On
Plan 9 we have c89 to compile foreign code.  I would rather compile
applications on Linux using kenc any day.  P9p is doing something
different, so it's using the right compiler for its job.

I have two machines on my desk, a plan 9 terminal and a Mac.  It took
a little effort to break the thought habit that I have only one
machine.  Same is true about compilers.  We can, and do, have more
than one.

> i must say i don't see the point though.
> in many ways, ?[acl] are attractive as a whole. (the
> way it is done and the distribution of the work is part
> of the point, although it's worth noting that the
> arrangement isn't novel to it.)  going back to .s production seems a
> retrograde step to me.  indeed, some thought so even
> in the 1970s!  it's fairly typical of gnu to have
> stuck with it.

Re: [9fans] Good enough approximation for ape/pcc

[erik quanstrom]

the problem is that the X11 libraries are required for p9p to be useful.
tcc or icc on x86 machines seem good alternatives to gcc.
(tcc is very fast.)

- erik

On Tue Apr 11 20:11:18 CDT 2006, forsyth@terzarima.net wrote:

> it would still be useful for other software, and in some ways not too hard to do,
> if so much other code didn't depend, often needlessly, on peculiar things in gcc,
> as noted in earlier discussion.
>

Re: [9fans] Good enough approximation for ape/pcc

[Charles Forsyth]

> the problem is that the X11 libraries are required for p9p to be useful.

the X11 libraries are probably not so bad (well, not in that sense), but i
wasn't referring to using ?[acl] for p9p anyway