• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1630 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

A bug in C166 v.4.27

Mik Kleshov

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();
}
In the disassembly window of the simulator the generated code looks like this:
     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
which is obviously wrong since the user stack pointer R0 gets corrupted. If we add local variables to test the use of the user stack pointer we will see that a word memory access on odd address will be generated because of the corrupt R0.
When compiling via SRC file and assembler everything is different:
; 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
We can see that the __inline keyword is ignored here and the code is correct.

- mike

Parents
  • 0 in reply to Mik Kleshov

    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.

Reply
  • 0 in reply to Mik Kleshov

    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.

Children
  • 0 in reply to Holger Hofmann

    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 )

  • 0 in reply to Holger Hofmann

    Hi Holger, hi Mike,

    this is known by KEIL and will be solved in the next release.

    Stefan

  • 0 in reply to Stefan Fricke

    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