From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: EDE - Personal Suggestions and Ideas Date: Fri, 28 May 2004 11:11:50 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200405281111.50735.dg@cowlark.com> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <40B6F3D7.7050009@codito.com> <20040528081028.GX15905@vega.vega.lgb.hu> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20040528081028.GX15905@vega.vega.lgb.hu> Content-Disposition: inline List-Id: Content-Type: text/plain; charset="iso-8859-1" To: linux-8086@vger.kernel.org On Friday 28 May 2004 09:10, G=E1bor L=E9n=E1rt 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 machin= e > 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 CP= U > runnable machine code. My only point is that we should generally spea= king > 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 yo= u can=20 take pointers to things on the stack. This means that the stack has to = live=20 in the data segment. However, the 8086 doesn't have to do this! You can put the stack in a=20 completely different segment, if you like. If you do, the only way of=20 accessing it is via stack-relative addressing modes, but the 8086 was=20 designed to make this easy. (If you've ever programmed on the Z80, whic= h=20 *wasn't* designed to make this easy, you'll realise just how nice=20 stack-relative addressing modes are.) Unfortunately, if you put the stack in another segment, you can't take=20 pointers to it from C. Imagine this code: void settozero(char* pointer) { *pointer =3D 0; } char global; void main() { char local; settozero(&local); settozero(&global); } As far as the settozero() function is concerned, it doesn't know whethe= r the=20 pointer argument should be accessed with DS or SS. But if you're not programming in C, you don't have this limitation. Uni= x=20 traditionally is programmed in C, so people don't think about this much= , but=20 it would be really nice if the kernel would manage all the segment regi= sters=20 and not just CS and DS. So that, if you like, you could load a binary t= hat=20 allocated all four segments. This would allow nice features such as a B= asic=20 interpreter that stored its byte-code in ES, its working stack in SS, a= nd=20 used DS for workspace. I haven't looked at the source, so I don't know how much extra work it = would=20 be, but I suspect it wouldn't be hard to extend the kernel to do this. = This=20 way the multi-segment people can be happy, plus we keep the clean desig= n of=20 the kernel (and avoid the hideousness of far pointers). --=20 +- 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 i= t | (dg@tao-group.com) | just fine." --- Ethan Benson +- www.cowlark.com --+=20 - To unsubscribe from this list: send the line "unsubscribe linux-8086" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html