Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (JAMES ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Zortech "limitation"
Message-ID: <51064@microsoft.UUCP>
Date: 26 Feb 90 19:57:29 GMT
References: <48aa63d6.20b6d@apollo.HP.COM> <2337@dataio.Data-IO.COM>
Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 59

>	To achieve portability you must code to the common denominator between
>	all the platforms. Note that I don't know of any reasonable method
>	to implement on the 8086 things like:
>		func()
>		{	char array[70000];
>			...
>		}
>	The 8086 hardware simply doesn't support it.

[standard disclaimer on]

I disagree with this last statement.  8086 hardware *does* support such
a construct.  Rather, it is 8086 compilers that typically don't support
putting a 70K allocation on the stack.  Many 8086 compilers *do* support
70K+ sized objects allocated statically, or from heap.  [I would claim 
putting a 70K allocation on stack is not a good thing to do in any case,
on any machine.  Many [most?] machines/compilers/linkers will have problems
with such an approach, since default stack allocations are much smaller 
than this.]  Even on 32-bit machines it is not too uncommon to run into
16-bit restrictions from their compilers -- such as maybe allowing huge
arrays, but restricting structures to less that 64K.  The *optionally*
segmented architecture of the 80x86 family allows compiler writers many
choices trading off memory models verses code size/complexity.  The most
important memory models are [informally]:

memory model	 code size	data size

small		16		16
large		32		16+16
huge		32		16+32
flat		32		32

where 16+32 means using a 32-bit offset from a 16-bit base address.
The 16-bit base offset is multiplied by some number, typically 8 or
4096, to allow the 16-bit base address to span a range of bytes
greater than 2^16.

An interesting characteristic of the 80x86 family is that the chips can
be put into a mode where they *either* efficiently run code using 8/16
bit data sizes *or* they can be put in a mode where they efficiently
run code using 8/32 bit data sizes.  In 8/16 bit mode 32bit sized data
requires an extra byte in the machine code.  In 8/32 bit mode 16bit sized
data requires an extra byte in the machine code.  Thus, IMHO, *either* small
or flat models generate particularly pleasing machine code.  You need at
least a 386sx to run flat model, but predecessors are all capable of
running small, large, and huge.

IMHO, small model is adequate for learning C++ code.  IMHO, flat model
is the way to go for serious OOP projects.  Flat model is essentially
identical to the memory model used by most 32-bit Un*x machines,  which
should help portability.  Put 70K+ sized objects on a 368 stack if you
insist -- the architecture supports good automatic growing of the stack.
But you'll probably have problems with lots of other machines.

Like I said before, IMHO, if you're buying a new PC, get at least a 386sx.
[But then again, if doing C++ development, you probably want the fastest
 machine you can get your hands on :-]

[standard disclaimer off]