From mboxrd@z Thu Jan 1 00:00:00 1970 From: sandeep Subject: Re: EDE - Personal Suggestions and Ideas Date: Fri, 28 May 2004 13:39:59 +0530 Sender: linux-8086-owner@vger.kernel.org Message-ID: <40B6F3D7.7050009@codito.com> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <200405261517.47059.dg@cowlark.com> <20040526151030.GC15905@vega.vega.lgb.hu> <200405261749.42017.dg@cowlark.com> <40B4D6F9.4070507@i.com.ua> <40B52614.10908@cowlark.com> <40B585AE.101@codito.com> <20040527155128.GE21172@duckman.distro.conectiva> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20040527155128.GE21172@duckman.distro.conectiva> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-8086@vger.kernel.org hi Eduardo, Since my earlier mail was focussed wrt to 8086/88, I am continuing with that only as reference when voicing few suggestions. > You are right, but this is true only if you assume that the program > don't try to mess with the segment registers by itself, or store in > memory the values of the segment registers for using them later. That > is what was being discussed. That issue comes with user writing assembly programs and messing around. To start with the work, why not assume that user will only be writing C programs for time being and gcc/any other compiler (and corresponding c libraries) can be modified to handle the above issues. I am hopeful, as the work progresses, ideas will take better shape. AND guidelines can be laid for the assembly programmer. IF (s)he doesn't follow (s)he himself will be responsible for trashing the system. Here are my 2 cents on the issues (and a lot needs improvement and filling the gaps) -- * to start with (a dirty design), compiler generated code, limits code, data and stack to 64KB maximum (CS/DS/SS) and uses only 64KB (ES) for dynamic memory allocations. * in case data/code is more than 64KB, it should be managed via code and data overlays. these overlays could be 4/8/12/16 KB in size (to keep things simple may be can start with 8KB) mapped into fixed location in CS/DS segments. no far pointers, only near pointers. with this in place OS always have to bother with only 4 segments maximum (suggestions in my previous mail wrt 8086/88). in the scheme so far we don't endup with the need to store segment id anywhere in some variables. but in a logical sense total space for program in memory at any time is fixed at maximum 256KB, though we have much more memory available for user program. This next idea possibly hides alternatives to current idea. * we want to go beyound 256KB now. we cookup one table [with fixed limit] that is kept as a part of program related information, that informs where in memory the segments related to program are currently located and what is their length, that helps OS to track them and relocate them. for ex. ((seg1,len1),(seg2,len2).....(segN,lenN)) all the segs are saved onto disk, when process got moved out, we remember the order, and next time wherever we put them in memory, appropriately update them in this list concerning programming related information. assuming whenever the new segments are loaded into segment registers by program, they are picked up from this table. other values of CS/DS/ES/SS are anyways handled in same manner as in earlier mail. * similar treatment can be given to far pointers (allow only global/static far pointers for time beings) that get stored in same section, that can be handled in some special manner. all these far pointers have segment-offset format and the segments part can be updated in similar manner via the OS, some bit of housekeeping/supporting information will be used for this. this will keep far pointers fine across program removal and put-backs. -- regards sandeep -------------------------------------------------------------------------- Loose bits sink chips. --------------------------------------------------------------------------