higgin@cbmvax.cbm.UUCP (Paul Higginbottom GUEST) (01/21/87)
In article <2271@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: $In article <1250@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom GUEST) writes: $>Why would Manx want to make their product SLOWER, LARGER, $ $You can either get smaller & faster, or a nice set of features. I use $GNU emacs, so you know what my tastes run to (and that's what it is, a $matter of taste). Agreed. $I nearly bought MANX, until I found out they didn't $even support a v7 C compiler. And according to you don't now, and $won't until 3.40 (though I have other sources that say otherwise). Are you sure you mean v7 and not BSD? What in v7 UNIX isn't supported under Manx C (except obvious machine stuff like fork())? $>But with garbage $>like the automatic concatenation of strings in the ANSI standard, I $>wish it weren't! E.g:... $> $>char *strings[] = { $> "this", $> "is", $> "a" $> "test" $>}; $ $Hmm - I thought they blew that off in favor of a string concatenation $operator in the pre-processor; which version of the standard are you $using? If it's there in the current draft, you should first check the $rationale behind it, and if you think they're wrong, notify the $standards committee. Well, I'm only going by what Jim Goodnow (author of Manx C) told me when I complained that the latest Beta version of Manx C does this. He said the ANSI standard [he was trying to be faithful to] wanted it this way. $>The strchrs and such have been added on top of the standard v7 stuff (isn't $>duplication wonderful?). $ $Sorry, but v7 didn't have anything like strchr/strrchr (index/rindex $for berkeleyphiles). Read what I said - they've been added ON TOP of v7. rindex/index were in K&R and so became pseudo C-standards. $>And most importantly, the code generator has been improved greatly. It's $>still not 100% if you decide to use a million register variables in one $>function, and 32 bit support still isn't perfect, but then there's no need $>to use the 32 bit stuff at all anyway. $ $[Time for some MANX bashing. Those not interested in another round of $compiler wars should skip this.] $ $Gee, it seems that the people at Manx need to go back to school - $they've forgotten one of the basic rules of programming: $ $ Make it RIGHT before you make it faster. $ You're obviously not aware of the commercial realities of software development. If "right" doesn't include having sufficient performance so as to be practical, then I disagree. I think you're saying that something should be "ideologically pure" before being optimized which is fine in Bell Labs, but not for struggling small software companies. $Seems like they should quit working on making it smaller and faster, $and worry about making it generate correct code. There's no such thing as "correct code". If you mean, functionally the compiler output does what the source dictates, then I agree, and Jim has worked hard at that for 3.40. What about the "n+1" garbage under Lattice that caused grief for Dave Wecker's terminal program? Was that "correct"? $Since I've got it in front of me, let me make the plug: The above $rules of programming can all be found in one short book, Kernighan and $Plauger's "The Elements of Programming Style." Recommended reading for $*all* programmers, and re-reading it never hurts. $ TOTALLY AGREED - FANTASTIC BOOK, ****BUT**** when financial survival says put out the product NOW or go under, you put the product out and take the heat. I'm not saying Manx would croak without their product on the Amiga (I have no idea), but sooner or later you have to make a cut-off date and release a product. Take the Amiga itself for example! The 1.0 version of the operating system was REALLY FLAKEY. The 1.1 release (which didn't come out until 6 months after the release of the computer) was better, but the authors KNEW it still wasn't perfect, but they knew it was a LOT BETTER than 1.0. And the same goes with 1.2, and so on. If you wait until it's perfect (and then only to the best of your knowledge, i.e., until someone finds the inevitable bug), you'll be waiting until hell freezes over. $Finally, there's a DAMN good reason for wanting the 32-bit stuff. Try $porting anything from the "all the worlds a VAX, and every variables's $a LONG" world of 4BSD (Note: this is rapidly being fixed; the bug $reports on it from CSRG are filling my mailbox at an alarming rate). Right - there's a perfect example of code generated using principles certainly abhorrent to K&P! Pointers and longs interchanged everywhere. Run the compiler silent and ignore the warnings. $You'll quickly find out you need 32-bit ints. Of course, on a 68K $family machines that predate the 68020, you really want both a 16-bit $int and a 32-bit int version of the compiler; one for porting, and one $for benchmarks (from the mouth of a major 68K computer manufacturer!). $Manx got that right. Amen. And yes, I don't forgive Manx either for not getting their 32 bit side in MUCH better shape than it is, but I DO understand the pressure factor. It ain't perfect, but it ain't useless either. $ <mike Regards, Paul.
mwm@eris.BERKELEY.EDU (Mike Meyer) (01/21/87)
In article <1262@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom GUEST) writes: >$I nearly bought MANX, until I found out they didn't >$even support a v7 C compiler. And according to you don't now, and >$won't until 3.40 (though I have other sources that say otherwise). > >Are you sure you mean v7 and not BSD? What in v7 UNIX isn't supported >under Manx C (except obvious machine stuff like fork())? No, I mean v7. The v7 C compiler supported structure assignments, in all their multivarious forms. Of course, we didn't convert to v7 until long after most people, so it's not clear how late a version of the C compiler we had. >$>The strchrs and such have been added on top of the standard v7 stuff (isn't >$>duplication wonderful?). >$ >$Sorry, but v7 didn't have anything like strchr/strrchr (index/rindex >$for berkeleyphiles). > >Read what I said - they've been added ON TOP of v7. rindex/index were >in K&R and so became pseudo C-standards. I think I did read what you said; since v7 didn't have anything like str[r]chr, there was no duplication involved for them. What you really mean here is that I should write what I mean. My copy of K&R doesn't mention rindex (at least not in the index). Index is included as a subroutine, but not mentioned as part of the string library. In any case, the str[r]chr stuff can't be blamed on ANSI, it belongs to AT&T. They didn't seem to think that index/rindex were part of the standard (and ok, V the system didn't quite grow out of v7, it grew out of a research Unix from just before the 7th version of the manual). These are minor nits, though. ANSI has got some REAL problems with it. Go to comp.lang.c for a discussion of that. >You're obviously not aware of the commercial realities of software >development. If "right" doesn't include having sufficient performance >so as to be practical, then I disagree. I think you're saying that >something should be "ideologically pure" before being optimized which is >fine in Bell Labs, but not for struggling small software companies. Nope; if it isn't fast enough, then you need to fix it. Fixing it isn't done by tweaking the code, it's done by finding a better algorithm (see K&Plaugher again!). Code tweaking for speed isn't necessarily bad, it should be done after the program is correct, though. Oh, yeah - I _do_ know something about commercial software development. That's one of the reasons I avoid it like the plague! Things shouldn't be ideologically pure; taking them away from that for performance reasons is a reasonable thing to do. For instance, the usual path for Unix tools is: shell script, to C code, to either the kernel or the shell. Consider either "more" or "test" for examples. The Berkeley ls is an example that isn't quite so extreme. >There's no such thing as "correct code". If you mean, functionally the >compiler output does what the source dictates, then I agree, and Jim >has worked hard at that for 3.40. What about the "n+1" garbage under >Lattice that caused grief for Dave Wecker's terminal program? Was that >"correct"? Yes, that's what I mean by correct code. It sounded like the latest version of Manx doesn't quite make it in all conditions. The n+1 garbage was just that, garbage. Lattice marketed buggy code; which is a bad thing. But that was two versions and nearly a year ago. What was Manx like back then? >TOTALLY AGREED - FANTASTIC BOOK, ****BUT**** when financial survival >says put out the product NOW or go under, you put the product out and >take the heat. I'm not saying Manx would croak without their product >on the Amiga (I have no idea), but sooner or later you have to make a >cut-off date and release a product. Take the Amiga itself for example! True; but Manx should be long past the point of releasing compilers with known bugs. After all, I bought my first compiler from them in '80 or so. And they've got an Amigac compiler out NOW that people seem to like a lot. And it sounds like the 32-bit integer model is known to not be right! Not that Lattice is perfect; I'm going to post a nasty note on 3.10 in the near future. They broke some things pretty badly; but they got a *lot* of the ANSI library in place, which I appreciate. What I really want is for there to be some competition in the Amiga C compiler market. I can't see buying another compiler when I've already got at least the second-best compiler on the market. When there are four or five, THEN it's time to buy another compiler. >The 1.0 version of the operating system was REALLY FLAKEY. The 1.1 >release (which didn't come out until 6 months after the release of the >computer) was better, but the authors KNEW it still wasn't perfect, but Uh, question - was it really 6 months? I thought the Amiga was released (being sold in stored, that is) in November of '85 or so. I bought mine in January of '87, and it came with the 1.1 disks. >Right - there's a perfect example of code generated using principles >certainly abhorrent to K&P! Pointers and longs interchanged everywhere. >Run the compiler silent and ignore the warnings. Damn straight. It was produced under the "get it out now or we're dead" environment. Something about DARPA wondering what had happened to the OS they were paying for that was pushing two years late (this is 4.2 we're talking about). And let's not talk about portals :-). > Paul. <mike Disclaimer: Just to make it perfectly clear to those not familiar with the guts of Berkeley computing. I *do not* work for CSRG, and had nothing to do with the development of 4.2BSD. I had nothing to do with 4.3 and 4.? (whatever they want to call it), other than trying to sell back some of my mods. What I do is maintain the kernel for many (12 ?) vaxen for the Berkeley Computer Center. Don't mix us up with the people who produce 4BSD, as you'll make both groups mad.
wagner@utcs.UUCP (01/23/87)
I think the point that Mike Meyer was trying to make got lost in Paul's response. MANX should be spending it's time getting the output generated to be a faithfull translation of the input source, and only then spend time on performance. We can all hack a slightly slower program much easier than one that compiles and blows up. And no, I don't think Lattice is a perfect compiler either. But I use it, despite it's speed problems, because it appears that it's track record on producing good output is much better. Michael
jdg@elmgate.UUCP (01/26/87)
In article <2277@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: >What I really want is for there to be some competition in the Amiga C >compiler market. I can't see buying another compiler when I've already >got at least the second-best compiler on the market. When there are >four or five, THEN it's time to buy another compiler. > > <mike > Well now... I did a great job editing down the verbage 8^). Anyhow, maybe you'd like to take up the task of putting Lattice and Manx behind the 8 ball? I know of two C compilers that can be had now or RSN (month or two). All you have to due is port them. As you don't like to write commercial software, you could make it freely redistributable. The Motorola one on Fish disk #53 seems available now and needs LOTS of work (Fred's words paraphrased). Maybe netter's would like to help out. Second there is supposed to be the release of the FSF/GNU compiler for GNU Real Soon Now, or so I'm told. Again it'll have to be ported. So there's the competition you wanted. They can't beat you if the port works correctly and produces GreenHills or better code. Right? As you might guess I have Lattice (3.03) and Manx (3.20). Neither are really any good. One too big/slow. The other I paided $600 for a year ago for free updates and haven't seen a dimes worth since. Since what I have can't play with 1.2 it's useless as TOS on an ST. Things could be worse. I own an ST as well (1meg w/42meg HD). They have about 7 fair to trash C Compilers to choose from. Imagine! Seven lousy code generators/parsers/libs. That's MUCH more frustrating than two fair to ok ones. The real question is WHY can't someone/anyone sell me a true optimizing solid C compiler for a 68K based box NOT running U*IX? Heck I've shelled out close to $1000 bucks already for C compilers between the two systems so price ain't the problem. You make it, have it produce code as good (or so) as say my SUN or GreenHills and I'll buy it. As it is I'm very gun shy. I've been burned (my own fault) too many times now with 'itty-bitty-folks' idea of a C compiler. PS. Manx... if you really exist!... for chr*st sake, will I ever see another release? No..? sigh............ -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>
hadeishi@husc4.UUCP (01/27/87)
In <562@elmgate.UUCP> jdg@elmgate.UUCP (Jeff Gortatowsky) writes: >As you might guess I have Lattice (3.03) and Manx (3.20). Neither are >really any good. One too big/slow. The other I paided $600 for a year >ago for free updates and haven't seen a dimes worth since. Since what I >have can't play with 1.2 it's useless as TOS on an ST. Lattice 3.10 plays with 1.2 just fine (I just finished a short little program for EA with it.) But, it still generates pretty big code (although it does have the small code/data option now, still not as good as Manx.) >PS. Manx... if you really exist!... for chr*st sake, will I ever see >another release? No..? sigh............ Jim Goodnow has posted on the Well that yes, he is alive and well, and yes, 3.40 will actually be released Real Soon Now. And he promises miracles have happened with the debugger, as well as lots more good stuff. I know 3.40 works and exists, since several friends of mine have beta copies they use frequently. It also supports structure passing and assignment, plus 68881, FFP, and IEEE floating point code generation. -Mitsu
fnf@mcdsun.UUCP (01/28/87)
In article <562@elmgate.UUCP> jdg@aurora.UUCP (Jeff Gortatowsky) writes: > [stuff about C compilers] > The Motorola one on Fish disk #53 seems available now >and needs LOTS of work (Fred's words paraphrased). Maybe netter's would >like to help out. Just to clarify, the compiler on disk #53 has NOTHING to do with Motorola other than: (1) It is for the 68000. (2) It was apparently developed on a Motorola VME series machine. (3) It happens to generate assembly code that bears a fair resemblance to that produced by the 68000 SGS compiler, probably because of (2) and the author wanted to use the native assembler for testing purposes. -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
jdg@elmgate.UUCP (02/03/87)
In article <238@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes: >In article <562@elmgate.UUCP> jdg@aurora.UUCP (Jeff Gortatowsky) writes: >> The Motorola one on Fish disk #53 seems available now >>and needs LOTS of work (Fred's words paraphrased). Maybe netter's would >>like to help out. > >Just to clarify, the compiler on disk #53 has NOTHING to do with >Motorola ,........... >-Fred >-- >=========================================================================== >Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA >{seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 >=========================================================================== I'm sorry Fred. I hope none of the folks you work for got bent outta shape. I simply must have misunderstood the origins of the compiler. Anyways as you probably know by now, I've ordered it. I'll 'C' what can be done. This line for rn. This line for rn. This line for rn. This line for rn. This line for rn. This line for rn. -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>