M680*0 "small model"

[Jim Hanko]

     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.