Rockbox mail archiveSubject: Re: Linus: bootloader main.c,1.17,1.18
Re: Linus: bootloader main.c,1.17,1.18
From: Manuel Dejonghe <limbus_at_gmail.com>
Date: Wed, 13 Jul 2005 00:07:42 +0200
It's not an optimisation in my eyes.
We certainly want it, and in this case it's certainly quicker, but
generally, one does not want big atomar operations, because they can
not be interrupted in an interrupt (eh!) that may be very time
P.S.: Feel free to slap me if I just told nuts.
On 7/12/05, Dave Hooper <dave_at_beermex.com> wrote:
> Interesting point (good link by the way - I'll have to make a note of
> that). I wonder if the default optimisation flags for rockbox build
> (just -O) does not pick up this optimisation, but a higher-level
> optimisation (e.g -O3) would do? Just a thought anyway..
> ----- Original Message -----
> From: "Ronald Teune" <rtwolf_at_gmx.net>
> To: "Rockbox development" <rockbox_at_cool.haxx.se>
> Sent: Tuesday, July 12, 2005 2:12 PM
> Subject: Re: Linus: bootloader main.c,1.17,1.18
> > Hi Dave,
> > neat, thanks. Odd that gcc doesn't do such a simple optimisation.
> > Btw, if anyone else on the list doesn't know what atomic is, here's a
> > clear description:
> > http://www-128.ibm.com/developerworks/library/pa-atom/
> > Ronald
> > On Tue, 12 Jul 2005 14:51:46 +0200, <dave_at_beermex.com> wrote:
> >> Hi Ronald;
> >> or_l is not a function call - it compiles to inline code (i.e. no
> >> CALL/RETURN, the body is actually applied in-place)
> >> Furthermore, or_l is actually optimised assembler (just one assembly
> >> instruction!) whereas the C code "X |= Y" compiles to two assembly
> >> instructions, which is slower and also not atomic
> >> Regards,
> >> d
> >>> Hi,
> >>>> and_l(~0x01000000, &GPIO_OUT); -> /* GPIO24 is the Cypress chip
> >>>> power */
> >>>> GPIO_ENABLE |= 0x01000000; -> or_l(0x01000000, &GPIO_ENABLE);
> >>>> GPIO_FUNCTION |= 0x01000000; -> or_l(0x01000000, &GPIO_FUNCTION);
> >>> Not that I'm very into the rockbox code not deep c programming, but I'm
> >>> curious about the above code change. It seems to me that the original
> >>> code
> >>> (left) is more like standard c and probably faster (no function calls).
> >>> Can someone enlighten me on this one?
> >>> Ronald
Received on 2005-07-13