Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!uunet!philmtl!ray
From: ray@philmtl.philips.ca (Raymond Dunn)
Newsgroups: comp.lang.c
Subject: Re: Memory Models
Message-ID: <664@philmtl.philips.ca>
Date: 23 Aug 89 20:24:30 GMT
References: <10744@smoke.BRL.MIL> <319@hitech.ht.oz>
Reply-To: ray@philmtl.philips.ca (Raymond Dunn)
Organization: Philips Electronics Ltd. -  St. Laurent  P.Q., Canada
Lines: 30

In article <319@hitech.ht.oz> clyde@hitech.ht.oz (Clyde Smith-Stubbs) writes:
>From article <10744@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
>> People who aren't "wedded" to the *86 architecture generally don't
>> seem to think it was necessary to cause memory models to be visible
>> in higher-level programming languages.
>
>There are probably more 80x86 processors out there than any other,
>and the 80x86 architecture has brought C and Unix within reach of  people
>who would not have access to it otherwise. That doesn't alter the fact that
>its memory organization is horrible, but it should be some incentive to
>devise rational, portable  techniques of managing address spaces that are
>not linear.

Hey, it's easy.  If you don't want to bother yourself with memory models,
then always use the large or huge models and forget about it.

All your code will then of course have to carry the overhead of data and
program pointers greater than 16 bits, just like it does on the processors of
wonderful design.

However if you want to take *advantage* of the fact that you can see a
significant improvement in code size and execution speed by using 16-bit
addresses when possible, then use the small and medium memory models.

(:-) * 0.5
-- 
Ray Dunn.                    | UUCP: ..!uunet!philmtl!ray
Philips Electronics Ltd.     | TEL : (514) 744-8200  Ext: 2347
600 Dr Frederik Philips Blvd | FAX : (514) 744-6455
St Laurent. Quebec.  H4M 2S9 | TLX : 05-824090