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

User defined memory space

Hi all,

I'm asking if anyone has found a better way to access user defined memory. That is, accessing memory that can't be reached w/the "movx" instruction, but must be accessed w/user code.

I can get it done w/Far memory but don't want to buy the PDK.

I finally found that I can use good old C51.exe & BL51.exe and generic pointers to get the job done. I can divide XDATA space into "standard" RAM and user defined RAM by writing my own ?C?CSTPTR & ?C?CLDPTR routines (these library routines resolve generic pointers at run time).
This can get tedious (using pointers when I normally didn't have to) but it works. My main problem is that I have to be careful to use or store parameters passed between functions (via registers) right away or the compiler will store them in XDATA w/MOVX - which can cause trouble depending on the address.

Anyway, if I'm careful this works. And, I don't see any other way to do this aside from buying the PDK.

Has anyone else ever done this another way?

Thanks for your time.

Bill

Parents
  • What's the loaded labor rate at your company?

    $1600 is maybe three days of work. Heck, just carrying on this argument cost a noticable fraction of the extra expense of the PK51 upgrade. Never mind the actual cost of researching, implementing, and testing replacement library code.

    Penny-wise, pound-foolish, IMO. But then, it's not my problem.

    Anyway, you're on the right track, though I think you have a few more library routines to re-implement to have all the bases covered. Take a look at XBANKING.A51 at all the load/store XPTR routines; you'll want to do them all in order not to have to worry about which ones the compiler happens to need. The "theory of operation" section of the comments explains the use of the third tag byte in generic pointers to represent extended XDATA as well as the memory space.

Reply
  • What's the loaded labor rate at your company?

    $1600 is maybe three days of work. Heck, just carrying on this argument cost a noticable fraction of the extra expense of the PK51 upgrade. Never mind the actual cost of researching, implementing, and testing replacement library code.

    Penny-wise, pound-foolish, IMO. But then, it's not my problem.

    Anyway, you're on the right track, though I think you have a few more library routines to re-implement to have all the bases covered. Take a look at XBANKING.A51 at all the load/store XPTR routines; you'll want to do them all in order not to have to worry about which ones the compiler happens to need. The "theory of operation" section of the comments explains the use of the third tag byte in generic pointers to represent extended XDATA as well as the memory space.

Children
  • Hi Drew,

    I greatly appreciate the feedback.

    Being a hardware guy, I often don't understand the things that get you SW types' knickers all twisted up.

    Figuring out how to hack the compiler and write my own library routines (all the ones in xbanking.a51) took less than half a day. There are only two calls to my "special" memory, so testing went pretty quickly.
    The only potential future problem is that a new set of eyes may skip the docs and not know to check the .m51 file for XDATA placed in the "special" memory area.

    Thus, my question about other methods.

    Reading & writing this thread has taken maybe 30 minutes of my time.

    I've hacked many a compiler in my day, and am a little stunned that this practice is apparently very frowned upon these days. Tools are supposed to serve us, not the other way around.

    Anyway, thanks for weighing in. I do appreciate it.

    Bill

  • "Being a hardware guy, I often don't understand the things that get you SW types' knickers all twisted up."

    Maybe an analogy would help?

    As a hardware guy, I'm sure you appreciate the value of a good 'scope.

    Your scheme is a bit like saying, "I really need a dual-trace scope, but I've got this trusty single-trace job, and don't want to pay out for a new one - so I'll just build myself a chopper to make it look like a dual trace..."

    Of course, you could do it; and it probably would be a useful learning experience, but it's hardly the way to run a business in this day & age, is it?

    "I've hacked many a compiler in my day, and am a little stunned that this practice is apparently very frowned upon these days."

    And maybe, in the Good Old Days, you did have to build your own chopper to get a dual-trace scope, and wind all your own transformers, etc, etc, ...

  • "I've hacked many a compiler in my day, and am a little stunned that this practice is apparently very frowned upon these days."
    Please provide a link to your code so I can hack it.
    Since you believe that code should be free to hack, please make yours available.

    Thanks

    Erik

  • So - writing your own library routines (as recommended by Keil in their own documentation) is illegal or immoral?

    That cracks me up! Very funny.

    As far as the scope analogy - I don't even need a voltmeter to get this job done!

    I think you folks must not understand how simple this is - and it is already done!!

    I just thought I'd poll the great minds here for better ideas.

    My mistake! I give. You win. It is wrong to buy a sling shot and make it better to kill a fox if the same company can sell me an elephant gun.

    Sheesh.

  • I just thought I'd poll the great minds here for better ideas.
    you included the better idea in your first post:

    I can get it done w/Far memory

    Erik

  • please.... That's the best you can do?

    Why not point out the part of my user's agreement that says I can't write my own library routines? What, you can't find it?

    I now promise to give you the last word.

    Unless, of course, I have to apologize when you've shown me that what I've done is wrong.