[PATCH] mtd: spi-nor: fix the wrong dummy value

Gerhard Sittig gsi at denx.de
Thu Apr 17 08:55:07 PDT 2014


On Thu, 2014-04-17 at 21:41 +0800, Huang Shijie wrote:
> 
> The disassemble code for "int dummy = 8; dummy /= 8;" is:
> --------------------------------------------------
>     83a6:	2308      	movs	r3, #8
>     83a8:	607b      	str	r3, [r7, #4]
>     83aa:	687b      	ldr	r3, [r7, #4]
>     83ac:	1dda      	adds	r2, r3, #7
>     83ae:	2b00      	cmp	r3, #0
>     83b0:	bfb4      	ite	lt
>     83b2:	4613      	movlt	r3, r2
>     83b4:	461b      	movge	r3, r3
>     83b6:	10db      	asrs	r3, r3, #3
>     83b8:	607b      	str	r3, [r7, #4]
> --------------------------------------------------
> 
> The disassemble code for "int dummy = 8; dummy >>= 3;" is:
> --------------------------------------------------
>     83a6:	2308      	movs	r3, #8
>     83a8:	607b      	str	r3, [r7, #4]
>     83aa:	687b      	ldr	r3, [r7, #4]
>     83ac:	10db      	asrs	r3, r3, #3
>     83ae:	607b      	str	r3, [r7, #4]
> --------------------------------------------------
> 
> Obviously, the "dummy >>= 3" is faster then "dummy /= 8".

That is because of signedness.  Both forms of "/= 8" and ">>= 3"
should be identical to the compiler, and generate the same
output.  Compilers know that division by powers of two can be
done with a shift.

Signedness apparently makes a difference.  If you know that the
number of clocks always is non-negative, use appropriate data
types.  Or let the compiler carry out the correct instructions
for the very data type that was declared.  Pick one, don't
violate abstractions.

Counter example, matching the expectation:

	unsigned int u_div(unsigned int v) {
		return v / 8;
	}

	unsigned int u_shift(unsigned int v) {
		return v >> 3;
	}

	0000001c <u_div>:
	  1c:   e1a001a0        lsr     r0, r0, #3
	  20:   e12fff1e        bx      lr

	00000024 <u_shift>:
	  24:   e1a001a0        lsr     r0, r0, #3
	  28:   e12fff1e        bx      lr


Anyway, source code should be written for humans, as it gets read
more often than written, and maintenance is hard enough already.
Try to come up with a text search pattern to catch both the 3 and
8 values at the same time.  Or try to easily see how they are the
same when there is no comment.  Is the code path so hot that
single instructions count so badly, that the downsides should be
considered acceptable?


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de



More information about the linux-mtd mailing list