Re: EDE - Personal Suggestions and Ideas

[sandeep <sandeep@codito.com>]

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.
--------------------------------------------------------------------------