This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: How can HAL_REORDER_BARRIER() prevent optimization? Thanks a lot
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: "Qiang Huang" <jameshq at liverpool dot ac dot uk>
- Cc: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
- Date: 05 Oct 2002 13:56:20 +0100
- Subject: Re: [ECOS] How can HAL_REORDER_BARRIER() prevent optimization? Thanks a lot
- References: <BDEPKKELILOKGOAOMONOMEDFCAAA.jameshq@liv.ac.uk>
"Qiang Huang" <jameshq@liverpool.ac.uk> writes:
> As defined as:
> #define HAL_REORDER_BARRIER() asm volatile ( "" : : : "memory" )
>
> If as:
>
> HAL_REORDER_BARRIER( );
> do_something_fun( );
> HAL_REORDER_BARRIER( );
>
> Will do_something_fun( ) be protected(not being optimized(eg. delete, move
> etc.)) while it is surrounded by two HAL_REORDER_BARRIER( )s?
That example will have no effect since a function call is already a
suitable barrier.
>
> How does this work?
>
It works because that is what GCC defines a volatile asm directive to
do: the instruction scheduler will not migrate instructions across it.
> what is meaning of "memory" in the HAL_REORDER_BARRIER macro??
It marks the asm directive as affecting memory rather than just
registers.
All of this is described in the GCC documentation.
--
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss