🚀 go-pugleaf

>>The National 32032, 32332, and the Motorola 680XX both have a much better 
>>instuction set than the Intel 8086, 186, 286, and 386. This may not be
>>as noticible at the machine code level, but when in compiled codes, especialy
>>'C', the National and Motorola instrucitons sets are much more efficient.
> Executable file sizes, 6502 assembler program:
> Intel, 8086, Microsoft C 3.0 -> 15110
> Motorola 68000, UniSoft cc   -> 19500
> This is more efficient?

    I have had occasion to compile 4.2 BSD system code for both 80286
and 32032, under comparable execution conditions, meaning that both 
compilers generated 32-bit pointers and 32-bit int's (not 16-bit pointers
and 16-bit int's as with some 80286 compilers).  The 32032 code was
about the same size as the VAX code.  The 80286 code was about 70
per cent larger.  Some of the difference was due to slightly less
sophisticated optimization in the 80286 compiler, but there was no
reasonable way to get the 80286 code to be less than 50 per cent
larger than the 32032 code, given comparable levels of optimization.
The main problems on the 80286 were the small number of pointer
registers (2) and the lack of built-in 32-bit arithmetic.  The 80386
is much better than the 80286, in 80386 "flat" model (32-bit registers,
32-bit addresses, no segmentation), but 80386 flat model is essentially
incompatible with 8086 and 80286 compilers.  

    Some people seem to like the intellectual challenge of fitting
complex programs onto inadequate hardware, such as the 80286, but
doing so is not likely to be cost-effective, except for mass-market
products such Lotus.  (By complex, I mean programs which require
several megabytes of memory to execute.)

	William J. Earl
	American Information Technology, Cupertino, CA
	408-252-8713
	...!decwrl!nsc!voder!lewey!wje


-- 
	William J. Earl
	American Information Technology, Cupertino, CA
	408-252-8713
	...!decwrl!nsc!voder!lewey!wje