On Mon, 3 Aug 2009, Dave Tweed wrote:

> sergio masci wrote:
> > On Mon, 3 Aug 2009, Dave Tweed wrote:
> > > In C, of course, you would simply write something like:
> > > 
> > >    tail = (tail + 1) % FIFO_SIZE;
> > > 
> > > Or, if your compilier isn't smart enough to optimize the % operator:
> > > 
> > >    tail = (tail + 1 == FIFO_SIZE) ? 0 : tail + 1;
> > > 
> > > Either of these is perfectly thread-safe; no standards-compliant compiler
> > > would turn either statement into multiple assignments to tail.
> > 
> > Is this guarenteed anywhere?
> 
> It's related to the concept of "sequence points" in C.
> In the C99 specification (Clause 6.5#2), it explicitly states:
> 
>    "Between the previous and next sequence point an object shall have its
>    stored value modified at most once by the evaluation of an expression."
>
> Operator precedence also plays a role here: You can't modify the lvalue
> on the LHS of an assignment operator while evaluating the sub-expression
> on the RHS, and when you do evaluate the assignment, you may only modify
> the lvalue once.
> 
> Therefore, the compiler may need to create an implicit temporary variable
> if you don't have an explicit one in the source code.

wow there's so much scope for optimisation lost right there. I mean 
generating the result in situ.

e.g.

	int	x, y, z

	x = y * 2 + z

this could easily be optimised to:

	bsf	STATUS, C
	rlf	y+0, w
	movwf	x+0
	rlf	y+1, w
	movwf	x+1
	movf	z+0
	addwf	x+0
	btfsc	STATUS, C
	incf	x+1
	movf	z+1
	addwf	x+1

I wonder what the HiTech compiler would produce in non-optimised mode.

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist