Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!gitpyr!don From: don@gitpyr.gatech.EDU (Don Deal) Newsgroups: comp.sys.m68k,comp.sys.intel Subject: Re: Re: Re: Recent Motorola ad seen in Byte Message-ID: <3441@gitpyr.gatech.EDU> Date: Fri, 17-Apr-87 01:49:49 EST Article-I.D.: gitpyr.3441 Posted: Fri Apr 17 01:49:49 1987 Date-Received: Sun, 19-Apr-87 10:31:40 EST References: <362@sbcs.UUCP> <930@intsc.UUCP> <1517@ncr-sd.SanDiego.NCR.COM> <932@intsc.UUCP> Reply-To: nobody Followup-To: comp.sys.intel Distribution: comp Organization: Georgia Institute of Technology Lines: 62 Summary: give me a break please Xref: mnetor comp.sys.m68k:361 comp.sys.intel:158 In article <932@intsc.UUCP> tomk@intsc.UUCP (Tom Kohrs @fae) writes: >What caused most of the frustration toward the 286 was DEC and Motorola >both went to a 32bit programming model at that time. Programmers quickly >jumped to arms to adhere to the old maxim of using all of the available >memory plus one byte. When these neat new programs (ie BSD 4.x) were >forced back down to the 16 bit architecture things got tricky. Many >programmers decided that programming in a 32 bit environment required >less effort and less need for structure than the 16 bit environment and >so to justify their not liking to work on 16 bit machines they were labled >as being kludges or obsolete. Oh I get it. It was lazy programmer's who resulted in negative comments being made about the 286. Thanks for clearing that up. Next time I reload a segment register to address more than 64k, I'll remember that I'm doing structured programming. Gee, come to think of it, all of the 8-bit microprocessors I used could only address 64k. Maybe i've been a structured programmer all along! >The only thing I could fault Intel for is possibly not going to a 32 bit >architecture sooner, but we were too busy building 80186's (5-6 million >sold so far). Also we were learning about how to build an MMU (the hard >part) without having to debug 32 bit ALU's at the same time. The design >decision that was made 9+ years ago was do we build a slow 32bit machine >or a fast 16 bitter. Intel decided on the fast 16bit, Motorola went for >the slow 32 bit. The rest is history. Oh, use your imagination. If you don't have one, here are a few of my favorite gripes: - using single-byte opcodes for infrequently used instructions AAA, AAS, DAA, DAS, LAHF, SAHF - 1 byte - using longer code sequences for commonly used operations PUSH'ing more than two registers. Having a register mask for push and pop would have been nice. Using an eight bit mask would have allowed the most commonly-used registers to be pushed in one instruction - a sixteen-bit mask would take care of all of them. Not being able to move immediate data into a segment register. How often have you seen: MOV AX,data MOV ES,AX This makes >64k addressing just *so* much more painful. - Selling silicon with bad bugs in it. The 286 had problems with the POPF instruction and with one or more instructions in protected mode. So many broken parts were sold, that it was essentially impossible for software developers to make use of these instructions (assuming they knew about the problems). Hearing word of a recall program for 386 makes me wonder how much of an improvement the 386 really is. - 8080 compatibility. In this day and age, it's no longer an advantage; it's a liability. -- D.L. Deal, Office of Computing Services, Georgia Tech, Atlanta GA, 30332-0275 Phone: (404) 894-4660 ARPA: don@pyr.ocs.gatech.edu BITNET: cc100dd@gitvm1 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!don