This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How can HAL_REORDER_BARRIER() prevent optimization? Thanks a lot


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]