Re: [9fans] Good enough approximation for ape/pcc
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 [EMAIL PROTECTED] you write: somehow i thought this might be the case. - erik On Tue Apr 11 06:58:07 CDT 2006, [EMAIL PROTECTED] 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
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
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. ---BeginMessage--- 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---End Message---
Re: [9fans] Good enough approximation for ape/pcc
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
rob had a aimple example of some java that := could help. brucee On 4/11/06, Skip Tavakkolian [EMAIL PROTECTED] 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
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.
[9fans] Good enough approximation for ape/pcc
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
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, [EMAIL PROTECTED] 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
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
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
On Mon, Apr 10, 2006 at 05:07:03PM -0700, David Leimbach wrote: On 4/10/06, Roman Shaposhnick [EMAIL PROTECTED] 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
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
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
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. ---BeginMessage--- somehow i thought this might be the case. - erik On Tue Apr 11 06:58:07 CDT 2006, [EMAIL PROTECTED] 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]---End Message---
Re: [9fans] Good enough approximation for ape/pcc
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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED] 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
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
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)PaulOn 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.bruceeOn 4/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Gcc does all these kinds of optimizations and more. I can't imaginewhat 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 otheremployee, by making themselves indispensable. I don't think it'snecessary or a conscious decision on their part, but it's that aspectof human nature that eventually defeats any attempt at benevolentsocial engineering. Call it "the tragedy of the commons", if you needa label.++L PGP.sig Description: This is a digitally signed message part
Re: [9fans] Good enough approximation for ape/pcc
-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
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
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
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
On 4/10/06, Andy Newman [EMAIL PROTECTED] 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
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
On 4/10/06, Roman Shaposhnick [EMAIL PROTECTED] 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
sorry. - erik On Mon Apr 10 19:41:18 CDT 2006, [EMAIL PROTECTED] wrote: On Mon Apr 10 09:43:27 CDT 2006, [EMAIL PROTECTED] 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
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
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, [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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
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
| 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
| 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
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
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 [EMAIL PROTECTED] 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
ifdefs are so 80s. i wish that were so. -rob
Re: [9fans] Good enough approximation for ape/pcc
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 [EMAIL PROTECTED] wrote: ifdefs are so 80s. i wish that were so. -rob
Re: [9fans] Good enough approximation for ape/pcc
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? smime.p7s Description: S/MIME Cryptographic Signature
[9fans] Good enough approximation for ape/pcc
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
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
On 4/8/06, Russ Cox [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] 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
On 4/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] 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
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
On 4/7/06, Russ Cox [EMAIL PROTECTED] 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
On 4/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] 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
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
