1 Nov 2009 07:46
Re: "This is probably a compiler bug..." message
Hi, I've found another situation causing sdcc to spit : « encountered NULL pcop--this is probably a compiler bug... » A line trying to set a variable but using by mistake "==" instead of "=", i.e. somevariable==1; instead of somevariable=1; Then the compiler spits this message without giving any indication about the line that is the cause of the problem. -- -- Michel Bouissou (OpenPGP ID 0xEB04D09C) ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
At this step, as every poor programmer would, I think "this is probably a
compiler issue, otherwise my brain is dead", so it's quite ashamed that I
submit this here...
I have a function called SubReadInputs() that does something complex yet
simple 
:
1/ It first "statically" fills an array/structure of 12 entries by copying ports
inputs into it.
2/ It then processes the array using a for (i=0; i<=11; i++) { ...blah... }
loop to perform some "logical debounce magic" on said entries.
However the loop doesn't work as expected at all, and when used the whole
thing goes crazy and all inputs shift permanently in a completely random way
that I'm completely unable to understand.
I've come to incriminate the loop logic itself when I noticed that :
- If I set the loop values to process a single value, it still behaves crazy
for the corresponding input.
- If I remove the loop logic and set "i" manually to any given constant value,
then the corresponding input is processed appropriately ?!?
i.e.:
Le dimanche 1 novembre 2009, George M. Gallant, Jr. a écrit :
>
> SDCC : ms51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
> 2.9.0 #5416 (Oct 6 2009) (UNIX)
Mine is from latest Ubuntu Karmic packages and displays: 2.9.0 #5416 (Aug 15
2009), so same version number but older date...
> installed and am unable to replicate your problem. I wrote a Makefile to
> compile from the command line. Did not generate a hex as I do have you
> CPU chip.
Hmm... well, if you were able to compile it, I'm able too... But that's the
actual running of this part of this program that shows completely erratic on
my system (i.e. reacting as if the same input was changing state all the time
in a random way when I know for sure it isn't... and not reacting to actual
state changes...).
If the for(...) loop is there, the program's behaviour is completely erratic,
if I remove the loop and manually set the "i" value to any possible value that
"i" should be able to take, then that part of the program processes the
corresponding entry perfectly well.
I supposed there might be either something wrong in my code (although I spent
2 days and a night checking it...) or something weird in the way sdcc
translates this part of the code into assembler and that could be visible in
the assembly code for sdcc specialists or developpers... But well, yes, it
compiles, it just runs plain wrong 
RSS Feed