From: pausch AT merope DOT saaf DOT se (Paul Schlyter)
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp
Subject: Re: Just a few questions
Date: 24 Oct 1999 09:20:51 +0200
Organization: Svensk Amat|rAstronomisk F|rening (SAAF)
Lines: 61
Message-ID: <7uuc0j$ed7$1@merope.saaf.se>
References: <7up2m7$pvc$1 AT ctb-nnrp2 DOT saix DOT net> <85cQ3.632$pD5 DOT 45821 AT dfiatx1-snr1 DOT gtei DOT net> <3812a5c7 DOT 3453113 AT newsserver DOT cc DOT monash DOT edu DOT au>
NNTP-Posting-Host: merope.saaf.se
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In article <3812a5c7 DOT 3453113 AT newsserver DOT cc DOT monash DOT edu DOT au>,
Davin McCall <DavMac AT iname DOT com> wrote:
>On Sat, 23 Oct 1999 05:55:16 GMT, "Damian Yerrick"
><web DOT poison AT pineight DOT 8m DOT com> wrote:
>
>>> And then, since I'm used to 16bit programming, is
>>> there any other important facts I should know about,
>>> that is important in 32bit programming?  I do know
>>> in 32bit programming the memory is a flat model,
>>
>>True. Technically, it would be called a "tiny" model.
>
>Eh? It would be called the "flat" model. "tiny" model refers to data
>and text being together in the same 64KB 16-bit segment. It's called
>"tiny" only because of the limit on the total program size.

"tiny" refers to data + text residing in the same segment.

>DJGPP does not impose that limit.

Well, it does: DJGPP, as well as all other 32-bit compilers for x86,
put data and text in the same 32-bit segment.  This will make
available memory tiny, compared to what could be obtained if multiple
32-bit segments were used.  Through virtual-memory mechanisms,
the 386 (and later) is capable of addressing up to 8192 different
32-bit segments of 4 GB each -- that's a total of 32 TB memory!

Right now, 4 GB may appear enough -- just like 64 KB appeared enough
some 20 years ago.  But soon enough, people will start complaining
over that "horrible 4 GB-limit".  Yes, history will repeat itself
here....

>
>>> and there is no segments (except for the 4GB
>>> segments) like there is in 16bit programming.
>>
>>There are still segments in DPMI programming if you
>>want to access memory outside your program's private
>>area, e.g. video RAM or the First Meg.
>
>That's right. There are still segments. You don't have to deal with
>them, except in cited circumstances (even then, you can avoid them by
>using the "nearptr hack" but most people recommend you don't do this).

That's the big advantage of all "tiny" memory models, 16-bit as well
as 32-bit: all segment registers are set to the same values at the
beginning of execution, and then you won't have to worry about
segments, but can pretend the memory addressing is linear.
The 32-bit tiny memory model is in this respect no different from
the 16-bit tiny memory model.  Of course, 32-bit programmers who
want to sneer at 16-bit programming don't like having their
memory model named "tiny", so instead they call it "flat".  But
that's just a rethorical trick.


-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch AT saaf DOT se    paul DOT schlyter AT ausys DOT se   paul AT inorbit DOT com
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch