Memory Models

Clyde Smith-Stubbs clyde at hitech.ht.oz
Sun Aug 13 21:46:12 AEST 1989


>From article <5653 at ficc.uu.net>, by peter at ficc.uu.net (Peter da Silva):
> In article <10703 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>> That is not a C language issue.  It's kludgery introduced specifically
>> in the IBM PC environment.
> 
> Emphatically agree.

It IS a language issue - you could argue that near and far address spaces
are not part of the Standard C, therefore it is not a C issue, however
there are sufficient architectures that REQUIRE a useful language  to
permit specification of more than one memory space that it is
a language issue. the 8086/286 may be the best known example of an
architecture that requires far and near address spaces, but it is not
the only one. Others are:
	8051 (on chip vs off chip RAM)
	6801/HC11 (basepage memory)
	64180 (banked code memory)
	65816 (banked code and data)
	8096 (on chip memory)
	Z8000 (another segmented architecture)

I have implemented C compilers for the first five of the above (plus the
8086/286). In doing so I devised a machine independent model for the
semantics of far, near and differing memory models. Such a model allows
code to be written which is both efficient for strange architectures like
the 8051 AND portable.

>> Unless you have a strong reason not to,
>> just always use the large memory model.
> 
> Disagree. Always use the smallest model you can get away with, but if
> the program won't work under a small model don't play games with
> NEAR and FAR pointers... just go to a larger model. You will thank
> yourself later when you get a real computer.

Generally speaking a small model would mean economy of addressing,
and therefore smaller and faster code. If a large address space is not
required then the small model should be used. Where only a limited
set of data structures need to be in far memory then far pointers can
be used to advantage PROVIDING a) you program within the bounds of
a portable model as described above AND b) the compiler is gracious
enough to issue decent warnings (e.g. converting a far pointer to a non-far
pointer). Without these precautions you can easily get into big trouble.

> 
> After all, all of UNIX ran in small model once upon a time :->.

UCB and the VAX have a lot to answer for :-)
----
-- 
Clyde Smith-Stubbs
HI-TECH Software, P.O. Box 103, ALDERLEY, QLD, 4051, AUSTRALIA.
INTERNET:	clyde at hitech.ht.oz.au		PHONE:	+61 7 300 5011
UUCP:		uunet!hitech.ht.oz.au!clyde	FAX:	+61 7 300 5246



More information about the Comp.lang.c mailing list