Quote:
Originally Posted by Perderabo
That is more or less what I had in mind. Remember, I claim this is not terribly inefficient. I did not mean to claim that it would be beautiful. You might be able to use some macros to help make it less ugly.
Doable...certainly...I wonder what the compiler does for PIC code. Lucky for it, however, to be able to wrap around every memory assignment and usage in the code. I have to procedurally enforce such conversion, and I'm sure someone will break my "homebrew PIC" code, lol.
But, you're probably right, it is likely not too inefficient. However, add on the "easy to break" factor and...well.... I'm basically trading a slight inefficiency and some code maintainability for portability. The question is, how worth it is it? The only nice thing I see about this method is that I can (at a later time) extend it to multiple shared memory segments with ease. Obviously the the native pointer method does that by default...but asking for more than a few segments all attached to specific points in memory could start to get hairy. This way I'm assured I can extend my memory requirements into the multi-segment territory without fearing I can no longer attach one at a position depedant location.
Hummm.... I wonder if this is even a reasonable method of accessing the shared memory.... I mean...I wonder if any other application has created their own shared memory allocator or if they just bucket up individual segments of shared memory for each of their data types (seems like a bad idea given you can only attach a limited number of segments per process).
Any good books? I mean...ones that advise you
how to use shared memory, not just explain the interface to it.