Generating PIC or nonabsolute OMF51

The Keil C51 compiler and A51 assembler generate OMF-51 object modules which are relocatable object modules (in other words, they are non-absolute). The linker relocates them to reside (and execute) from any address in CODE memory and this is what makes the final output from the linker an absolute object module.

With regards to position independent code, this implies to me that the code can be changed after linkage. And, that's not the case with our tools. In fact, I don't know of any 8051 tools that can do that or that offer that as a feature. I guess it's possible to search and replace targets of jumps and calls. However, many 8051 applications don't rely exclusively on these instructions to branch to a new address.

With regards to Program Counter-relative addressing, there is no such addressing mode on the 8051. So, this would have to be done through some kind of function call.

Can the C51 generate OMF51 Object code rather than Absolute OMF51 object code?

It already does that.

If I write a program with unresolved external references, would the linker abort as soon as it realizes that these references cannot be linked or would it resolve as much as it can and generate object code with 'dangling' unresolved symbols?

The linker would link the entire program and would output all errors/warnings it encountered.

If so, would the OMF51 file list these unresolved symbols such that a dynamic loader can patch them at runtime?

The absolute OMF51 object module format is just that - it's absolute. It does not include any fixup information about external symbols. However, this information is available in the listing file generated by the linker.

Just what kind of dynamic loader did you have in mind? Is this something you are writing yourself or have you found an existing commercial product? If you have found a product that claims to be able to do this, why don't you ask them how it all works?

Jon

I was wondering whether the Keil C51 compiler can generate Position Independent Code.

The last in the row of inventors of the '51 PC I think

The '51 is NOT intended for 'loadable code'

Erik

Hi,

With regards to position independent code, this implies to me that the code can be changed after linkage.

PIC would basically be able to be loaded anywhere in memory because all its jumps are PC-relative.

What about object code that is stored in a LIB? Is it relocatable OMF51?

Just what kind of dynamic loader did you have in mind? Is this something you are writing yourself or have you found an existing commercial product?

No, no commercial product. I had this in mind myself to be able to load modules on 8051-based sensor networks to change their behavior. There are small RTOSes which run on small microcontrollers based on AVR, MSP430, etc. architectures that provide this functionality. However, the compilers for these archs. generate ELF code so a dynamic loader can resolve the 'kernel' function calls at load-time.
I was thinking if the OMF51 file can be parsed by a dynamic loader and it's symbols resolved at load-time, something similar could be achieved on my beloved 8051 architecture.

Umar

The point of position-independent code is that you don't have to relocate it. It's not a "51 PC" request, but in fact the opposite. Without PIC, you have to have a dynamic loader that processes some file format and relocates the code for its final destination.

As Jon said, the 8051 doesn't have PC-relative addressing modes for jumps or moves, so it's not possible to write PIC for an 8051 even by hand. (In fact, I don't think the PC is visible to software at all -- or is it? I didn't see it in a quick glance at the SFRs of a couple of variants.)

the "'51 PC" I referred to is the often seen attempt to make the '51 appear as a Personal Computer. There is a group of people that believe that the '51 is useable as a "loaded program computer" which IMHO is ridiculous.

Erik

I don't think the PC is visible to software at all -- or is it?

Not really. However, there are several ways to get the PC (program counter) value.

http://www.keil.com/support/docs/3265.htm

Jon

Clever.

Peeking at the stack had occurred to me, but to set the PC that way seems to involve making all calls indirect through a thunk that converts a parameter to the actual target address. You'd need tool support much like that for bank switching to insert calls to this thunk, and there would be overhead on every single procedure call.

At that point, writing a dynamic loader starts to seem simple by comparison. It's just a list of offsets into the code to be updated when you copy it into executable RAM...

If dynamic loading of program modules is important for the application, maybe it's time to look at the ARM7. The ARM architecture does PIC nicely.

If dynamic loading of program modules is important for the application, maybe it's time to look at the ARM7. The ARM architecture does PIC nicely.

Now that wouldn't be fun now would it? :)

Thanks all for the inputs.