this project has 3 functions (a, b nad c) function g, when running (which will be twice a year) makes function a TOTALLY inactive.
In this memory starved world we '51ers live in I am sharing some global (please it has to be - need no comments on that subject) between functions a and c snce they never will run concurrently and the program is reset after the run of function c (no it is not a bootloader, but the problem would be the same).
I am not asking for a discussion of the relative merits of my current method and do thus not list it.
Obviously, to keep it sane, there need to be a dual name of the variables involved.
So, I solicit your ideas and look forward to seein them.
Erik
1. Use a union
2. Have one variable, but each function accesses it via a different #define
3. Are there any Linker tricks that could give a "synonym" to a symbol...?
Erik, you've gotten so defensive with listing all things that are not the question that you've hidden what the question actually is so well that it took me three readings to find it.
Simple answer: no, one variable never actually has two names. Nor do I agree that
It's just as insane to have two different names for the same object, since that breaks just about the only property a variable name has by itself.
What you're trying to do here does go against the grain of the material (i.e. the programming language). The only choice is which way you're going to rough it.
By far the least intrusive method is to use a union. Put all globals particular to each major module (those 'a', 'b' and 'c') into a struct, and union-ize those structs.
OTOH, the compiler's overlay analysis should already be able to discovers all those overlayable variables by itself --- if you let it.
OTOH, the compiler's overlay analysis should already be able to discovers all those overlayable variables by itself --- if you let it. the overlayable variables is no problem, the linker does that magnificently. the issue is the globals.
Simple answer: no, one variable never actually has two names. not correct, for the XDATA variables I have the definition in an asm module and them as externs in the main .h file.
so two names: name1: ds 0 name2: ds 0100h
voila!
Oh Erik,
You're such a clever boy!
Reinvented wheels always give a much more rounded result!
Who did we got now, to use this new alias?
who cares, an idiot is an idiot, I'll treat them all the same.
PS for the remote possibility that the idiot can understand a simple statement, and hoping this get to him in a moment where the fog in his brain is not too dense: "where did I say that I invented the method".
"where did I say that I invented the method"
You may not have said it, but you're usual style of answer sure did suggest it.
XDATA variables I have the definition in an asm module and them as externs in the main .h file.
And by doing that, you're violating all kinds of assumptions built into the C programming language about what a "variable" actually is, and how it works.
You're doing something that is strictly impossible in actual C, so there's no reason for the C compiler to suspect such things would happen. So it won't be prepared for them. As long as you really don't ever mix usage of those variables, you'll probably be OK. But it does put you in "warranty void if seal broken" territory.
Unions or #defines are preferrable over asm hacks or linker tricks for exactly this reasion: they work inside the language, so the compiler knows about them.
When I'm in need of larger amounts of data for short-term use (and can't/won't use dynamic memory) I normally either uses unions or defines a large char array as a one-block heap.
The function that needs access to the memory may then allocate the right to use the block/individual union for a short while before releasing the access lock.
Other parts of the program that has a need for the memory has to poll or busy-wait for it to be available.
Unions or #defines are preferrable over asm hacks or linker tricks for exactly this reasion: they work inside the language, so the compiler knows about them. this can, for all practical purposes, be described as two different programs never running at the same time. Thus there is no 'danger'
You're doing something that is strictly impossible in actual C, so there's no reason for the C compiler to suspect such things would happen. So it won't be prepared for them how is using a union going to avoid an accidental overwrite?. Anyhow since it IS, elsewhere as well, mixed asm and C what is wrong with using the assembler to align xdata? except 'purity' of course. by the way happens to 'purity' once a few modules are written in assembler?
Anyhow, as already posted, I solicit alternatives, not comments on my current method.
so, let us look at the two presented a) union will do nothing to make it 'safer' and only make the variable names become silly.significant. b) #defines are fine, but they do disable my filtering method which can be simplified described as: I start all variable names for group a with AAA and all variable names for group c with CCC. Then I do a global replace of AAA with XXX and compile the group c modules which will reveal any misuse. Then the same for the other group.
Please remember this when YOU write a reply to others. Purile tangents just breed annoyance.
Purile tangents just breed annoyance.
your "Purile tangent" definitely will