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!
ZShell programs had to patch themselves by calling a bunch of slow routines
in the shell that added the program's address to the address they wanted to
call (they used a bunch of relative jumps). Usgard relocation sucks too,
IMHO (from what I could tell when I researched all the 85 shells). It looks
to me that their special pre-assembler takes all the addresses prefixed by &
and creates a table at the end of program, which are then patched to where
ever the program is in memory, then patched back when it's done. Unless I
understand it wrong (which I probably do), this method either takes up lots
of room or can have errors. But if Mardell, Ess and the other 85 legends
worked on it, then I'm sure I'm overlooking something, but I don't see how.
PhatOS just relocates special PhatOS programs (PhatStrings) to a specific
place in memory, using a "standard" routine that they wanted all shells to
use. Rigel looked to me like an awsome shell, the only one offering true
fixed-address relocation (the only real method, IMHO) and possible
dynamic-link style libraries. If I was going to program/port on the 85, I'd
use Rigel. Just a little background, I spent a whole evening studying ALL
of the 85 shells... (not tonight)
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.
>>you're also loading it into a predictable place in memory, which
>greatly
>>simplifies the programs. the only way you could do this without
>copying
>>is to make each segment start on a page boundry, which limits you to 6
>or
>>7 segments
>>
>>if you don't load it to a specific place, the program loader (whatever
>>runs the programs) would have to patch up every jp and call in the
>>program. well, i guess you could force the program itself to do that
>(i
>>think that's how zshell worked), but that makes it too slow.
>
>just Load it once and do all the patch work when you load it into ram
>the first time. Then afterwords, you don't have to worry about this
>problem.. I don't see how this slow down would be noticable. It isnt'
>like you load and unload programs that much anyways. And in my new
>paridegm, as soon as you get the program into memory, it is ready to
>run.. no unloading when you exit. or loading when you run it. To run
>it, you just call it. and when it exists, it stays in its exact same
>memroy block. So this "patch" would only be done by the OS once when it
>puts it into memory for the first time...
Follow-Ups: