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

C51 Code banking: library

I have following question about code banking.
There's some small tests, that uses one big library.
So, how can I put this library to different code banks?
Ofc, I can include this tests right in library project, but are there any other solutions?

Parents
  • Surely that depends upon the intra-bank call overhead and the hardware logic used for bank selection?

    Only in just how bad, exactly, the effect is.

    Calling a (library) function contained within the same bank does not require that overhead and could therefore have a significant speed advantage.

    Which is exactly why it's a bad idea to fight the linker over where the best place for each object module is.

Reply
  • Surely that depends upon the intra-bank call overhead and the hardware logic used for bank selection?

    Only in just how bad, exactly, the effect is.

    Calling a (library) function contained within the same bank does not require that overhead and could therefore have a significant speed advantage.

    Which is exactly why it's a bad idea to fight the linker over where the best place for each object module is.

Children
  • Indeed - and code banking is always a fight against the fundamental limitations of the architecture.

    The fight might have been worth it years ago when there was little alternative - but, nowadays, why not just use an architecture which doesn't impose these restrictions in the first place??!

  • "Which is exactly why it's a bad idea to fight the linker over where the best place for each object module is."

    Assuming that the linker knows the precise details of every relevant detail of the hardware configuration.

    The linker makes decisions based upon information it has available to it and the rules it has been programmed to use. If detail is missing, then the result may not be the optimum.

    Sometimes, little hints about placement can help - Especially with an architecture like the '51.

    As always, the key is understanding of the hardware and tools.

  • "...why not just use an architecture which doesn't impose these restrictions in the first place??!"

    In an ideal world, that has surely got to be the best solution.

    But ... Out of interest, have you never been presented with a piece of hardware and given the one instruction of "make it work"?

  • "The linker makes decisions based upon information it has available to it and the rules it has been programmed to use. If detail is missing, then the result may not be the optimum."
    Agreed, linker only follows presets from l51_bank.a51. So, some tweaks seems reasonable.

  • Yes, of course - but the OP has not given any indication that this is the case here.

    Even then, the answer is sometimes that the provided hardware is simply not suitable to the task - or, more often, is no longer suitable to what the task has evolved into!