Re: EDE - Personal Suggestions and Ideas

sandeep
2004-05-28T08:09:59Z

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