From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jody" Subject: Re: Future of ELKS Date: Fri, 21 May 2004 14:38:59 -0400 Sender: linux-8086-owner@vger.kernel.org Message-ID: <00a901c43f62$e18bb1b0$0101a8c0@vash> References: <1084985870.3062.23.camel@talena.hsol.net> <40AD4286.1090801@cowlark.com> <20040521132425.GP24490@duckman.distro.conectiva> <200405211730.45239.dg@cowlark.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: Linux-8086 *snip* > On Friday 21 May 2004 15:15, Jody wrote: > [...] > > The 8086/88's biggest limitation has to be the segmented memory model to > > retain compatibility with some old CPU (8085?) and these compatibility > > efforts have hindered Intel CPUs for a long time... > > Segmentation is also what makes ELKS work at all on the 8086. It acts as a > poor-man's MMU. Without segmentation, you wouldn't be able to have > relocatable processes; you wouldn't be able to do any kind of swapping or > move code around at run time. > > (Remember that a 64/64 process is using 16-bit points for everything. It never > touches its segment registers. If you copy the process onto disk, reload it > elsewhere, restore its registers but make sure that the segment registers > point to its new location in memory, it'll never even notice.) > > Yes, we *could* use some kind of larger memory model with bigger pointers, but > I wouldn't recommend it. Using multiple segments makes stuff far more > complicated --- particularly as ints and pointers will now be different sizes > --- and any 8086 program that needs more than 128kB is probably too big > anyway. Disclaimer: I don't know a ton about low-level 8086 programming, only pieces, please correct me if I am wrong as it will benefit myself as well as the community. I was trying to hint that we should try to use less than 64KB per process in another unquoted snippet...I don't know everything about 8086's but I do know that there are PLENTY of operating systems from the past that have done "a lot of stuff" in what we now see as a miniscule space. I've seen a program in less than 256 bytes (1 page in 6502 memory space) of 6502 asm that would do a dual-algorithm decompression of the data it was attached to. I myself wrote an RLE decompressor to be attached to a BASIC program that took up 110 bytes of code and about six bytes of data. It's not 8086-related per se, but it does show that it can very well be done. Also, remember that good old DOS ran on PCs with 256KB of RAM or *less* sometimes, and still did a lot of useful things. Eventually, even when DOS was rewritten in C (MS-DOS 3.0?) it STILL ran on ancient and "modern" configurations. Anyone who thinks we should eat one or two entire segments for a program like cp, mv, rm, mkdir, or kill, is in my opinion self-limiting to the segmentation of the architecture. Please "think outside the box" on this. If we write a good memory manager and programs honor the allocations of that memory manager, there is no reason we can't break processes down into smaller pages. A relocatable executable format rather than dependency on segments to do everything for us would probably help. > If you think 128kB of RAM is too small to do anything useful, I strongly urge > you to go out and look into CP/M. Your average CP/M system had about 60kB > free for user applications, shared between code and data. 8080 and Z80 code > is significantly more verbose than 8086 code. But look at all those > applications... I certainly believe that 128KB is more than enough for a lot of things, and that we're so used to inherent code bloat in both Linux and Windows that we don't remember the "old ways" of coding sometimes...it's all about squeezing that last 64 bytes, no? What can I do in 64 bytes? With my favorite CPU (6502) I can write a routine that'll clear the entire contents of the C64's 320x200x1-bit screen so it can be used for something, like a GUI. I can write something that will act as a supplementary buffer for my serial port. I can store a small icon (say a 2-bit color 16x16 icon for a CGA screen) for my simple GUI...why use 64KB per process when we're already so limited and you don't need all that? Simplified versions of stuff like cp and mv could take only a few kilobytes at most if written strategically. I'm too lazy to type more, please respond to my comments ASAP so hopefully I get them before work. Everyone take care, and good hacking! Jody