[A83] Re: Relocatable code vs. fixed adress code
[Prev][Next][Index][Thread]
[A83] Re: Relocatable code vs. fixed adress 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".
We're arguing semantics. Imho, that's a rather stupid and pointless thing
to do. But anyways. There is a big difference between "relocating" code
that is designed to be run from a fixed address and "relocatable" code that
can be run from different addresses. These can overlap, but do not have to.
> 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".
Yes. I never stated otherwise.
> Search a bit on the internet and you will find out what I mean.
> (Maybe a good place to start http://www.dictionary.com/ )
Again, big difference between "relocation" and "relocatable". Relocation is
a verb, an action that can be done to code. I.e. copying code, fixing
addreses, etc. Relocatable is an adjective or pronoun, describing an aspect
or feature of the code. I..e. code is either relocatable, or it is not.
> 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"...
Why isn't it? You mentioned dictionary.com, so we'll look at the first
definition they have for "relocate" or "relocation": To move or be moved to
a new place. I would say that swapping around memory so that the code is
moved into the correct spot definitely fits that definition.
> 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.
Yes.
> 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")
Yes. Copying. So copying is not "to move or be moved to a new place"? I
would most certainly say that it is.
> 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.
Yes. A nice feature. But irrelevent to the discussion here.
> 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)
Right. They hacked the TI-85 so assembly programs could run. Old news.
I've known about this for at least five years.
> 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 :-)
Usgard could just as easily have used a Rigel style relocation technique.
Granted, it does have it's virtues, but in my opinion, if you look at all
the pros and cons to both methods, Rigel style relocation is definitely
better. Rigel could easily have the number of games that Usgard has.
Porting would be trivial. And you could remove all those annoying & from
the source :)
> 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.
String85 is Dan Eble's program to make TI-85 strings. It's been standard
since ZShell. The program to make the Usgard relocation table is Srcwiz.
> 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...
Yes. There are several different ways this can work, including address
pointers, self relative memory address spaces and true relative instruction
sets. And yes, none work on the z80. But we knew this.
> 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?
You wouldn't. It would be similiar to ZShell. Which doesn't really use
relocation at all. It just plain sucks.
> 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(!)
Right. It relocates the code to a fixed address.
> 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... :)
Ok. So if you don't use any libraries or anything ION specific, then you
could run the program straight from the OS (due to the definition of
"anything ION specific").
> 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 :)
I knew about all of this before (except for the bit about the TI-OS
relocating code to the same address that the shells do on the 83). Btw, the
correct term would be "programming group".
References: