From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: Any research putting c above ada? Date: 1997/04/17 Message-ID: <5j5nf0$c38@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 235554632 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <5ivtcu$puv@huron.eel.ufl.edu> <5j1ann$f20@bcrkh13.bnr.ca> <5j31dt$o3j@huron.eel.ufl.edu> Organization: Prism Systems Inc. Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-17T00:00:00+00:00 List-Id: In article <5j31dt$o3j@huron.eel.ufl.edu>, Daniel P Hudson wrote: > >kaz@vision.crest.nt.com (Kaz Kylheku) wrote: > >Damn, I'm gonna have to expand your twit scope to all usenet newsgroups, >I see. It is so peaceful not reading you or Peter, or Craig's flames >on poor unsuspecting newbies who make a simple mistake. Too bad people >reply to them or I'd never see that much. If you note, most comp.lang.c flames are directed at cocky, yet incorrect attempts to answer newbie questions and those unsuspecting newbies who want their homework served on a silver platter. Most of the c.l.c regulars in fact act as champions for the downtrodden newbie, defending them from misinformation. >>>Kaz's soul point is to not let you prove that there is ever a condition >> ^^^^ that's sole. > >At least you don't deny it. BTW you do know what grammar/spelling >flames are considered by that precious netiquette [the one you're >always bitching about people not following] of your's don't you? Look whatever. A spelling flame is still one notch above some low blow like comparing someone to Scott Nudds, isn't it? That's where I draw the line. :) >Actually that post got sent out without my control, the system crashed >in the middle of my writing, you know how AIX gets sometimes, It just >stops accepting input for no apparent reason and then does all sorts of >crazy stuff. It also resent out the message with the edited version >later on, I'm told. What can you expect from something written in C. ;-) Ah, right! And you conveniently forgot the digital signature. Well, you know what? I didn't write that spelling flame either. In fact, I'm not the author of this very article; it was just written by someone _called_ Kaz. :) >>-> Perhaps you knew of a better micro-processor for systems that could >>-> fit on the average desktop? It just so happens that the 8086 was >>-> state of the art back then. > >>Can you say, MC68000? > >Can you say cost effective? > >The i8088, more specifically than the i8086, was small, technologically >and advancement over previous CPU's [4004 etc..] and cost efficient. > >The Motorolla MC68000 was small, technologically advanced, and TWICE >the cost. PC's were expensive enough already, thank you. Plus, the 68000 Well, twice the cost of a processor doesn't necessarily translate to twice the cost of the whole box: the processor cost is amortized over the the whole unit. Also, remember that the 68K is easier to interface. The 8088 had to carry an external address decoder, for instance, due to its multiplexing of data and address lines. This multiplexing saved 8 data pins, but three additional lines had to be used to decode the state of the 8088. Thus, a total saving of 5 pins bought by adding a bunch of other logic! On the other hand, there wasn't an 8 bit version of the 68K yet (I don't think): you needed a 16 bit data bus and that was that. This was probably significant---after all they did choose 8088 in favor of 8086. >was an extremely slow chip, even compared to the 8086/8088. Add to that I doubt that. The clock cycle counts for many 68K instructions are about on par with 8086 instructions. But the 68K instructions do more. >the additional cost in memory chips, and its easy to see why IBM choose >Intel. Why? They are a business and Intel offered the best deal. As to I suspect it was more because of existing assembly language software written for the i8080 that, though not binary compatible, could be translated at the source code level to 8086 code. It was all in the spirit of good old backward compatibility coupled with a lack of foresight, rather than technical innovation. Did the IBM team not originally plan to bundle some CPM/86 type thing with the PC? My recollection is hazy. Thanks to IBM, the comp.lang.c newsgroup still fields questions like ``Help, I have 32 megs of RAM, but I can't make arrays bigger than 64K, and halloc() craps out at 500K!'' >proof of the success over using Intel over Motorolla, look at Apple and >IBM clones [Obviously IBM makes more than PC's] and compare. Clones >are growing at a rate of at least 50% a year [Gateway 2000 is 100%] >and Apple is, oh that's right, down sizing. I asked for a reasonable >replacement, not one that would have put IBM under, Kaz. So now you are saying that it was the Motorola processor that is responsible for Apple's failings? If IBM had gone with the 68K, the PC would have gone under? Interesting hypothesis, and so conveniently untestable, too!