Re: A86: Re: New operating system...


[Prev][Next][Index][Thread]

Re: A86: Re: New operating system...




>You can't patch programs upon load, it's not possible!!!  How do you 
know
>what's an address and what's data?  You can't!
>
>
>The reason anything other than fixed-address relocation won't work is 
that
>it's impossible for anything other than a human to patch all code.  Any
>value might be code or data, you never know.  If you load a value into 
HL,
>it could be a label to jump to, or an address of code to modify.  Or it
>could just as easily be an immediate value that shouldn't be changed 
(it
>might be opcodes for example).  Without fixed-address relocation, you 
can't
>use any self modifying code!  Self modifying code is such an important 
tool
>I'd never program for a shell or OS that didn't support it.
>
>Just my $0.02.
>

I'm glad that you brought up these important points.  Well this what an 
operating system does.  But first of all I would like to point out that 
in order to implement any advanced OS of this type on a z80 is going to 
"require" a certain amount of higher-level "agreement" between the OS 
and the program running under the OS.  Now I'm sure you can invision 
mechanisms that will allow any program to be "loaded" anywhere in ram 
and have all the abilities and resources that current programs have, 
including self-modifing code, and JP (HL) and so forth.  The key here is 
that the writters of the OS and the writers of the programs for the OS 
need to come to a "contract" to allow for these special provisions.  My 
initial suggestion is the following.  Any program written for this new 
OS will contain a DATA segment and a PROGRAM segment.  The OS can scan 
the PROGRAM segment and fix it.  Now the JP (HL) instruction brings up 
an interesting point.  So solve this problem I propose the following 
solution.  Any program written for this OS when loaded will be notified 
of its own starting location.  If the user programmer needs to do JP 
(HL), then they can first update their HL, adding it to its own segment 
offset.  I am proposing that this information be passed to the PROGRAM 
segment via one of the first bytes of the PROGRAM segments.  So for 
example I might do the following:

LD HL,(nn)              <= nn located in DATA segment, fixed by OS.
LD DE,(PROGRAM_OFFSET)  <= constant 
ADD HL,DE
JP (HL)

This would be two extra instructions, and there maybe an even clever way 
to handle it.  But I would simple suggest that if these two instructions 
make it too slow, then do not do a JP (HL).

Another solution may be to store these values in special data segment 
that the OS would know to fix as well.

There are none-the-less simple solutions to all these problems.  But 
there are going to have to be higher-level restrictions, or protocals 
that are agreed upon by between the OS and its programs.  These 
abstractions could be handles through a set of special MACROS that a 
programmer would have to use.  But these set of MACROS should not be 
very big or unweildy....

later,

David E. West

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com