Compiler refuses to compile a statement

[jas...@earthlink.net]

I'm using Arduino  1.6.6 and even tried  Arduino 1.6.8

Hi what I have include is the list.txt file created by doing avr-objdump. -S debugP.ion.elf

What the rub is  ...shp_type = (int) ship_type[i];       this statement appears to be executed.

If I put a break statement  in at the bottom of the for loop as to allow only the 1st time thru to work  the 1st item appears to work and that's it.

  taken from the debugP.ion file.

void update_ship_movement(void)
{
  int shp_state;
  int shp_type;
   
  unsigned char j;
 
   for (unsigned char i = 0; i < NUMBER_ITEM_SUPPORTED; i++)  // updates each active symbols/Ships for this tickmark of time
   {
       j = ship_location[i];
      
       shp_type = (int) ship_type[i];       <--- line of code that appears to not get compiled or even run.
       shp_state = (int) ship_state[i];
     

       int old_state = shp_state;

and here's the proof   ... taken from the  list.txt file that I created and reviewed

00000090 <_Z20update_ship_movementv>:
   
  unsigned char j;
 
   for (unsigned char i = 0; i < NUMBER_ITEM_SUPPORTED; i++)  // updates each active symbols/Ships for this tickmark of time
   {
       j = ship_location[i];
  90: 40 91 05 01  lds r20, 0x0105
      
       shp_type = (int) ship_type[i];           <----- notice no code produce it appears ????

       shp_state = (int) ship_state[i];
  94: 80 91 02 01  lds r24, 0x0102
  98: 28 2f        mov r18, r24
  9a: 30 e0        ldi r19, 0x00 ; 0
      
       switch (shp_type) {
            
          case 1:  // Destroyer

I even broken down the this statement

from

const PROGMEM unsigned char ship_type [] = {1,2,3};

to

const  unsigned char ship_type [] = {1,2,3};

to  even this and still see the same problem of that statement still not being compiled ???

unsigned char ship_type [] = {1,2,3};

      

[Matthijs Kooijman]

Hi jasonzz,

> void update_ship_movement(void)
> {
> int shp_state;
> int shp_type;
>
> unsigned char j;
>
> for (unsigned char i = 0; i < NUMBER_ITEM_SUPPORTED; i++) // updates
> each active symbols/Ships for this tickmark of time
> {
> j = ship_location[i];
>
> shp_type = (int) ship_type[i]; <--- line of code that appears
> to not get compiled or even run.
> shp_state = (int) ship_state[i];
>
> int old_state = shp_state;

If this is your entire code, I'm not surprised no code is generated for
that statement - you're not actually using the shp_type variable for
anyhthing. The compiler simply optimizes it away. Perhaps you're using
the variable somewhere else (in code you didn't show us) and this is
wrong, or perhaps your expectation of what should happen is wrong. Feel
free to clarify.

> from
>
> const PROGMEM unsigned char ship_type [] = {1,2,3};
>
> to
>
> const unsigned char ship_type [] = {1,2,3};

Unrelated to the above, but note that if you make a variable PROGMEM,
you must not access it directly, only through the pgm_load_* functions.
If you do access it directly, you will read from an arbitrary bit of
memory and not get the results you expect.

Gr.

Matthijs

[jas...@earthlink.net]

hI

What the switch statement in the sample code I provided ???

int shp_state;
int shp_type; <--------- here define

unsigned char j;

for (unsigned char i = 0; i < NUMBER_ITEM_SUPPORTED; i++) // updates each active symbols/Ships for this tickmark of time
{
j = ship_location[i];

shp_type = (int) ship_type[i]; <--------- here set to a value

shp_state = (int) ship_state[i];


int old_state = shp_state;

switch (shp_type) { <------------ and here used in switch statement ????
Comment of NOT using the variable shp_type
What about this statement ????

>--
>You received this message because you are subscribed to the Google Groups "Developers" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Paul Stoffregen]

While I'd imagine this to be common sense, apparently it's not so
commonly understood that you should provide a complete program
(everything needed to copy-paste into the Arduino IDE and Verify) when
asking for help. Really, my question for you is why do you believe
posting only a fragment of your program is a good idea? Maybe you think
you're saving other people time by giving them less code to read? Maybe
your project is proprietary or secret and trimming the code down to
something small without proprietary info is too much work? Really, I
want to understand your though process.

[jas...@earthlink.net]

Paul

I trying to make it simple to trouble a much sampler version of my much large
program which has the same problem.

I scale my program down to where the problem is and no more as to be able trouble shoot
the problem with out getting side track of much large chuck of source code to wade thru
I was plan to release the program for all to see when I'm done.

What I'm working on is a sea Wolf program since you are asking why
I'm not releasing more code plus was hoping to be a real surprise for all
in the near future.

Thanks

Jason

[Victor Aprea]

Jason, 

The problem is we can only guess without being able to put the code into our own IDE and hit compile. It could be anything... e.g. it could be something subtle like a multi-line pre-processor define somewhere that has spaces after what is supposed to be a terminating backslash. The point is, it's not reasonable to expect anyone to diagnose compiler errors without being able to hit the compile button for themselves. 

Kind Regards,

Vic

Victor Aprea // Wicked Device

victor...@wickeddevice.com

T: @vicatcu

>>> To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

>
>
>--
>You received this message because you are subscribed to the Google Groups "Developers" group.

>To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Paul Stoffregen]

> I scale my program down to where the problem is and no more as to be able trouble shoot
> the problem with out getting side track of much large chuck of source code to wade thru

That's the right thing do it, if the scaled down result is a complete
program which can be compiled by someone who wishes to investigate the
problem.

It's absolutely the *wrong* approach if you scale it down to something
which can't be compiled. Hopefully you can understand and accept this?

Really, my question is how can we as a community spread this notion, the
make it this common sense actually widespread common, that code samples
for problems need to be complete programs which can actually be compiled
by developers who investigate the issue?

[Peter Feerick]

I could be missing something here, but Jason did include a full sketch as an attachment (debugP.ino), which is a culled version of the original code that is enough to reproduce the issue encountered, and DOES compile... (or so says my Arduino IDE 1.6.10 after generating a 782 bytes binary for the Arduino Uno). Anyway, that is isn't helping the issue. 

What is confusing me is why variable like unsigned char ship_type is being stored in flash memory (as the memory usage would virtually negligible in reality), and then an integer variable is created with the same name in the update_ship_movement, and then you are trying to access the flash memory variable. Normally I would expect compiler to be completely to be confused about which variable you're trying access by this point... but because the global ship_type is in PROGMEM, it doesn't know about it. 

So in other words, it actually seems to me that the comments Matthijs though unrelated are actually very pertinent to the issue. If for some reason you are trying to create a global array of 'ship_type' as some sort of master lookup list which to base your in-game working list, you need to use the PROGMEM functions to access it. Maybe you should be using a differently named global constant that is just stored in normal memory? It's not like your PROGMEM variable is storing long strings or such, thus using PROGMEM to save SRAM. 

Also be careful about reusing the variables names - your simulate_poke() function uses ship_type again, but is declared as a boolean this time!!

Pete

Peter Feerick
BIT, BLDes CQU

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Victor Aprea]

Pete, you're right, I totally missed that. Sorry Jason.

Vic

Victor Aprea // Wicked Device

victor...@wickeddevice.com

T: @vicatcu

[Paul Stoffregen]

Oh, apologies, I also missed the attachment.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[jas...@earthlink.net]

Hi again

 

I did the following

 

and it made NO difference .. still no code for shp_type = (int) ship_type[i];

 

from

void simulate_poke(char xLocation, char yLocation, unsigned char symbol_char, boolean ship_type)

to

void simulate_poke(char xLocation, char yLocation, unsigned char symbol_char, boolean ship_types)

Please note I also had shp_type as unsigned char before I started to debug this strange problem.

 

I was thinking maybe the compiler had a problem of the switch variable being an unsigned char and change it

to a int.  As to rule that as a problem.

 

I spent 2 day debugging this problem and removing code until I came up with this small but complete program that

still has that little problem which I submit for help/review as to show this problem.

 

What I'm trying to do use program space/code space to contain the table tables and not the RAM space.

 

I know the limits of my data and that's why I picked unsigned char as to help with memory space usage and speed of access the

memory locations.   

 

You would think the compiler would either given a error or warning about shp_type variable being define both as a unsigned char and Boolean

data type.

 

 

-----Original Message-----
From: Paul Stoffregen

[Peter Feerick]

Ok, I didn't realise the variables inside the functions were different... I didn't noticed the missing 'i' on the local variables (shp_type vs ship_type). 

Ok, well after a bit of prodding, and adding serial debug messages to actually see what is happening with the variables, it *seems* the problem may not be what you think it is... as it appears the for loop is only running once! This is with the global ship_type as an unsigned char just to remove any argument over progmem calls. 

If you look at the serial debug messages, you'll notice every time update_ship_movement() run, 'i' is always equal to 0, but shouldn't it be increment to 3? I only realised it when I changed the contents of the ship_type array, and the first value updated the local shp_type variable, indicating the assignment was happening, but the loop is only running once. Hopefully you can verify this without the Serial debugging as you're comfortable with using avr-objdump (as I don't have a clue how to use it, and don't intend to bother learning just atm)

I can't tell what's stopping it though. I have a challenge for Matthijs, Paul or anyone else knowledgeable about the Arduino guts though... why would a Serial.println statement allow a for loop to increment when a Serial.print does? Why do two letters make such a big difference. Disclaimer: It is very temperamental gremlin, and can be spooked by changing other lines as well... and is so-far specific to this code as a simple sketch with just a for loop doesn't exhibit this behaviour. This is with 1.6.9 & 1.6.10, so probably isn't necessarily related to the recent compiler updates. On an Arduino Uno. Have at look the attached 'debugP_withSerial-print' and 'debugP_withSerial-println' sketches. The only change is one Serial.println line, yet the reported 'i' value is different???

Am I going mad or is 'Something Strange Going On Here' (TM) ;D

Pete

Peter Feerick
BIT, BLDes CQU

[Matthijs Kooijman]

Hi Jasonzz,

> What the switch statement in the sample code I provided ???

Ah, I did not see you put the full code in the attachment. In the
future, it might be good to explicitely mention this in the mail (you
only talked about attaching the list output).

Looking at the full code, here's your culprit:

for (unsigned char i = 0; i < NUMBER_ITEM_SUPPORTED; i++) // updates each active symbols/Ships for this tickmark of time
{

(...)

shp_type = (int) ship_type[i];

(...)

break; // debug

} // end for loop

The break at the end makes the loop only run once. The compiler sees
this, so it knows i is always 0, and thus shp_type is always
ship_type[0] == 1, so it only compiles the code for the case 1. It
generates *exactly* the behaviour you've written down, just with less
code than you expected.

I assume that, before you put in the break, the code did not run as you
expected because you forgot the pgm_load_* function to load stuff from
PROGMEM. As I said, without that, and without the compiler optimizing
away the access to ship_type, the ship_type[i] reference will end up
reading some arbitrary bit of memory, which is your real problem.

Gr.

Matthijs

[William Westfield]

On Aug 6, 2016, at 1:29 AM, Matthijs Kooijman <matt...@stdin.nl> wrote:

> break; // debug
>
> } // end for loop
>
> The break at the end makes the loop only run once. The compiler sees
> this, so it knows i is always 0, and thus shp_type is always
> ship_type[0] == 1, so it only compiles the code for the case 1.

Also, the compiler might be smart enough to notice that simulate_poke() and similar don’t actually contain any code, rendering the separate cases that called them with different arguments actually identical. (But I imagine that wasn’t the case in the “full” code, and that Matthijs’s observation is more important.)

BillW/WestfW

[Victor Aprea]

Jason,

Following up on Matthis' comments, you might find these two references useful:

http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

Kind Regards,

Vic

Victor Aprea // Wicked Device

victor...@wickeddevice.com

T: @vicatcu

Matthijs

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.