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
"This can get tedious ... I have to be careful ... or the compiler will ... cause trouble ... if I'm careful this works." Sounds like a recipe for disaster to me! Does all this faffing around, and all the risk it entails really justify the saving of the extra cost of the PDK??
Actually, all it takes is a quick look at the .M51 file to see what is where in order to avoid disaster. It's pretty simple and certainly worth saving $1600.
Isn't it amazing how some with very ambitious projects still want their tools for free. Bill, did you spend zero billable hours to develop the program you are developing and are you going to give it away for free since you evidently expect Keil to do so. Erik
Who asked for free stuff? I'm just trying to get around a limitation in the tools I bought and paid for. I am aware that I can buy a whole bunch of junk I don't need to get this one feature - but why not use a work around if one is available? You've never done that?
It's pretty simple and certainly worth saving $1600. Who asked for free stuff? as per above you did. Where is the difference between 'saving' and getting for free. but why not use a work around if one is available? You've never done that? Temporarily, waiting for a compiler fix or such Yes, permanently never. Oh the number of disasters I have seen as a result of 'workarounds' that (un)intended became permanent. Erik
I rewrote some library routines and have something that works. I was curious to know if anyone had found a way to do it better. I don't understand what is upsetting you. Is your problem that you don't think I should be allowed to write my own library routines? In any case, its obvious that you cannot think of a way to do it better. Thanks anyway, Bill
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.
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.
You may want to check the following knowledgebase article. http://www.keil.com/support/docs/1964.htm It lists all of the load and store compiler routines that are currently used. There are quite a bit more than just the ?C?CSTPTR & ?C?CLDPTR routines that you mention. Basically, the compiler is at liberty to use any of these routines based on the level of optimization, the data types accessed, the access method, and any other side effects that may occur with the data or the pointer to it. The biggest argument against re-writing these routines is that they are not intended to be general-purpose user library functions. They are intended for use by the compiler only. As such, you cannot depend on Keil to leave these routines alone -- the arguments, registers used, and function names may change (especially in future releases where new features and optimizations and likely). Actually, we do augment these routines from time to time. The routines in the PK51 that are defined for accessing far memory are specified as user routines. The compiler uses them, but they are intended to be written and maintained by the user. In the past, when I've had to access multiple RAM (or EEPROM or FLASH) areas, I've typically written functions to read and write this area directly. It does not couple directly with the compiler and the C language, but it is certainly a lot easier to explain. Most of the projects I have been involved in required a hand-off to the maintenance team. I quickly learned that for my projects, I wanted code that was easy to maintain (or else I got called in years later to fix something that someone else broke). Jon
Jon, Good to hear from you. We know each other - I used to work for Marty Pawloski a while back. We've hung out a few times, years ago. I agree that the biggest danger is if a new compiler version changes how it deals with the library files it calls. However, once a project is complete, I archive the compiler with it in order to avoid those types of problems. Anyway, thanks for the very reasonable arguments against what I'm doing. You make some good points. Keil is a good product and I'm glad we choose it for this project. Maybe next time we'll upgrade to the whole shebang. I hope things are going well for you & yours. Take care, Bill