Re: EDE - Personal Suggestions and Ideas

Gábor Lénárt
2004-05-28T08:10:28Z

On Fri, May 28, 2004 at 01:39:59PM +0530, sandeep wrote:
> 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.

Wrong, because there is no such thing like 'C program' from the view point
of the CPU. It runs machine code. It's ANOTHER thing that this machine
code was produced by a C compiler/linker/etc, or it's 'hand coded' in
assembly and was assembled by the assembler and/or linked/etc into CPU
runnable machine code. My only point is that we should generally speaking
that we have or have not this feature, and probably we should not use
rules 'only C is allowed'.

[...]
> * 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.

And again, it's quite interesing that 'far pointer' notion is only
introduced by C compilers on machine without 'flat' addressing model.
However it's only because you assume that you can address the whole memory
in once. But you shouldn't and eg an assembly coder does not even have
problems to use multiple segments. (S)he does not even know what is 'far
pointer' ;-)

So it's better to provide an OPTIONAL mechanism to write multi segment
programs and it's up the the program/compiler/programmer/whatever to
handle the situation because it may varies on the certain ability of
used compiler, on task you should deal with it, etc etc etc.
That's why EXACTLY why I've been talking about SIMPLE implementation in
kernel and my theory to leave to the program to handle the high amount of
this complex work if it really needs this multi segment relocatable stuff
...

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html