simple code cause NXT brick frozen

[afanofosc]

I think the bad code line is

Code: Select all

   not __DF0main, __DF0main

I can't even fathom why it would do that based on the original source code. I will investigate further.

John Hansen

[afanofosc]

Actually, looking at the standard firmware code it would appear that not handles float types fine. Still looking.

John Hansen

[felix2ch]

Hello,
I think this is the result of macro expansion. "until(x)" is defined as "while(!(x))". So at the end the statement is "while (!(1))". A real c compiler will make a "false" out of this but may be "nxc" is confused by that construction.

Give "while(0)" a try and tell us the result.

You are right.
After replace "until" with "while", the problem is gone!
I confused totally, because I used many "util", even "until(!(condition))", the code in this post is the only one.

[felix2ch]

There's definitely something going wrong - possibly a floating point type opcode incompatibility of some kind. Can you try with different optimization levels to see if it is an optimizer bug or a code generator bug? My guess is it is in the optimizer.

It's still frozen at optimize level 0.

Also, can you use the variables in the loop? They are being (partially) optimized out and that may lead to the bug you are seeing. Is there a "real code" case where this is hanging the brick or can you only replicate it in a trivial loop like you posted? For example, add code to write X and Y to the LCD using NumOut or something along those lines.

It's apart of a "real code". Actually, I found this problem after modified original code. The modification is delete the references of the variable y. It's working fine if add some code using the variable y like "OutText(0,0, NumToStr(y));".

I would encourage you to use the "automatic firmware" option if that is not already checked. That lets you check 2.0 and Enhanced but then it will automatically switch to standard if that is what you have installed on your NXT.
John Hansen

It's still frozen after checked all 2.0 and Enhanced and "automatic firmware".

[afanofosc]

I am unable to reproduce the problem with the enhanced firmware. Has anyone else running the enhanced firmware been able to get this crash to happen? So far I have also not been able to tell what exactly is causing the failure. The generated code looks fine. It may be necessary to write an NBC version with some TextOut lines to figure out exactly which opcode is triggering the crash. I'll have to flash the standard firmware as well to see if I can reproduce it at all.

Can you show me the F12 code with until(1) and then show me the code with while(0) (which apparently works) for the current compiler at optimization level 3?

John Hansen

[felix2ch]

Can you show me the F12 code with until(1) and then show me the code with while(0) (which apparently works) for the current compiler at optimization level 3?

F12 code of util(1) at level 3

Code: Select all

dseg	segment
;------- definitions -------
;------- declarations -------
__D0main	sdword	
__DF0main	float	
____initialize_global_data_return	byte	
__constVal1	sbyte	1
__PFTmp	byte	
dseg	ends
;------- code -------
thread main
	subcall __initialize_global_data, ____initialize_global_data_return
__ASM_Label_558:
	not __DF0main, __constVal1
	tst 5, __D0main, __DF0main
	brtst 4, __ASM_Label_559, __D0main
	jmp __ASM_Label_558
__ASM_Label_559:
	exit -1, -1
endt
;------------------------
subroutine __initialize_global_data
	subret ____initialize_global_data_return
ends
;------------------------

F12 code of while(0)

Code: Select all

dseg	segment
;------- definitions -------
;------- declarations -------
__D0main	sdword	
____initialize_global_data_return	byte	
__constVal0	sbyte	
__PFTmp	byte	
dseg	ends
;------- code -------
thread main
	subcall __initialize_global_data, ____initialize_global_data_return
__ASM_Label_558:
	tst 5, __D0main, __constVal0
	brtst 4, __ASM_Label_559, __D0main
	jmp __ASM_Label_558
__ASM_Label_559:
	exit -1, -1
endt
;------------------------
subroutine __initialize_global_data
	subret ____initialize_global_data_return
ends
;------------------------

Thanks a lot.

[HaWe]

for me the "frozen" code works fine, even with until(1), until(0) and either optimization level.
Bricxcc 3.3.8.10 20.2.2013

[afanofosc]

I am nearly certain that the problem is in this line:

Code: Select all

	not __DF0main, __constVal1

I fixed a bug a long time ago which could crash the standard firmware:

Code: Select all

static pSetOperand SetProcArray[9]= {cCmdSetByte, cCmdSetByte, cCmdSetByte, cCmdSetWord, cCmdSetWord, cCmdSetLong, cCmdSetLong, cCmdSetError, cCmdSetError}; // dup UByte to line up

If this array was ever indexed by the Float TypeCode (10) then it would try to read past the end of the array and call a function pointer in the middle of nowhere. The enhanced firmware looks like this:

Code: Select all

static pSetOperand SetProcArray[11]= {cCmdSetByte, cCmdSetByte, cCmdSetByte, cCmdSetWord, cCmdSetWord, cCmdSetLong, cCmdSetLong, cCmdSetError, cCmdSetError, cCmdSetError, cCmdSetFloat}; // dup UByte to line up

This fix was never taken by LEGO and incorporated into the standard firmware. For this and many, many, many, many, many other reasons I highly recommend that you switch to using the enhanced firmware which is 100% compatible with the standard firmware but not broken like it is in several places.

You might find it interesting to know that with NXT-G 2.0 every variable is a floating point variable (iirc) so the standard firmware was never tested for a case where some variables are not floats.

Unfortunately, it is unlikely that I will be producing a compiler fix to guarantee that no code generated by the compiler can trigger a standard firmware bug that crashes the NXT.

John Hansen

[HaWe]

those are the reasons why I always recommend to upload exclusively the EFW and target exclusively the EFW by the compiler - and not automatically 8-)

[felix2ch]

This fix was never taken by LEGO and incorporated into the standard firmware. For this and many, many, many, many, many other reasons I highly recommend that you switch to using the enhanced firmware which is 100% compatible with the standard firmware but not broken like it is in several places.

Thanks for your reply and I will try to using enhanced firmware.
I just wonder why the code works fine at earlier compiler.