Date:	Sun, 16 Apr 2000 10:20:55 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
cc:	djgpp AT delorie DOT com
Subject:	Re: Help with Inline ASM...
In-Reply-To:	<38F747E2.7793F51B@mtu-net.ru>
Message-ID:	<Pine.SUN.3.91.1000416101756.2482U@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Fri, 14 Apr 2000, Alexei A. Frounze wrote:

> Please read all the following text until its end. Then reply.

I thought I always did that, no need to remind me.

> You're right, we can not modify segment marked as executable/read. But since
> data segment is mapped on the code segment as well, you may modify it just
> uding the DS selector.

Yes, this is done on purpose, so that interrupt and exception handlers
could access crucial variables safely (since only CS is known to be
valid in an interrupt or exception handler).  The DJGPP library actually
uses this to provide several important features, like signals and FP
emulation.

> > Btw, DJGPP doesn't use a flat memory model at all.
>
> Wait a minute. Some string constants are stored to the code segment by GCC. And
> they are accessible in data segment as well, since data segment is mapped onto
> the code segment too.
> 
> Or do you mean, that EXE files contain all the relocation entries? 
> If so, why I see in each EXE only the following:
> 
> 1. COFF header
> 2. optional COFF header (for already linked programs)
> 3. .text section (w/o relocation entries)
> 4. .data section (w/o relocation entries)
> 5. .bss section (w/o relocation entries)
> 6. string table
> 7. symbol table
> 
> According to the sections, the .data section starts just after the .text section
> and the .bss esctions starts just after the .data section. 
> 
> So, it's a true flat memory model

We seem to use two very different definitions of what ``flat memory
model'' is.

According to my definition, the flat model is when any linear address
can be accessed without reloading the segment registers.  DJGPP
doesn't allow this (for example, you need _dos_ds to access the
conventional memory), so its memory model is not flat.

Under that definition, flat model has nothing to do with how sections
are mapped.

This all was discussed to death in a thread that I mentioned in my
message.  I suggest to find it in the DJGPP archives and read it.

> The only problem might be that code segment pages are marked as read-only. But
> since sections are not always 4KB aligned and their sizes are not in 4KB blocks,
> I can tell you that there is no page level protection for writing.

Page-level protection is not supported by most DPMI servers, so DJGPP
cannot use it.

But that has nothing to do with flat memory model.

- Raw text -