From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Olson Subject: Re: EDE - Personal Suggestions and Ideas Date: Fri, 28 May 2004 22:28:34 -0700 (PDT) Sender: linux-8086-owner@vger.kernel.org Message-ID: <20040528221920.T35665@agora.rdrop.com> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <200405281111.50735.dg@cowlark.com> <40B72146.4080202@i.com.ua> <200405281314.49031.dg@cowlark.com> Mime-Version: 1.0 Return-path: In-Reply-To: <200405281314.49031.dg@cowlark.com> List-Id: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-8086@vger.kernel.org > Think instead of traditional Unix segments. The 8086 is a 16-bit processor, > which means each process can address 64kB of memory. Full stop. We don't even > want to *try* to make it address more, it's just too complicated. However... > which 64kB is being accessed depends on what the processor is doing at the > moment (accessing code, data, the stack, or 'other'). That's very easy to > support and allows considerable flexibility later. I agree 100%, I keep seeing what look like very complicated ways to allow large processes to run under ELKS, while I can't claim to be an ELKS programmer, I tend to think that we are better off just keeping things simple and small. > So, if a process wants, it can allocate up to 256kB of memory. If it does, it > needs to be specially written --- probably not in C --- but it can be done. That's a good sized chunk of memory, if you concider that the OS and other background stuff will be using memory too, about have of the memory on a 640k machine will be used once this one large process is run. This also make it possible to allow C without special concideration, and without giving up the multiple segment feature that the 8086 allows. > Except that in our case, pointers are always 16 bits. The compiler neither > knows nor cares about segments. As far as it is concerned, it's using a flat, > linear 16-bit address space with memory protection (even though on anything > below a 286 there isn't any actual memory protection). Very true too, I think the best we can do it to just assume that the memory is protected, as we can't stop someone who really wants to write a program to modify another process's memory, or prevent misbehaved programs. If that's a feature that's needed, the 8086/8088 is a poor choice (without a MMU). Dan