XCore Exchange

Posted: **Thu Jan 18, 2018 4:12 pm**

This thread is a follow-up from http://www.xcore.com/viewtopic.php?f=26&t=6331.

The problem here is that in /.build/src/__arduino_on_xmos_test.xc.o I found a lot of alias error reports. I opened in in TextEdit and much is readable there. You will find all alias error reports in /.build/src/__arduino_on_xmos_test.xc.o file.zip. See first attachment zip file.

However, when I started this thread I had made a task out of the code in main in the above src file (there is only one), then there was a completely different set of error reports in /.build/src/__arduino_on_xmos_test.xc.o. See second attachment zip file.

None of these error reports are seen in the console.

Is this something "serious" or is it some kind of perturbation that the developers have done to observe some particular behaviour?

xTIMEcomposer 14.3.2

Posted: **Thu Jan 18, 2018 5:13 pm**

Hi aclassifier,

The xc language will check for bad code at compile time as much as possible (e.g. array bound overflow).
Somethings it can't check until run time (it does not have all the information).
In this case the code will contain simple 'trap' instructions that stop the core should something bad happen (rather than it carrying on into undefined behavior - a form of 'defensive programming').

To make things nicer, the .o contains messages that will be printed up by the IDE/debugger if/when you arrive at one of these traps statements.
These messages are not loaded onto your target, they are there to give you more information if/when things go bad.

The reason the number of messages has changed is because the ability for the compiler to be sure at compile-time or not has changed.
This is all quite normal.

robert

Posted: **Thu Jan 18, 2018 11:08 pm**

So, that's where those messages are! Thanks! This is so good! I love it!

Off Topic

It reminds me of a message I got from the occam compiler: "Run-time disjointness check inserted". This was from the occam 2 compiler, I have the manuals, it's in the May 1995 D7405A occam 2.1 Toolset Reference Manual, page 119. It also was in th earlier Toolsets. The compiler ran on 386/486, and I seem to remember that when this message came the disk had been quiet for a while, so I got the feeling that that message was going to appear soon, since the processor was doing some loop. I think it was searching to do the disjointness checks at compile time, but had to give up. Or maybe there was some NP-complete algorithm that gave up. (Does anybody know?) I also think that this was when there was a replicated PAR with some kind of weakness in the definition of the limit. N had to be a constant, but still. "Disjointness" Inmos didn't define in their Glossary in the same set of books, but I think it basically was aliasing between processes. Disclaimer: mostly trying to reconstruct memory here..

XCore Exchange

Error report seen in .o file but not in Console

Error report seen in .o file but not in Console

Re: Error report seen in .o file but not in Console

Re: Error report seen in .o file but not in Console