I am using an 8051 (C51/BL51) with no off-chip memory. I have two functions with parameters:
void Detect( U8 iLed )
and
static U8 INHSampleHandler( U16 u16Sample )
Now I understand that Keil will allocate a variable (in DATA) for these. The problem seems to be that the locator is using the same memory location for both. I cannot understand why.
Below are excerpts from the scratchpad showing 2 "D:0026H". These are the only places these symbols are declared. Any ideas what I'm doing wrong?
Thanks, Jeff
BL51 BANKED LINKER/LOCATER V5.12 07/14/2011 09:36:23 PAGE 1 BL51 BANKED LINKER/LOCATER V5.12, INVOKED BY: Z:\TOOLS\SOFTWARE\KEIL\BL51.EXE Z:\Software\FB_CPU_Init.obj, >> Z:\Software\Settings.obj, Z:\Software\Glo >> bals.obj, Z:\Software\Devices\Clock.obj, Z:\ >> Software\Devices\Flash.obj, Z:\Software\Devices\HMI.obj >> , Z:\Software\Devices\INH.obj, Z:\ >> Software\Devices\ADC.obj, Z:\Software\Devices\Timer.obj, Z >> :\Software\Builds\TestINH - 06-00039-21-09\Main.obj >> , Z:\Software\Test\Test_Button.obj, Z:\So >> ftware\Builds\TestINH - 06-00039-21-09\Version.obj TO Z:\ >> Software\Builds\TestINH - 06-00039-21-09\06-00039-21-09-xx.wsp >> RS (256) PL (68) PW (78) XDATA (?XD?SETTINGS (0X0)) CODE (?CO?VERSION (0X7 >> FC0)) MEMORY MODEL: SMALL Deleted for brevity ------- PROC _INHSAMPLEHANDLER D:0026H SYMBOL u16Sample C:0BF1H LINE# 150 C:0BF5H LINE# 151 C:0BF5H LINE# 207 C:0BF7H LINE# 208 ------- ENDPROC _INHSAMPLEHANDLER ------- ENDMOD INH Deleted for brevity C:09FEH PUBLIC _Detect C:074EH PUBLIC main ------- PROC _DETECT D:0026H SYMBOL iLed
If the two functions aren't calling each other and the compiler/linker can see that the two variables will never be needed at the same time - what is then wrong with optimizing the memory usage by using the same space for the two variables?
I see. In my case one of these functions is called by an ISR. So I changed my function declaration to
static U8 InhalationSampleHandler( volatile U16 u16Sample )
and now the locator keeps the data separate. Any idea if this is a guarantee that the linker will do the right thing?
Thanks for the help.
I disagree that it is perfectly correct, and I disagree that it is reasonable.
"the real cure is to educate the programmers"
Indeed - by not giving misleading statements.
"I disagree that it is perfectly correct, and I disagree that it is reasonable."
if you look at IB's statements in their totality, he essentially said that it is ok to call a function from within an isr, as long as you know what you are doing.
he may not have put the two statements physically next to each other, but I think if anyone were to think the two in separation, s/he has a deeper problem, with comprehension.
"Indeed - by not giving misleading statements."
people learn a lesson far better if they experience it in a painful way.
unless you can shield everyone from every misleading / less-than-truthful statement, it is probably to their interest for them to learn to identify and interpret such statements on their own.
sounds like poor programmers, rather than the message itself, are the problem.
then the real cure is to educate the programmers or let them suffer through prolonged debugging to learn their mistakes is the solution.
you are talking out of both sides of your mouth. Here you say "let them suffer" in other places you criticise that a solution is not provided.
Erik (who is not afraid of putting his name to his statements)
"unless you can shield everyone from every misleading / less-than-truthful statement, it is probably to their interest for them to learn to identify and interpret such statements on their own."
You don't seem to know what foot to stand on. In this case, it's "close enough". In other threads, you are willing to spend hours fighting for the use - or nonuse - of a single word.
"Erik (who is not afraid of putting his name to his statements)"
how heroic you are!
on that basis along, they should award you the Nobel prize for Bravery and two Metals of Honor (not just one!)
:)
"You don't seem to know what foot to stand on. In this case, it's "close enough". In other threads, you are willing to spend hours fighting for the use - or nonuse - of a single word."
because each case is different. while doing something is in-material in one case, doing the same thing may be material in others.
so the seeming contradiction is fairly easy to understand, if you have common sense.
As you well know, I'm not into C51. But I don't like the notion of people doing things in software that fly in the face of the processor architecture; that is asking for trouble. You may be sufficiently qualified to maintain the code, but the person that will take over in 5 years might not be; I think a better way is not being too smart. Keep it simple, straight forward and maintainable even if it costs you a few more instructions. But that's only my opinion.
Indeed!
One moment, you're criticising fine detail and ignoring the context; then, just to be contrary, you decide to do the opposite!
Make up your mind!
people learn a lesson far better if they experience it in a painful way. (Asheley)
That is often not an option in the commercial world...
"One moment, you're criticising fine detail and ignoring the context; then, just to be contrary, you decide to do the opposite!"
I thought I had answered that, in the post that yours above responded to.
but in case you missed it, sometimes fine details matter, and in other cases, they don't.
so it is hard and wrong to insist that one always pays attention to fine details - they are called "fine details" for a reason.
hope it helps.
Making a bold statement like "There are NO problems" - with the big emphasis on the NO - is not a fine detail. It is plain wrong.
this is exactly what IB wrote:
'There's NO problem with calling a function from an '51 ISR.
However, like most tasks, the programmer needs to understand the mechanism(s) involved and take appropriate steps to ensure the cogs fit correctly.
FWIW, we have plenty of code that calls functions from ISRs. It's all written in assembler and there have been no reported problems. Quite a few of those functions are inherently re-entrant. They are called from both ISR and mainline code. Most importantly, parameters and local variables are passed in registers.
No problem, so long as you know what you're doing, period.'
vs. what you characterized what he wrote:
"There are NO problems"
come on. would any reasonably intelligent people equate the two?
as I stated before, the two of you said the same thing, with different emphasis. and there is no point in pushing any of your statements to the extreme to justify the other.
You want to hide your spewing bile behind anonymity, I am, at least, willing to stand behind what I post.
Erik
"I am, at least, willing to stand behind what I post."
far more importantly, you have the bravery to put your name to your statement, as you proudly and publicly stated.
and that's just extremely heroic, and because of that and that alone, you should be the target of national admiration.
thus I think you deserve not just the nobel prize for bravery but also two (not just one) Metals of Honor!
"True, the problems will not be significant in some designs..."
So how low down the significance scale exactly is no problem? I described how I have written plenty of assembler functions that were inherently re-entrant.
"...but, again, just saying there are "NO" problems is unhelpful."
But when does a professional/experienced programmer learn that what they've always been told they cannot do can in fact be done?
Saying it is unhelpful, I think, in itself is unhelpful - And doing a disjustice to budding competent future professional programmers.
There are quite a few professional programmers here. Do they think that what I suggested cannot work? If they do, then I'd (unfortunately) have to say that maybe they're not quite as professional as they think.
"Because Keil C51 functions are inherently not reentrant (due to the Overlaying) ..."
Actually, that is not totally true. If one were to take the time to read the Keil documentation, they'd learn that it is in fact possible to write inherently re-entrant functions in Keil C51 (and I don't mean by using the reentrant keyword). Of course there are limitations. The functions would generally be small, take few parameters and use few local variables - Just the sort of sensible function that could be included into an ISR.
So how low down the significance scale exactly is no problem? I described how I have written plenty of assembler functions that were inherently re-entrant. the thread is about C
"...but, again, just saying there are "NO" problems is unhelpful." there are, indeed, - you say so yourself - some problems
pray show a function that "don't use the reentrant keyword" and "use few local variables" and is "inherently re-entrant".
"pray show a function that "don't use the reentrant keyword" and "use few local variables" and is "inherently re-entrant"."
Erik, I really expected better of you.
Anyway - As a starting point, take the simple/obvious example:
void foo(void) { ; }
You'd find it difficult to get fewer local variables. It doesn't need reentrant. It doesn't require any overlaying of data (simply because there isn't any).
In the past I have said to our junior trainees: "Here is the start. You have the manuals. Expand a step at a time and see how far you get".
If you have a few spare minutes, you could give it a go. The manuals really do have all the necessary information.
"the thread is about C"
Yes, it is.
And that is precisely the reason why I dislike reading the statement:
"If at all possible, avoid calling any functios from a '51 ISR, period."
The budding professional might well read that and quite literally take it to assume it includes any scenario.
Just because you've managed to avoid the problems does not mean that there are no problems.
Just like crossing the road has many dangers - but most of us manage to do it every day by being aware of the dangers, and acting accordingly.
But saying there are NO dangers is untrue and unhelpful.
"Just because you've managed to avoid the problems does not mean that there are no problems."
Andy, what problems are you talking about? I certainly didn't have to avoid any problems. There weren't any problems in what I did. Why? because I understood how the 51 works, how the assembler works, what the compiler produced, how the linker works, and what I wanted to achieve. There were no problems and no gotchas.
"Just like crossing the road has many dangers ..."
That's an extremely poor example. Processors are (in general) highly predictable. Crossing the road is totally different. You are not in control of all the variables - Most importantly there is that unknown variable sitting behind the wheel of a large mass.
"But saying there are NO dangers is untrue and unhelpful."
That seems to lack a certain amount of context. Go back and you'll see my post ended with:
No problem, so long as you know what you're doing, period.
So ... going back to the full post and full context, what I was saying is that there is no danger in doing it per se. You (and others) might consider it a danger in the context of Keil's implementation of C - But in itself I stand by what I said.
"Just like crossing the road has many dangers - but most of us manage to do it every day by being aware of the dangers, and acting accordingly."
which of the following statement would you agree more?
1) don't cross the road (because there is danger); 2) it is OK to cross the road, as long as you understand the danger.
I would rephrase it like this:
"Would you like to establish a _habit_ of crossing the road at a dangerous spot for 10 other people, when you know that the risk involved is significant"?
To me, the question is not if it is dangerous or not. Risk can be managed, at least on the short term. The question is whether this is sustainable on the long term.
my post was triggered by it is in fact possible to write inherently re-entrant functions in Keil C51 (and I don't mean by using the reentrant keyword). Of course there are limitations. The functions would generally be small, take few parameters and use few few is not none local variables
thus
void foo(void) { ; } You'd find it difficult to get fewer local variables. It doesn't need reentrant. It doesn't require any overlaying of data (simply because there isn't any).
of course not, with no local variables what I asked you to do was to show it "with a few local variables" as you stated would be no problem
"of course not, with no local variables what I asked you to do was to show it "with a few local variables" as you stated would be no problem"
So I take it that you didn't pursue the finding of a solution yourself.
I did say that my little code snippet was the starting point. Just consider/remember that parameters and variables do not have to be stored in memory - Hint, no mention of registers.
Please remember, I did say in the same paragraph:
"Of course there are limitations."
And note that for this part, at least, I didn't say there would be 'no problem'.
Anyway ... I do not consider this part of the discussion to be particularly important and I'm not going to get dragged any further into it.
the answer to that would depend on many different factors:
1) if the pay-off is sufficient, I would; 2) if the 10 other people understand their risks they are taking, I would; 3) if we are prepared for the risk, we would; ...
it is stupid to say "there is risk so don't do it". we all take risks, one way or another. sometimes wisely and others not so.
there is nothing wrong with taking risks. you just need to plan out the pros / cons and be good at it. that's essentially what IB said, in a more generic form.
It is not necessarily stupid to say "there is risk so don't do it". There is a risk going very fast on a curvy road, to an inexperienced driver I'd say "there is risk so don't do it", to a NASCAR driver I would not.
"There is a risk going very fast on a curvy road, to an inexperienced driver I'd say "there is risk so don't do it", to a NASCAR driver I would not."
but that's precisely what IB said: "there is nothing wrong with doing X if you understand what you are doing" aka your NASCAR example.
the converse of what IB said would be "don't do X if you are an inexperienced driver".
you guys really really need to improve your reading comprehension.
"you guys really really need to improve your reading comprehension."
So now it's "you guys"? Why the generalization? It seldom helps an argument. How much credibility would you give to the statement: "Everyone knows that all bikers are criminals"?
View all questions in Keil forum