Re: EDE - Personal Suggestions and Ideas

David Given
2004-05-28T10:11:50Z

On Friday 28 May 2004 09:10, Gábor Lénárt wrote:
[...]
> Wrong, because there is no such thing like 'C program' from the view point
> of the CPU. It runs machine code. It's ANOTHER thing that this machine
> code was produced by a C compiler/linker/etc, or it's 'hand coded' in
> assembly and was assembled by the assembler and/or linked/etc into CPU
> runnable machine code. My only point is that we should generally speaking
> that we have or have not this feature, and probably we should not use
> rules 'only C is allowed'.

One interesting consequence of dealing with C is that C insists that you can
take pointers to things on the stack. This means that the stack has to live
in the data segment.

However, the 8086 doesn't have to do this! You can put the stack in a
completely different segment, if you like. If you do, the only way of
accessing it is via stack-relative addressing modes, but the 8086 was
designed to make this easy. (If you've ever programmed on the Z80, which
*wasn't* designed to make this easy, you'll realise just how nice
stack-relative addressing modes are.)

Unfortunately, if you put the stack in another segment, you can't take
pointers to it from C. Imagine this code:

void settozero(char* pointer)
{
*pointer = 0;
}

char global;
void main()
{
char local;

settozero(&local);
settozero(&global);
}

As far as the settozero() function is concerned, it doesn't know whether the
pointer argument should be accessed with DS or SS.

But if you're not programming in C, you don't have this limitation. Unix
traditionally is programmed in C, so people don't think about this much, but
it would be really nice if the kernel would manage all the segment registers
and not just CS and DS. So that, if you like, you could load a binary that
allocated all four segments. This would allow nice features such as a Basic
interpreter that stored its byte-code in ES, its working stack in SS, and
used DS for workspace.

I haven't looked at the source, so I don't know how much extra work it would
be, but I suspect it wouldn't be hard to extend the kernel to do this. This
way the multi-segment people can be happy, plus we keep the clean design of
the kernel (and avoid the hideousness of far pointers).

--
+- David Given --McQ-+ "...you could wire up a *dead rat* to a DIMM
| dg@cowlark.com | socket, and the PC BIOS memory test would pass it
| (dg@tao-group.com) | just fine." --- Ethan Benson
+- www.cowlark.com --+
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html