martyl@rocksvax.UUCP (10/02/87)
I'm trying to get a protected mode implementation of Minix running. Programs using split I & D (max 64K code, 64K max combined data/bss/stack) require a code segment (execute only), a data segment and a stack segment. Using 16 bit pointers on a 286 requires the data segment to include the stack segment. It therefore seems necessary to always allocate 64k of data to a process whether it needs it or not. The stack begins (I believe) at 0xffff and extends downward to a segment limit (stack access below the limit will cause protection exceptions). The data segment would have to end at 0xffff to include the stack. Writes on top of the stack by an errant process would not be detected at the time of fault. Presumably the process would go errant some other way later. I'm toying with the idea of setting the initial stack pointer to a process to be something less than 0xffff. For example, if a program needs 16k of data and bss and 16k of stack, the data segment size would be 32K and the stack limit would be at 16k, with the initial stack pointer being at 32k. The only problem is if this program begins to execute: label: pop ax jmp short label for some brain-damaged reason. I don't see a way the hardware is going to generate an exception until the stackpointer reaches 0xffff -- which is 32k beyond the limit of our initial stack segment and probably in the address space of some other process. 32 bit pointers solve the problem, since the stack is not part of the data segment. But it injects other problems (like loading), which I don't want to handle off the bat. It seems I need to allocate 64K to all data segments where the stack is aliased on top of the data segment. This isn't a big problem once I start to hang Megabytes of ram on my 286. Any comments to confirm/deny my intuition in this issue. Any other ideas? Thanks -- marty leisner xerox corp. ARPA: leisner.henr@xerox.com UUCP: martyl@rocksvax.uucp -- marty leisner xerox corp leisner.henr@xerox.com martyl@rocksvax.uucp
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/06/87)
In article <93@rocksvax.UUCP> martyl@rocksvax.UUCP (Marty Leisner) writes: >I'm trying to get a protected mode implementation of Minix running. > >Programs using split I & D (max 64K code, 64K max combined data/bss/stack) >require a code segment (execute only), a data segment and a stack segment. >Using 16 bit pointers on a 286 requires the data segment to include the >stack segment. Actually, a rather nice way to implement this type of process is to duplicate the stack segment pointer in 'ES'. Then you allocate three segments, Code, Data, Stack. With stack growing negatively and the heap growing positively from the bottom. You will have to generate segement exceptions now and then to get stuff from ES:address rather than DS:address. >I don't see a way the hardware is going to generate an exception until the >stackpointer reaches 0xffff -- which is 32k beyond the limit of our initial >stack segment and probably in the address space of some other process. When you specify the size of the segment the '286 will trap any access outside that size. If you are sharing segments with different processes (not likely unless your forking) then you have a problem with your address space. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kds@mipos3.intel.com (Ken Shoemaker) (10/12/87)
well, maybe I'm dense, but I don't quite understand the problem. There is no
reason why you couldn't just put the stack and data in the same segment with
the same attributes. Thus, if you pop off the top of the segment, you will
get a segment limit violation. Note that this doesn't use the grow down
segment type for the stack. The real problem is if you can't determine
the maximum size of the stack, then you have the possibility of your stack
growing into your data. An option to take care of this is to put the stack
below the data, so that if the stack tries to grow too large you get a
segment violation. Of course, if you try to pop too much, then you start
using your data area as your stack, and strange things can happen, but aren't
these usually program bugs? At least, in either case, you will stay within
your limits, because if you don't you will get a trap.
Also, I don't really think that using 32-bit segments will solve your problems
if both your data and stack can fit within the same 16-bit segment, which is
what you want to do, since you want to allocate even less than 64k for the
segment. The thing that the 386 provides you here is that you can seperate
your stack and heap by lots of empty space in virtual memory using the
page hardware to use a minimum of physical memory but allowing for simple
grows of the stack or heap, and to cause traps if either get too close to
each other.
--
The above views are personal.
its another of those basic things you're never taught at school...
Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds
csnet/arpanet: kds@mipos3hourlls ta