GNU Arm Embedded Toolchain

is this a bug ? (missing logical shift from asm output)

Asked by yann

116 uint32_t test(uint32_t x)
117 {
118 return 8U << (x & 0xFF000000U);
119 }
120

/users/yann/xxxx/toolchains/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gcc -mlittle-endian -mthumb -mcpu=cortex-m0plus -march=armv6-m -mtune=cortex-m0plus -Ofast -c -o x.o x.c

objdump x.o
00000114 test:
     114: 08 20 movs r0, #8
     116: 70 47 bx lr

Disassembly of section .comment:

why is the LSL missing from assembly ? Looks like it'll always return 8 - I don't have an M0+ board to give it a try though.

Prebuilt gcc on MBPro OSX

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
john (jkovach) said : 		#1

Looks good to me. Here is what is supposed to happen:
"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1×2^E2, reduced modulo one more than the maximum value representable in the result type."
That's exactly what you are getting, if I'm not missing anything.

Revision history for this message
yann (yannp) said : 		#2

I was expecting to get zero when the shift value is bigger than 31

according to https://developer.arm.com/documentation/dui0497/a/the-cortex-m0-instruction-set/about-the-instruction-descriptions/shift-operations

"If n is 32 or more, then all the bits in the result are cleared to 0."

Therefore, in the example given, is x is 0xFF000000, then (8U << x) shall be zero, or am I getting something wrong ?
I was actually counting on this specific behavior for my code to work properly.

Thanks

Revision history for this message
john (jkovach) said : 		#3

You are writing in C, not in assembly language. So you should consult a book on C. Where is the logic in looking up CPU instructions? It is true that most of the time C statements map to instructions nicely, so I can see where the confusion is coming from.

Can you help with this problem?

Provide an answer of your own, or ask yann for more information if necessary.

To post a message you must log in.