Для uint в Keil /16 не равно >>4, используются разные команды Опции

[ViKo]

Вот листинг, в котором видно, что поделить на 16 требует больше команд, чем сдвинуть на 4 разряда. Для чего это, числа ведь беззнаковые?

Код

;;;222      uint8_t s0, s1, s2, s3;
;;;223      uint8_t m1 = ((s1 + s2) * 9 - s0 - s3) / 16;
000106  eb0c0006          ADD      r0,r12,r6
00010a  eb0000c0          ADD      r0,r0,r0,LSL #3
00010e  eba00007          SUB      r0,r0,r7
000112  eba00006          SUB      r0,r0,r6
000116  ea4f71e0          ASR      r1,r0,#31
00011a  eb007111          ADD      r1,r0,r1,LSR #28
00011e  f3c11107          UBFX     r1,r1,#4,#8
;;;224      uint8_t m2 = ((s1 + s2) * 9 - s0 - s3) >> 4;
000122  f3c01007          UBFX     r0,r0,#4,#8

Округление, что ли?

[ViKo]

И все-же, я не уверен, что этот код

Код

000116  ea4f71e0          ASR      r1,r0,#31
00011a  eb007111          ADD      r1,r0,r1,LSR #28
00011e  f3c11107          UBFX     r1,r1,#4,#8

есть расширение знака при делении на 16.
Может, все-таки, округление?
upd. Всё, нашел! В книге "ARM System Developer’s Guide" имеется точный ответ.

If your code uses addition, subtraction, and multiplication, then there is no performance
difference between signed and unsigned operations. However, there is a difference when it
comes to division. Consider the following short example that averages two integers:
int average_v1(int a, int B )
{
return (a+B )/2;
}
This compiles to
average_v1
ADD r0,r0,r1 ; r0 = a + b
ADD r0,r0,r0,LSR #31 ; if (r0<0) r0++
MOV r0,r0,ASR #1 ; r0 = r0>>1
MOV pc,r14 ; return r0
Notice that the compiler adds one to the sum before shifting by right if the sum is
negative. In other words it replaces x/2 by the statement:
(x<0) ? ((x+1)>>1): (x>>1)

В-общем, при делении на положительную константу U лучше не игнорировать.

[demiurg_spb]

В-общем, при делении на положительную константу U лучше не игнорировать.

Никогда об этом не задумывался. Спасибо!

Код

-3 / 2 = -1

-3 = 0b11111101

(0b11111101 + 1)/2 = 0b11111110/2 = 0b11111111 = -1 верно!

(0b11111101 + 0)/2 = 0b11111101/2 = 0b11111110 = -2  неверно!

[rezident]

Никогда об этом не задумывался.

Вообще говоря методов округления существует больше, чем один.

[_Pasha]

Вообще говоря методов округления существует больше, чем один.

дело в де-факто стандарте, а не в методах, а если его не придерживаться там, где это надо - это бага, имхо, вылезет она сразу или существенно позже..