[sdcc-devel] [ sdcc-Bugs-1743798 ] eliminate unnecessary bankswitching

[SourceForge.net <no...@so...>]

Bugs item #1743798, was opened at 2007-06-26 22:51
Message generated for change (Comment added) made by stsp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1743798&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msc51(8051) target
Group: non bugs
>Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Stas Sergeev (stsp)
Assigned to: Nobody/Anonymous (nobody)
Summary: eliminate unnecessary bankswitching

Initial Comment:
Hi.

This is not strictly a bug, but the effect
of that pessimization is rather bad.
If the interrupt handler is defined to use
some regbank other than 0, and it calls some
function that is not set to use any particular
regbank, then the compiler would save all the
regs and switch the bank to 0 before calling
the function. I define the inthandler to use
the specific regbank exactly to save some
stack space and an execution time, but the
effect is quite the reverse.
Unless I am missing something, if the function
is not set to explicitly use some regbank,
there is no need to switch the banks before
calling it. It looks like sdcc doesn't destinguish
between the function that is not set to use
a particular regbank and the function that
was set to use bank 0, which makes the problem.
It always switches to bank 0, but if the
function is not explicitly defined to use bank 0,
then there is no need to switch at all.

Attached is the simple demo program.
Looking into its assembly reveals how many
unneeded things are done, and how much memory
does this consume. It eats about 10 extra bytes
with the useless push/pops, which is way too
much for those poor MCUs with 128bytes of RAM.

----------------------------------------------------------------------

>Comment By: Stas Sergeev (stsp)
Date: 2007-07-18 15:19

Message:
Logged In: YES 
user_id=501371
Originator: YES

> If you use --stack-auto ALL functions are reentrant even the ones in
the
> libraries.
I know.

> And if you want some function from the library to use a certain
register
> bank, just recompile it and adapt the prototype and use that instead.
AFAIK sdcc sometimes generates the call
to the library function internally.
_gptrget(), _muluint() and the like.

> don't get what you're asking or you did not understand my answer that it
is
> not possible.
I understand that it is not possible right
now. But I wonder if it is really not
possible at all.

> Btw. SDCC uses ARx so much because it's more efficient than moving
> everything through the accumulator. Consider the following:
Thanks, I see. However, looking into the
datasheet, I've got an impression that the
push/pop are the only offenders. Is it
true, or can you give any other example?

> xch a,r2
> push acc
> xch a,r2
Maybe it can just be
mov b,r2
push b
as IIRC sdcc uses b as a scratch-pad.
But that's still a pissimization of course...

----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2007-07-18 01:23

Message:
Logged In: YES 
user_id=888171
Originator: NO

If you use --stack-auto ALL functions are reentrant even the ones in the
libraries. You cannot use it only on one source file but not on the
others.

And if you want some function from the library to use a certain register
bank, just recompile it and adapt the prototype and use that instead.

I could move this to the feature requests for you, but either I still
don't get what you're asking or you did not understand my answer that it is
not possible.

Btw. SDCC uses ARx so much because it's more efficient than moving
everything through the accumulator. Consider the following:

push ar2

or

xch a,r2
push acc
xch a,r2

----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2007-07-18 00:22

Message:
Logged In: YES 
user_id=501371
Originator: YES

> And what is wrong with telling those functions you do want to call from
an
> ISR to use the same register bank?
Sorry, I recalled the answer to this
question only now (amnesia).
You can't tell the library functions,
like memcpy, to use bankX. And calling
the library functions from the inthandler
is possible if one uses --stack-auto.

So at least as a feature request, I think
this entry is viable. But for some reasons
I can't move that to the feature requests...
Is it possible to change the tracker setup
so that people can change the "Data Type"
field? In other SF projects this is possible.

----------------------------------------------------------------------

Comment By: Stas Sergeev (stsp)
Date: 2007-06-27 20:32

Message:
Logged In: YES 
user_id=501371
Originator: YES

OK, quite clear, thanks.
Yes, there were a few small helper functions
that I wanted to use from both the int handlers
and main loop (marking them reentrant of course),
but it is not a big deal to not do so if the
good reason does exist.
Though, if possible, could you please
give a brief explanation (or point to one)
of why does sdcc use ARx so much?

----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2007-06-27 18:32

Message:
Logged In: YES 
user_id=888171
Originator: NO

Stas,

As you may or may not have noticed SDCC uses both Rn and ARn to access the
registers. The ARn version uses the direct address of the corresponding
register and thus needs to know which register bank is currently selected.

If SDCC would consider any function without __using directive as register
bank independent, it would lead to larger code in those places where it now
uses ARn.

In general it is a bad idea to call functions from an ISR.
And what is wrong with telling those functions you do want to call from an
ISR to use the same register bank? You can't share those functions with the
main loop anyway unless they are reentrant.

I don't think we want to change this behaviour.

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1743798&group_id=599