From: DavMac AT iname DOT com (Davin McCall)
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp
Subject: Re: Just a few questions
Date: Mon, 25 Oct 1999 03:35:56 GMT
Organization: Monash Uni
Lines: 73
Distribution: world
Message-ID: <3813cd8d.15570356@newsserver.cc.monash.edu.au>
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> <7uuc0j$ed7$1 AT merope DOT saaf DOT se>
NNTP-Posting-Host: damcc5.halls.monash.edu.au
X-Trace: towncrier.cc.monash.edu.au 940822531 22582 130.194.198.138 (25 Oct 1999 03:35:31 GMT)
X-Complaints-To: abuse AT monash DOT edu DOT au
NNTP-Posting-Date: 25 Oct 1999 03:35:31 GMT
X-Newsreader: Forte Free Agent 1.1/32.230
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On 24 Oct 1999 09:20:51 +0200, pausch AT merope DOT saaf DOT se (Paul Schlyter)
wrote:

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

Yes, and the total code+data size limit is the reason why that memory
model is called "tiny". [it also refers to 16-bit programs].

>>DJGPP does not impose that limit.
>
>Well, it does: DJGPP, as well as all other 32-bit compilers for x86,
[etc]

It imposes a *different* limit. A much bigger limit. Granted, it's
caused by the same thing.

>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.

Yes, that's right - but it's not tiny compared to 64KB. It's not even
tiny compared to 1MB, which is more than "huge" model memory programs
used to be able to access directly.

>  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....

This argument sounds awfully like "We will consider the limit to be
'tiny' in the future, so we'll call it tiny now".

>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 point is, with what you call the 16-bit tiny memory model, the
amount of memory you can address is severely limited.

>The 32-bit tiny memory model is in this respect no different from
>the 16-bit tiny memory model.

That's true.

>  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.

I don't want to sneer at 16-bit programming.

Your points about the tiny model and flat model being essentially the
same thing are correct, but I still maintain that the 16-bit version
is called "tiny" and the 32-bit version is called "flat". This
division is somewhat arbitrary, that I'll grant, but there are reasons
for it. It will only serve to confuse by calling the "flat" model
"tiny".

I for one would feel much less concerned if you wanted to call the
tiny model "flat". To call the flat model "tiny", at this point in
time, seems rather unnatural.

Davin.


__________________________________________________________
       *** davmac - sharkin'!! davmac AT iname DOT com ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/