Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike Meyer) Newsgroups: comp.sys.amiga Subject: Re: C, Manx, 32 bits, 68K, VAXen, etc. Message-ID: <2277@jade.BERKELEY.EDU> Date: Wed, 21-Jan-87 03:08:38 EST Article-I.D.: jade.2277 Posted: Wed Jan 21 03:08:38 1987 Date-Received: Wed, 21-Jan-87 22:50:31 EST References: <2229@jade.BERKELEY.EDU> <1250@cbmvax.cbmvax.cbm.UUCP> <2271@jade.BERKELEY.EDU> <1262@cbmvax.cbmvax.cbm.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike Meyer) Organization: Missionaria Phonibalonica Lines: 118 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.