Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!cbmvax!higgin From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom GUEST) Newsgroups: comp.sys.amiga Subject: Re: C, Manx, 32 bits, 68K, VAXen, etc. Message-ID: <1262@cbmvax.cbmvax.cbm.UUCP> Date: Tue, 20-Jan-87 18:14:32 EST Article-I.D.: cbmvax.1262 Posted: Tue Jan 20 18:14:32 1987 Date-Received: Wed, 21-Jan-87 04:01:57 EST References: <2229@jade.BERKELEY.EDU> <1250@cbmvax.cbmvax.cbm.UUCP> <2271@jade.BERKELEY.EDU> Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom GUEST) Organization: PDH, Inc. Lines: 118 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. $