The C166 compiler generates incorrect code when using __inline functions with bit return type. Test source code:
bit bitvar1 = 1; bit bitvar2; __inline bit test() { return bitvar1; } void main() { bitvar2 = test(); }
9: void main() 10: { 0000000A 4A00F000 BMOV R0.0,0xFD00.0 11: bitvar2 = test(); 0000000E 4AF00001 BMOV 0xFD00.1,R0.0 12: } 00000012 CB00 RET
; line 4: __inline bit test() ; line 5: { ; line 6: return bitvar1; BMOV R4.0,bitvar1 ; line 7: } RET ; line 8: ; line 9: void main() ; line 10: { ; line 11: bitvar2 = test(); CALL test BMOV bitvar2,R4.0 ; line 12: } RET
Hi mike, sorry, I think in my last post I used a different source code. So let's try again with this source code: bit bitvar1 = 1; bit bitvar2; __inline bit test() { return bitvar1; } void main() { bitvar2 = test(); } Compiling this with "code"-option delivers the same result as you have shown. So we're on the same line. The "Rvb?1?test" is a static bit which is reserved in bit-addressable memory. So the code should be correct, R0 is not changed. The only "bad" thing is: the main()-function is not reentrant, because it uses a static variable. For example: replace "bitvar1" by a port input pin, and rename main() into "read_pin()", then call this function from different interrupts. You will get confusing results! Compiling with "src"-option is also correct, even though the __inline keyword is ignored: ; line 4: __inline bit test() test PROC NEAR PUBLIC test ; FUNCTION test (BEGIN RMASK = @0x0010) ; line 5: { ; line 6: return bitvar1; BMOV R4.0,bitvar1 ; line 7: } RET ; FUNCTION test (END RMASK = @0x0010) test ENDP ; line 8: ; line 9: void main() main PROC NEAR GLOBAL main ; FUNCTION main (BEGIN RMASK = @0x0010) ; line 10: { ; line 11: bitvar2 = test(); CALL test BMOV bitvar2,R4.0 ; line 12: } RET ; FUNCTION main (END RMASK = @0x0010) main ENDP This code is reentrant! Holger.
The "Rvb?1?test" is a static bit which is reserved in bit-addressable memory. Can I see some evidence to support this, please?:-) I've checked all the listing files in the project and I didn't find such a name. It only shows in the compiler listing. Besides, the disassembly window in the simulator is still giving this:
9: void main() 10: { 0000000A 4A00F000 BMOV R0.0,0xFD00.0 11: bitvar2 = test(); 0000000E 4AF00001 BMOV 0xFD00.1,R0.0
Hi Mike, Hi Stefan, I've again analysed our little problem. Mike, you are right, the variable "Rvb?1?test" is indeed replaced by R0.0. This is done by the linker. To proof this, I've generated an absolute binary file from the linker output file, and disassembled the crucial part: 4A16 F0F0 -> BMOV R0.0,FD2C.F ; = Rvb?1?test,bitvar1 4AF0 160E -> BMOV FD2C.E,R0.0 ; = bitvar2,Rvb?1?test This is actually a bug! You can report it to Keil. The bug does not appear if you use OPTIMIZE(7,SPEED): ; FUNCTION main (BEGIN RMASK = @0x4000) 0006 4A000000 R BMOV bitvar2,bitvar1 000A CB00 RET ; FUNCTION main (END RMASK = @0x4000) Holger.
Hi Holger, hi Mike, thanks for find this bug. I did the test on friday but only find that what Mike has posted as first message on 28.05.03. I tried out with different optimization levels but got a identical result. So it was good idea to disassemble and find the detail in the binary. You are excellent guys. Stefan. (This to find would not have been an easy thing ;-} Thanks again )
Hi Holger, hi Mike, this is known by KEIL and will be solved in the next release. Stefan
Hi, Stefan, thanks for find this bug No problem. But does it mean that I don't have to report this bug to Keil anymore? I mean, with your interest in the bug, it sounds like you work for Keil. If not, how do I report a bug? Do I write an email to support.intl@keil.com? There is a couple more bugs I found some time ago. One of them was in the implementation of scanf and the other was in RTX166 tiny. So while I am at it, I could as well verify that the bugs are still there and report them too. - mike