• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1627 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 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

Reply
  • 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

Children
No data