hanko@mot.UUCP (Jim Hanko) (06/12/85)
In the endless debate over the relative performance of various micros,
much discussion centers around whether "small model" 80*86 code can outperform
M680*0 code developed for 24+ bit addresses and 32 bit integers (a
"huge model"). In fact, Intel has recently been running a glossy ad which
is implicitly based on this type of comparison. Overlooked in the debate,
however, is the fact that the M680*0 has a logically consistent subset of
addressing modes and operations which constitute a "small model".
The features of the M680*0 small model are:
32k program - logical addresses 0 to 7fff
- absolute short & PC-relative addressing modes
32k stack&data - logical addresses f...f8000 to f...fffff
- absolute short addressing mode
16 bit integers - full set of word operations
16 bit pointers - the CPU sign-extends word addresses to 32 bits
This M680*0 small model is fully self-consistent (including sizeof(int)
being equal to sizeof(int *)), is easy to implement, and is capable of
supporting virtually all published benchmarks that work with the 80*86 small
model. M680*0 small model code is significantly smaller and faster than
M680*0 huge model code (eg. absolute addressing takes two fewer bytes and
eight fewer cycles on the M68000).
The M680*0 small model is not generally supported in M680*0 systems
and compilers for the following resons:
1. Small models are not as generally applicable as huge models.
2. The M680*0 huge model is also relatively easy to implement.
3. The M680*0 huge model takes a relatively small performance
'hit' (compared to other common architectures :-)
4. Supporting multiple models requires extra compiler code and
redundant libraries.
Perhaps, if the small model is as good an idea as Intel claims, more
M680*0 systems should support it.
The bottom line in performance measurement is, therefore, not whether
a small model 80*86 can or cannot beat a huge model M680*0, but which
small model and which huge model outperforms the other.
From now on, let's compare apples to apples.
================================
Jim Hanko, UNIX group, Motorola Microsystems, Tempe, AZ U.S.A
{seismo | ihnp4 } ! ut-sally ! oakhill ! mot ! hanko
================================
Disclaimer: the opinions expressed here are my own, but anyone may adopt them.steve@anasazi.UUCP (Steve Villee) (06/18/85)
> > In the endless debate over the relative performance of various micros, > much discussion centers around whether "small model" 80*86 code can outperform > M680*0 code developed for 24+ bit addresses and 32 bit integers (a > "huge model"). In fact, Intel has recently been running a glossy ad which > is implicitly based on this type of comparison. Overlooked in the debate, > however, is the fact that the M680*0 has a logically consistent subset of > addressing modes and operations which constitute a "small model". > > From now on, let's compare apples to apples. > > > ================================ > Jim Hanko, UNIX group, Motorola Microsystems, Tempe, AZ U.S.A > {seismo | ihnp4 } ! ut-sally ! oakhill ! mot ! hanko > ================================ > Disclaimer: the opinions expressed here are my own, but anyone may adopt them. I don't think it's quite fair to compare this "small model" with the small model provided by the Intel 8086 or 8088. If your 68000 system has an MMU, it might be almost reasonable, but even there, many OS's are not set up to let user programs address the range ffff8000 to ffffffff. So it might well be that all code and data would have to fit in the first 32K. In any case, this 68000 "small model" does not readily upgrade to something analogous to the Intel medium model (separate code and data, with 64K for each). The real problem is if your 68000 system does not have an MMU. This is the case with the Macintosh, Jackintosh, Amiga, etc. that are in the same price league with the IBM PC and clones. In this case, you are limited to one "small model" process running at once, and it is very unlikely that the range ffff8000 to ffffffff is available. You also have to watch out for the interrupt vectors. Don't get me wrong. I'm no fan of the 8086 architecture. But at least things like PC/IX are possible on an 8086 system without an MMU, with lots of small model processes running that the OS can switch between easily. While there is no rigid memory protection, it's pretty tough to step on other processes accidentally. You have go into assembly language and muck with the ES or something. A fairer "small model" for the 68000 would use (Am,Dn.W) addressing modes, with the 16-bit pointer in Dn and some kind of base address in Am. This would provide closer to the same capability that Intel small model provides. But of course this would be slower than the large model! --- Steve Villee (asuvax!anasazi!steve) International Anasazi, Inc. 2219 East University Drive Phoenix, Arizona 85034 (602) 275-0302
jer@peora.UUCP (J. Eric Roskos) (06/24/85)
> If your 68000 system has an MMU, it might be almost reasonable, but even > there, many OS's are not set up to let user programs address the range > ffff8000 to ffffffff. I get the feeling this statement is based on ONE operating system, the OS for the Apple Macintosh. One of its major flaws is that certain types of program segments are limited to 32K. I believe, if I'm not mistaken, that this is because they used entirely PC-relative addressing in order to aid in code relocation. > Don't get me wrong. I'm no fan of the 8086 architecture. But at least > things like PC/IX are possible on an 8086 system without an MMU, > with lots of small model processes running that the OS can switch > between easily. Is it true that PC/IX uses this approach? It had been my understanding that PC/IX worked more or less like AT&T's "Mini-Unix*" for the PDP-11/03, where the old process was swapped out and the new one swapped in each time a new process was scheduled to run. Actually, that is one of the few places where the 8086's segmentation registers would seem particularly useful to me. Unfortunately, the unflagging demand for "large model" compilers on the part of IBM PC users more or less did away with the chance for that sort of thing. > A fairer "small model" for the 68000 would use (Am,Dn.W) addressing > modes, with the 16-bit pointer in Dn and some kind of base address > in Am. I think the Macintosh's OS does this for the data segment; i.e., data is all addressed off one base register. ---------- NOTE: followups to this article will go to net.arch, where they more properly belong. *Unix is a trademark of AT&T. -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Erny vfgf qba'g hfr Xbqnpuebzr."
mike@peregrine.UUCP (Mike Wexler) (06/25/85)
> Don't get me wrong. I'm no fan of the 8086 architecture. But at least > things like PC/IX are possible on an 8086 system without an MMU, > with lots of small model processes running that the OS can switch > between easily. While there is no rigid memory protection, it's > pretty tough to step on other processes accidentally. You have > go into assembly language and muck with the ES or something. How about this. On a Altos 586(and 8086 base micro) if you pass the compiler an unterminated string, it will cause the whole system to crash. I have done application development work on the 586 in C(not recommended) and it crashes quite often. I didn't not write one line of assembler. -- -------------------------------------------------------------------------------- Mike Wexler(trwrb!pertec!peregrine!mike) | Send all flames to: 15530 Rockfield, Building C | trwrb!pertec!peregrine!nobody Irvine, Ca 92718 | They will then be given the (714)855-3923 | consideration they are due.
hanko@mot.UUCP (Jim Hanko) (06/26/85)
> I don't think it's quite fair to compare this "small model" with > the small model provided by the Intel 8086 or 8088. ... > The real problem is if your 68000 system does not have an MMU. ... > In this case, you > are limited to one "small model" process running at once, and it is > very unlikely that the range ffff8000 to ffffffff is available. You > also have to watch out for the interrupt vectors. > A fairer "small model" for the 68000 would use (Am,Dn.W) addressing > modes, with the 16-bit pointer in Dn and some kind of base address > in Am. This would provide closer to the same capability that Intel > small model provides. But of course this would be slower than the > large model! > > --- Steve Villee (asuvax!anasazi!steve) > International Anasazi, Inc. Actually, one non-MMU M680*0 "small model" would involve using two A-registers as the base of the code and data segments. Then, the d(An) modes could be substituted for the absolute short modes. (Note: other formulations are possible, including pointing to the middle of the segments, allowing 64K program and 64K data). Note that this would not "be slower than the large model!", but would in fact cause the SAME SIZE AND SPEED code to be generated as my original M680*0 "small model", which required an MMU. The only loss it suffers is that two of the A registers would no longer be available for register variables (are they segment registers? :-). The (Am,Dn.W) modes you mentioned would be used, as in the original "small model", to index into arrays after their base is loaded into an A register. eg. a[i + 1] = c; /* i int; c char; a char array */ MMU small model: non-MMU small model: (absolute short modes) (assume A5 has base address of data) LEA.W a,A0 LEA.W a(A5),A0 MOVE.W i,D0 MOVE.W i(A5),D0 MOVE.B c,1(A0,D0.W) MOVE.B c(A5),1(A0,D0.W) Both implementations require 14 bytes and 43 cycles on an M68000. ================================ Jim Hanko, UNIX group, Motorola Microsystems, Tempe, AZ U.S.A {seismo | ihnp4 } ! ut-sally ! oakhill ! mot ! hanko ================================ Disclaimer: the opinions expressed here are my own, but anyone may adopt them.