mo@seismo.UUCP (Mike O'Dell) (04/27/85)
As a peson who has spent almost a year trying to get quite-well-written C code running on an 8086, I cannot let the defense of this abomination go by unchallenged. I have seen 386 stuff and it is like the 286, but it has a mode where it isn't like a 286 and does have larger addresses. But as for the 8086, 8186 and 8286, THEY ARE ALL POORLY-DESIGNED 16-BIT MINICOMPUTERS WITH PRETENTIOUS INDEX REGISTERS, and one of the worst hosts a C compiler writer could be faced with. The miserable quality of the existing *86 C compilers atests to this fact. Only now are compilers coming availble that truly do the Large address model correctly (in spite of vendors strenuous claims to the contrary). But the dead-giveaway is the fact you need "address models" at all!!!!! Our program runs perfectly well in 650-700K bytes of memory on 68K systems without batting an eye. It handles LARGE objects, ie, bigger than 64K bytes, and it does LOTS of pointer arithmetic, including pointer subtractions. To get it to run on a *86 in the max memory available on an IBM PC-XT, we had to chop out much dynamic debugging code we would have liked to have left in, and battle tooth and nail with an addressing architecture which is very much like the IBM System 370, but in reality much worse because of the paucity of registers available for doing anything. Many of our problems stem from inadequacies of the compilers available when we started, but the reason the compilers were poor is not because the people doing them weren't smart; it was because the machine they were dealing with are awful. To give ground where deserved, running an 8086 in split-I/D mode with the code and data limited to 64K it is a fine competitor with most of the LSI-11/RL01 systems I have used. But the last time I checked my watch, we are in the last fifth of the Twentieth century and the 11/70 stopped being remotely state of the art well over 6 years ago. As for the 286 somehow being a serious 68K competitor from an architecture standpoint, that is pure malarky. It does have an on-chip mmu, which is attractive from the chip-count viewpoint, but the 286 running in real 286 mode is harder to deal with than the 8086 from an addressing viewpoint. Face it - the *86 is a 64Kbyte segmented machine with all the liabilities which come with such an architecture, while the 68K is a flat-address space machine with 8 more address bits where they count - in instructions, not MMU registers! The address reach on the 68K is maximal and uniform. On the 286, it is disjoing and minimal. In the particular case of C, Large, Flat, and Uniform is Beautify - segmentation is pure death. Finally, the First Virtual Truth of Marketing states that: "If they are buying it, it must be good." A diehard fan of the 8086, -Mike O'Dell PS - the split register set in the 68K doesn't win any awards from code generator writers, either.
oz@yetti.UUCP (Ozan Yigit) (04/29/85)
In article <2114@seismo.UUCP> mo@seismo.UUCP (Mike O'Dell) writes: >But as for the 8086, 8186 and 8286, THEY ARE ALL POORLY-DESIGNED >16-BIT MINICOMPUTERS WITH PRETENTIOUS INDEX REGISTERS,... Absolutely..It is an abomination, but, we are stuck with it, due to much marketing hype. >the IBM System 370, but in reality much worse because of the paucity of >registers available for doing anything. Uh-huh.. No wonder IBM owns part of INTEL.. They stick to their previous mistakes.. >.................................... In the particular case of C, >Large, Flat, and Uniform is Beautify - segmentation is pure death. Worst, this is how market is cheated. *OH BUT 8086 CAN HANDLE LARGE PROGRAMS* .. so can 11/23.. Just use OVERLAYS !!!!!!! > >Finally, the First Virtual Truth of Marketing states that: >"If they are buying it, it must be good." Sigh.. Oz (wizard of something or another, no doubt..) [decvax|ihnp4|allegra|linus]!utzoo!yetti!oz -------------- If more than one person is responsible for a miscalculation, no one will be at fault.
bentley@aicchi.UUCP (Bentley) (04/29/85)
I'll attest to that! We converted SCICARDS to run on a dedicated 68000. (WE, meaning WE at SC when I was working there; I'm now working for AIC). SCICARDS[tm SC] is a five megabyte module that likes to envelope a good portion of a 68000's address space, and it prefers to have a couple meg of physical memory to do it. Dont ask how we did the memory management, but we did have two 68Ks... it was technically impossible to downport the source code to any Intel architecture. We did do a study some time ago where we took a small (1 Megabyte) program (in FORTRAN), trimmed it with BIG shears, and stuffed it into a standard Intel development system. For various reasons, both software and hardware, it was no go. The 286 is a relatively recent development with, so far, an unstable beginning (my view of the PC AT). It may be that the 286 is faster than a 68000 -- for small programs. I'd like to SEE a big program run on a 286. Meanwhile, the guys who make popular 68000-based machines in this country (read: Apple) think 512K is a tremendous amount of memory for the mere user. HAR HAR HAR. It now costs 200 dollars for 1 MEGABYTE of RAM, 150 ns, parity checked (even!). For a machine that costs 3200 dollars (list?), 100 dollars isn't much to spend on the main memory...!!! I'm using 5 dollars per 256K/1 dynamic ram prices that are floating around. Other prices (at Dayton Hamfest) were 5.50 and 6.00...one guy was actually trying to get 12.00 for his...they must be GOOD. mike bentley (ihnp4!aicchi!bentley)