[A83] Relocatable code vs. fixed adress code
[Prev][Next][Index][Thread]
[A83] Relocatable code vs. fixed adress code
Here comes some LONG mail... :-)
(sorry about the HTML, I really needed it to point attention to certain
aspects of the text)
> Van: David Phillips <david@acz.org>
> > I think if you would ask around on the Ti-85 (and 86) mailinglists they
> > would say you that relocating is changing the (jp-, call- and ld-)
> adresses
> > inside the code, so you can execute the code from any point in memory
> > (relocatable code)
>
> I think I know what relocation is. Fixing up all the addresses in a
program
> is one method of relocation. Copying the code before it's executed is
> another form of relocation. Because when you are copying it, you are
> "relocating" it, it is then located in a different area in ram.
You can think of it that way, off coarse. But everyone who knows about the
'real' relocating code, thinks you are talking about that, if you say
"relocatable/relocating code".
With the "location" of a program, they regularly mean the position from
where it is executed. If it can execute from any point in RAM it is called
"relocatable".
Search a bit on the internet and you will find out what I mean.
(Maybe a good place to start http://www.dictionary.com/ )
How should you call 'it' then? (aka the way a program is prepared for
executed at a Ti-82/83(+))
Just a bit philosophy:
So... It is (probably) not "relocating"...
How should you call it then?
Lets say, you want to execute a program on one particular version of the
Z80-based Ti Graphing Calulator (the Z80 processor hasn't got any built-in
adress-relocating). The data that should be executed is stored in a
variable (which the shell *knows* the place of). The shell doesn't *know*
if the data hasn't got any internal references. So it should *assume* that
the data can only be starting to execute from one fixed point in memory
(the shell also knows this memory-adress). This is because humans have
made a decission where a program should be started in memory for this
particular machine. They made this decission prior to making the shell, so
all programs that can run on this particular version of a Z80-based Ti
Graphing Calculator (aka Ti-82 or Ti-83 or ...), execute from there.
What happens next, the shell copies the data to the execution-adress, and
then, it calls the data. So it doesn't alter anything to the
(program-)data, the adress where the variable of the data was stored
doesn't
matter at all, because you just moved/copied the data to the normal
execution adress.
Now the program executes and it can do this the right way, because it is
located at the right place (the only place from where it can execute the
way it should execute, aka, the way the programmer intended it to execute)
So lets call it copying... :-)
(To be clear, copying code compares to "fixed-adress-executable-code", and
relocating to "relocatable code")
For *modern* processors you can program in a way that you don't have to
care about using no internal-references. (I mean in assembly, not in a
higher programming language, off coarse, then you don't have to (aka can't)
care about this yourself)
You just assemble it to execute from ".org $0000". And the processor will
"automaticly" add the adress from which it is executed. The way you store
the exec-adress-register is different per processor, normaly this is done
by the OS, I think.
On the Ti-85 they emulate this behavior of *modern* processors. At least
UsGard does this. The Ti-85 is a so call "hacked calculator", it wasn't
intended to run assembly. But some people took some time and discovered a
way to execute assembly programs. They did this by storing a pointer at a
particular place in RAM where the TIOS stores a pointer to the place it
should call to when returning from one of its subroutines. The pointer is
put there in a rather difficult way, and letting it point to another
program would need to edit the RAM which is of coarse something most people
don't think of as "easy". (another dificulty, when you have altered the
pointer, it doesn't point anymore to your hex-editor...) So they made a
shell, which resides at a fixed place in memory (probalby the first
variable in RAM), and they called it "UsGard" (probably something
North-European)
When making this shell they could decide themselves how they would like to
start programs. They had found this "hole" in the TIOS, so they would
probably be some "dyhards" in programming. So they chose for using a
relocating technique. There is no fixed adress to execute an assembly
program from thought by Ti, and they would probably don't know of all the
places where the TIOS writes to (because Ti wouldn't tell them, they
weren't supposed to run any assembly on the calc). So relocating-code was
the best they could do. Later-on other shells (like Rigel) have changed
this, but most people who run assembly on there Ti-85 still use UsGard
(there are more games made for UsGard :-)
Now some info about what UsGard does:
When you make an assembly program for UsGard you will have to set the .org
adress to $0000, and add an "&_" (or something...) to the adresses you call
to. Why? You assemble the (assembly) program with the MAP-file-creation
switched on. In the MAP-file is stored all the adresses of your program
(so it's a 'map' of the layout of your program).
Another (MS-DOS-)program (String85, if I'm not mistaken) then analyzes this
MAP-file and creates a pointer-table, to all the JP's, CALL's and LD's
(where you put the "&_" in front of). It stores this table together with
the UsGard header at the very beginning of the program.
When UsGards now *wants* to execute your program, it looks at the
pointer-table and it then fixes/relocates all the adresses the table points
to, so they are getting fixed before (in time) the program get's executed.
When the program is executing no "fixing" takes place. On the *modern*
processors the routines can be moved inside of memory (and also out of
memory), because they can change the "base-adress" (or how you would call
it). None of these can be done on the Z80...
So the UsGard-programs are only relocatable before exec-time. Doing it
while executing could be possible, because of the pointertable, but that
would need lots of code and pain to program such a shell. And, why would
you want to it?
Rigel (another Ti-85 shell) just moves the program-variable to the lowest
possible adress (not so low that it interferences with any TIOS-variables,
aka, it's put right after the shell). And then calls the program from
within its variable(!)
> > Copying doesn't do any changes to the code itself (you hope ;-)...
> > Of coarse, the code is then located somewhere else so it is RE-located,
> > but...
> > The programs on the Ti-83 (and 82/83+) are assembled in a way (.org
> > $xxxx-statement) so they execute from ONE point only.
>
> Yes. They are. Therefore they HAVE to be at that address when run,
> otherwise they will most likely not work (they will work if they have no
> fixed addresses refering to themselves). What I was saying is that I
> thought that ION relocated programs to this address (yes, we know it
does,
> otherwise nothing would work), but that the TI-OS did not.
The TIOS also copies the data to the same execution-adress as Ion (and SOS
and Zes and Venus and Ashell and Anova and...[all the other Ti-83 shells]).
Just read the info at Ti's website...
Let's see what your answer is... :)
Henk Poley
PS: You probably know much of this already (else you wouldn't be in the ACZ
programming 'alliance'...) but well, I just had to tell :)
Follow-Ups: