Forum unknown
· Software
Lattice C
3 messages in this thread
It's a job for the loader on processors where it is difficult (or impossible)
to write relocatable code. Or, in the case of DRI, where a port of an existing
operating system makes it easier.
On the 68000, relocatable code gives you
1) Faster performance
2) Smaller code size
3) Complete flexibility as to its placement in memory
All it costs you is an address register or two at run-time. I figure it all
balances out.
We seem to be having a little semantics problem here, and I suspect it's the
problem that's been permeating discussions of this subject everytime it comes
up. That's why I brought it up this time.
The semantics problem has to do with the term "relocatable code". As far back
as I can remember, certainly certainly for the last twenty years, this has
meant to most people an >>ABSOLUTE<< object file, together with the relocation
information necessary … bit map, linked list, or whatever … so that the
loader can patch the absolute references when the object program is actually
loaded. After all, loading programs into places other than ORG 0000 (or 100H)
has been the rule, not the exception, in every type of computing except micros,
ever since the mid 50's. Almost every compiler and assembler written, again
except for micros, has produced code of this type. When you compile separate
procedures in FORTRAN, C, Pascal or assembler, the LINKER takes the relocatable
modules for each procedure and links them into another relocatable module for
the entire program. (Except for CP/M systems … these compilers only produce
COM files since they are all ORG'd to 100H).
Now, you are using the term "relocatable code" to mean something very
different. What you're calling relocatable code is really >>PC relative<< code
.. code that will execute at any location because there are no references to
absolute addresses in it, but only to addresses offset from the PC. It has been
said that you could use an offset from any base register, and I suppose that's
true. But if you're doing a loop or a jump, for example, the base register had
better have in it the base of the program itself.
Anyhow, people are seeing the way that the Amiga "scatter loads" a program into
whatever locations are free, and they have rightly concluded that you can't run
an "absolute absolute" program. The problem I have is that they seem to have
jumped from that to the fact that all code must be PC-relative.
I feel a little strange being so dogmatic about this … I don't have that much
experience with the Amiga, and there are people who are a lot smarter than I,
who have developer's kits and who have been writing software for the Amiga for
some time.
Still, I have been looking in vain for some reference in my manuals that state
that you muct write PC-relative code. I can't find it, and I wish someone would
give me a page # reference.
In fact, mush to the contrary, the Amiga manual gives the details of the format
of the linker output files. The format specifically includes relocation
information (see Technical Reference Manual, Sect. 2.3)…. information that it
would never need for a PC-relative program.
So the bottom line is this:
1) I fully accept that you can't run truly absolute code on an Amiga. Anything
run must go through _A_ linker, and _THE_ loader.
2) I also interpret the manuals to read that you _CAN_ write >>RELOCATABLE<<
code, in the sense given in msg 4334, as long as the loader ends up with the
load module with the relocation info in it.
3) No doubt PC-relative code will also work, since that is the special case of
a relocatable program that needs no relocation, but that is a _VERY_ special
case.
4) I have a lot of trouble believing that CBM would design a system with such a
severe restriction on it… meaning that no software already in existence for a
68000 will run on the Amiga. I likewise have trouble believing that Lattice
rewrote their compiler specifically to generate only PC-relative code.
5) I _UNDERSTAND_, really I do, that PC-relative code for the 68000 causes
little or no performance penalty. That's not the issue. The issue is not wheth
PC-relative code is easy to write, but whether it's REQUIRED by the system
design.
OK, maybe I'm wrong, but I'll repeat what I said earlier … I simply can't
believe CBM would be that dumb. Especially since it's not at all necessary to
get the scatter-loading that they want.
We seem to be having a little semantics problem here, and I suspect it's the
problem that's been permeating discussions of this subject everytime it comes
up. That's why I brought it up this time.
The semantics problem has to do with the term "relocatable code". As far back
as I can remember, certainly certainly for the last twenty years, this has
meant to most people an >>ABSOLUTE<< object file, together with the relocation
information necessary … bit map, linked list, or whatever … so that the
loader can patch the absolute references when the object program is actually
loaded. After all, loading programs into places other than ORG 0000 (or 100H)
has been the rule, not the exception, in every type of computing except micros,
ever since the mid 50's. Almost every compiler and assembler written, again
except for micros, has produced code of this type. When you compile separate
procedures in FORTRAN, C, Pascal or assembler, the LINKER takes the relocatable
modules for each procedure and links them into another relocatable module for
the entire program. (Except for CP/M systems … these compilers only produce
COM files since they are all ORG'd to 100H).
Now, you are using the term "relocatable code" to mean something very
different. What you're calling relocatable code is really >>PC relative<< code
.. code that will execute at any location because there are no references to
absolute addresses in it, but only to addresses offset from the PC. It has been
said that you could use an offset from any base register, and I suppose that's
true. But if you're doing a loop or a jump, for example, the base register had
better have in it the base of the program itself.
Anyhow, people are seeing the way that the Amiga "scatter loads" a program into
whatever locations are free, and they have rightly concluded that you can't run
an "absolute absolute" program. The problem I have is that they seem to have
jumped from that to the fact that all code must be PC-relative.
I feel a little strange being so dogmatic about this … I don't have that much
experience with the Amiga, and there are people who are a lot smarter than I,
who have developer's kits and who have been writing software for the Amiga for
some time.
Still, I have been looking in vain for some reference in my manuals that state
that you muct write PC-relative code. I can't find it, and I wish someone would
give me a page # reference.
In fact, mush to the contrary, the Amiga manual gives the details of the format
of the linker output files. The format specifically includes relocation
information (see Technical Reference Manual, Sect. 2.3)…. information that it
would never need for a PC-relative program.
So the bottom line is this:
1) I fully accept that you can't run truly absolute code on an Amiga. Anything
run must go through _A_ linker, and _THE_ loader.
2) I also interpret the manuals to read that you _CAN_ write >>RELOCATABLE<<
code, in the sense given in msg 4334, as long as the loader ends up with the
load module with the relocation info in it.
3) No doubt PC-relative code will also work, since that is the special case of
a relocatable program that needs no relocation, but that is a _VERY_ special
case.
4) I have a lot of trouble believing that CBM would design a system with such a
severe restriction on it… meaning that no software already in existence for a
68000 will run on the Amiga. I likewise have trouble believing that Lattice
rewrote their compiler specifically to generate only PC-relative code.
5) I _UNDERSTAND_, really I do, that PC-relative code for the 68000 causes
little or no performance penalty. That's not the issue. The issue is not wheth
PC-relative code is easy to write, but whether it's REQUIRED by the system
design.
OK, maybe I'm wrong, but I'll repeat what I said earlier … I simply can't
believe CBM would be that dumb. Especially since it's not at all necessary to
get the scatter-loading that they want.