dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: time to sleep?

Re: time to sleep?

From: Paul Suade <>
Date: Sun, 25 Aug 2002 04:43:48 +0200

----- Original Message -----
From: "Sven Karlsson" <>
To: <>
Sent: Sunday, August 25, 2002 12:59 AM
Subject: Re: time to sleep?

> Hi again,
> Just coming back from some quality time with the relatives.
> > "register" is no use with gcc since itself will try to put the first
> > variables in registers (not always a good thing by the way...)
> >To rely upon registers to
> >keep a data is hazardous due to the way gcc uses them (not enough
> >to avoid stack saving/restoring for reusing registers).
> Hmm, I'm quite sure GCC always do register allocation with at least graph
> coloring when optimizing. Doesn't it? I did a backend for GCC a couple of
> years ago and it did AFAICR decent register allocation. The other
> optimizations it did weren't that good though and sadly it looks like this
> is true even today. It looks like GCC is way behind other compilers on
> a few targets. :-(

Register allocation is a matter for backend, that is, dependent of a target,
or there is a more general algo for register allocation ? for me SH1 target
is less optimizing than IA32 (for example, I was forced to use if/else
instead of switch/case in a inline function because even with a constant
selector in switch, it still produces all the cases statements, IA32 target
does the right job).

> However, most often you will see the following senario:
> Spread the word! :-) Use the register keyword. Speaking as one who has
> implemented optimizing compilers I must say I really like "register".

Well, maybe it could help a bit the compiler.

> >So I'm quite dubitative about a success to reduce power since executing
> >instructions involves DRAM access anyway. In fact, load/store actions
> >data in DRAM take much more cycles, since we must both load instruction
> >load/store data in DRAM.
> Judging from all the different phenomenons you are referring to, i.e.,
> size, use of registers etc, it looks to me that you have had problems with
> the register allocation in the optimizer . I think you would be surprised
> you tried register. I know I was when I started using it. I was coding an
> end game solver for Othello and by using register whenever possible and
> changing anything else the solver got IIRC 30% faster.

I'm speaking about the fact we are always looking for a 16-bit word in DRAM
for each instruction so we cannot avoid to access DRAM memory too much. So
using a register or not doesn't change anything. The only change is the
number of instructions to run, the less they are, the quicker it runs and
the less power it wastes. But you cannot expect a good improvement. The real
thing to do is to have the best algo for such solving. So prefer O(log n)
algos to O(n) for example, instead trying to gain just 5% by reducing and
optimizing assembly instructions to real save power.

> Also, see above. register normally helps you remove redundant code and of
> course the assiciated power consomption.

yes or no :

- data can be saved in scratch registers but their values are discarded when
calling a subfunction.
- can also be saved in callee-saver registers but the fact we need to save
their old value in stack then restore them is a slow operation too.

SH1 has only 4 scratch registers (r0,r1,r2,r3), 4 parameter registers
(r4,r5,r6,r7), 7 callee-saver registers (r8,r9,r10,r11,r12,r13, r14).

So it really depends on the contents of your functions.

> Eh?!? See the SH hardware manual pp. 459-464. Sleep mode is interrupted by
> interrupts, end of DMA and other things. Suspend mode can only be
> interrupted with reset or NMI.

You're right, I reread the manual and we must indeed use sleep mode (standby
mode looks inadequate for our need). Well, I think I was misleaded by the
fact that for IDE tells us that a sleep mode is more restrictive than a
standby mode (totally inverse definition than for SH1). Here must lie my
Received on 2002-08-25

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy