• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 2831 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Generating PIC or nonabsolute OMF51

Umar Q.

Hello,

I have two separate questions:
1) I was wondering whether the Keil C51 compiler can generate Position Independent Code. Perhaps, if I build a program as a library, would the generated object code be position independent? By PIC, I mean that all jumps would be Program Counter-relative rather than absolute.

2) Can the C51 generate OMF51 Object code rather than Absolute OMF51 object code? 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? If so, would the OMF51 file list these unresolved symbols such that a dynamic loader can patch them at runtime?

Thanks,
Umar

Parents
  • 0 in reply to Umar Q.

    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.)

Reply
  • 0 in reply to Umar Q.

    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.)

Children
  • 0 in reply to Drew Davis

    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

  • 0 in reply to Drew Davis


    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

  • 0 in reply to Jon Ward

    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.

  • 0 in reply to Drew Davis

    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.