Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Linus: bootloader main.c,1.17,1.18

Re: Linus: bootloader main.c,1.17,1.18

From: Dave Hooper <dave_at_beermex.com>
Date: Tue, 12 Jul 2005 23:57:57 +0100

Huh? How is replacing two instructions with one instruction not an
optimisation?
What we want is precisely the opposite of what you said - we want to
*prevent* an interrupt occurring between the first and the second
instruction

----- Original Message -----
From: "Manuel Dejonghe" <limbus_at_gmail.com>
To: "Rockbox development" <rockbox_at_cool.haxx.se>
Sent: Tuesday, July 12, 2005 11:07 PM
Subject: Re: Linus: bootloader main.c,1.17,1.18


> 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
> critical.
>
> manuel
>
> 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
>
> _______________________________________________
> http://cool.haxx.se/mailman/listinfo/rockbox
>

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-07-13

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