Rockbox mail archiveSubject: Re: Re: time to sleep?
Re: Re: time to sleep?
From: Paul Suade <paul.suade_at_laposte.net>
Date: Sat, 24 Aug 2002 22:59:10 +0200
Registers are low with SH1, 14 registers since r15 is the stack pointer.
Most interesting instructions are just only dealing with r0 (kind of
accumulator register as you can find on old cpu). To rely upon registers to
keep a data is hazardous due to the way gcc uses them (not enough registers
to avoid stack saving/restoring for reusing registers).
Due to archos jukebox design, code is mostly executed from DRAM as a 16-bit
memory space, WITHOUT any cache. There is a 4 KB SRAM (internal, 32-bit,
only 1 cycle access) but not enough for the whole software. Beside, the same
code in C, compiled for SH1 target tends to be more versatile than for IA32
target (meaning a lot of instructions for simple task).
So I'm quite dubitative about a success to reduce power since executing
instructions involves DRAM access anyway. In fact, load/store actions with
data in DRAM take much more cycles, since we must both load instruction and
load/store data in DRAM.
Just a precision, you were speaking about sleep mode, it is a mistake, you
probably speaking about standby mode. Don't use sleep mode but standby mode
to reduce the power consumption because sleep mode shuts down all, i.e,
peripheral controlers like timers, external interrupts would be reset, which
is probably not what you want. So you must use standby mode so timers and
external events can wake up SH1 if necessary. Of course using standby mode
makes a sense if we can be sure there is a lot of time spent in idle mode.
----- Original Message -----
From: "Rune" <colourless_at_stud.ku.dk>
Sent: Friday, August 23, 2002 7:26 PM
Subject: Re: Re: time to sleep?
> If variables are kept in registers we spare the data fetch in the MEM
> of the SH1 pipeline. So while we can't avoid the instruction fetch in the
> phase, we can still spare the latter. While this won't reduce the time to
> complete the instruction, it would possibly reduce the instructions usage
> power (provided the mem fetch uses a fair amount of power.) .
> Please correct me if I'm wrong. :-)
> - Rune
> ----- Original Message -----
> From: "Nielsen Linus (ext)" <Linus.Nielsen_at_elema.siemens.se>
> To: <rockbox_at_cool.haxx.se>
> Sent: Friday, August 23, 2002 10:33 AM
> Subject: RE: Re: time to sleep?
> > > So, I'm all for using sleep modes. However, if you are really going to
> > > reduce power then you should sleep as much as possible. And
> > > you cannot do that if you are using inefficient code.
> > My point exactly. However, as you put it (or rather, how i interpreted
> > text) you seemed to think that the memory accesses themselves added to
> > power consumtion even without a sleep mode.
> > > Now, code that usually is not considered inefficient can be
> > > very inefficient if you look at the power usage. I gave some
> > > pointers to what I believe are good programming standards.
> > I'm sure that you know a lot more than I do in this matter. Then please
> > explain how the power consumption can be lowered by keeping the
> > registers, when the RAM is accessed for every instruction anyway.
> > <large cache functionality description removed>
> > > What is, however, commonly agreed upon as a good thing as to
> > > save power is using compiler optimizations to make short
> > > efficient code with few memory references and writing
> > > efficient code.
> > Yes, it is always a good thing to write efficient code. What I objected
> > was that you wrote that efficient code in itself will draw less power. I
> > that it won't unless the CPU sleeps when it is done.
> > It is self-evident that the optimized code will save power because the
> > can go to sleep sooner-
> > > You mention that the SH is a RISC. I should perhaps mention
> > > that IMO "RISC" doesn't really mean anything. The SH is a load-store
> > > architecture and that is much more important.
> > True.
> > > To me it looks like you believe I'm against using sleep mode.
> > > I'm not, never was, and I frankly cannot see how you could
> > > deduce that.
> > I thought so, since you only talked about optimizing the code and
> > about the sleep.
> > > I'm not looking for a fight. I do tend to be bit agitated,
> > > though, when people are using arguments that I don't believe
> > > are true.
> > Please point out what was untrue in my arguments, so i can learn
> > for my next "fight". :-)
> > /Linus
Received on 2002-08-24