Re: EDE - Personal Suggestions and Ideas

[David Given <dg@cowlark.com>]

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