Category : Recently Uploaded Files
Archive   : DOORUTIL.ZIP
Filename : MEMMODEL.TXT

 
Output of file : MEMMODEL.TXT contained in archive : DOORUTIL.ZIP
Tricks that DOORS Play with Memory.


First, it is important to understand the difference between memory models on
the 80x86 processors. Since registers on the 8086/8088 processors are only
16 bits wide, including the Instruction Pointer register, there is an address
limitation of 64 Kbytes (2^16). To overcome this limitation, Intel uses 4
special registers called SEGMENT registers to augment addressing. Each
segment register defines a BASE ADDRESS, with a resolution of 16 bytes.
Each register, including the INSTRUCTION POINTER, provides an offset from
that base address, from which the instruction or data is retrieved. In actual
practice, the segment is loaded as bits 4-19 of the 20-bit address, with
bits 0-3 set to 0, then the offset is added to it, like this :

Segment register x x x x x x x x x x x x x x x x 0 0 0 0
Offset x x x x x x x x x x x x x x x x +
---------------------------------------
Actual address x x x x x x x x x x x x x x x x x x x x

There are 4 segment registers. They are :
CS - Code segment register. Normally combined with the IP to fetch the
next executable instruction.
DS - Data segment. Normally used to access memory. Most instructions
that manipulate memory in any way use the DS register by default.
SS - Stack segment. All operations concerning the Stack Pointer and
Base Pointer use SS by default.
ES - Extra Segment. This register is useful as an extra segment register.
It is often used in conjunction with the DS register when moving
data between segments.

Since the segment register identifies base addresses on a 16-byte (paragraph)
boundary, and there are 64K possible values for the segment registers, we
may address up to 1024K (64K * 16) or 1 Megabyte with the 8086/8088
processor, as well as a 80286/80386/80486 operating in REAL mode.

Why do we need to know this low-level esoterica? Because compilers and
assemblers for the 80x86 family of processors use these segment registers
differently, based on the Memory Model chosen for the program.

A SMALL memory model program will allow 64K data and stack, plus 64K code.
It sets the CS, DS, and SS registers to point to the beginning of
each of these memory regions, and does not change them while the program
is running. Memory accesses are performed using 16-bit arithmetic for
the addressing. Only the IP is pushed onto the stack for a subroutine call,
and all pointers require only a 16-bit offset to identify the datum to which
they refer.

A LARGE memory model program may have both code and data segments larger
than 64K. In this case, memory accesses must specifically load the segment
registers with the paragraph address of the datum to be accessed, since the
datum may be in a different 64K segment. Pointers must contain both the
16-bit offset, and the 16-bit base address (segment) to identify their datum.
Subroutine calls must push both the IP and the CS onto the stack, and the
CS and IP are both replaced by the 32-bit address of the target.

Medium and Compact memory models are variants of these basic types, allowing
either code or data segments to be larger than 64K. We will not concern
ourselves with these models.

The above discussion is important for Falken Door authors, because Falken
passes some information to doors as POINTERS. To be specific, Falken passes
Large Model pointers (called FAR pointers) which contain both the 16-bit
offset of data and the 16-bit segment address of the data. If you write
programs in the SMALL memory model, there may be problems because of the
different pointer sizes.

An example is the copying of the users name to a local string. Falken
passes the address of an array of structures, each of these structures
contains one account record for the configured ports. Falken also tells
you which port YOUR user is on. I use the variable 'who' to identify the
port I am running for, and the pointer 'acct' to point to the address of
account record structures. To copy the users name into a local string
called 'name', you might code a line like this :

strcpy(name, (*acct)[who].acctname);

The (*acct)[who].acctname might be confusing. Why didn't I use the pointer
notation : 'acct[who]->acctname' ? very simple - it won't work. The
syntax 'acct[who]' is used to identify an entry in an array of pointers, not
a pointer to an array. The (*acct) provides the base address of the array
of structures. From there, I must index into the array by 'who' entries.
The resulting address { (*acct)[who] } is not a pointer to a structure, but
is the actual ADDRESS of the structure I am accessing, therefore, I use the
direct access method (.) vs. the indirect access method (->) to reference a
member of the structure.

The example instruction above should work normally. If you have written your
program in SMALL model, though, it will not. The problem is that the strcpy
function in the small model library cannot accept a far address for one of
it's arguments. The instruction will appear to work, but in fact will only
use the offset of the account records structure, and index from YOUR DS
register. The result will be corruption of your program, or possibly, of
someone elses program. System lockups will surely result.

If you built your program with LARGE model, there would be no problem, since
the strcpy function in the large model library will accept 32-bit addresses
for both arguments.

So, how do you copy the account name if you have a small model program?
The best way is to write your own copy routine. Like this :

far_strcpy(char far *dest, char far *src)
{
while(*dest++ = *src++);
}

When you call the far_strcpy() function, cast both arguments as (far char *)
to make sure both pointers get passed as 32-bit pointers, like this :
far_strcpy((char far *)name, (char far *)(*acct)[who].acctname);

DO NOT IMPLEMENT FAR_STRCPY AS A MACRO!!!!!

It is quite possible, and easy, to write small model programs as Falken
Doors. You must use great care to assure that any data gotten via the
pointers Falken passes to your program is retrieved as FAR data.



  3 Responses to “Category : Recently Uploaded Files
Archive   : DOORUTIL.ZIP
Filename : MEMMODEL.TXT

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/