Hey, @nsaspook, I'm working on a PIC project in C. I feel icky all over.

In any case, I've got this code to declare and initialize an array of strings:

const char * messages[] =   {
                            "Line 1 Init msg",    //m_init1
                            "Line 2 Init msg ",   //m_init2
                            "                "    //m_blank
};

The code compiles and runs as expected, but I get this compiler warning:



What the heck does this mean?

I haven't read all the replies, so perhaps the issue has been resolved.

Is it possible that this header file is getting included more than once during the compilation process?

In general, it is good practice to deal with this by putting the following code (or its newer equivalent) in each header file.

#ifndef MESSAGES_H
#define MESSAGES_H
// Your header file contents
#endif

 

Not at the 8 bit embedded level, especially at the software/hardware interface (where I live and die).

Stick to what you know. No point arguing this.

If we stuck to what we knew we'd never develop out of the cradle.

 

If we stuck to what we knew we'd never develop out of the cradle.

@nsaspook tried to explain the lack of portability of nearly any language on 8 bit MCUs. You ignored him.

I tried to explain it to you and you replied with a straw man which I easily knocked down (but you then ignored).

I appreciate your academic/experiential knowledge regarding software programming. You seem not to be a hardware guy, though.

If you wanted to learn about 8 bit portability, you'd sit back and listen and maybe ask some appropriate questions (which I'd be happy to answer!), not argue irrelevant points.

Finally, just to reiterate for the zillionth time: for my work, there are qualities that are far more important than code portability. If that is the only selling point for C on MCUs (save for the lack of availability of -- say -- asm), then I am sad (ney, resentful) that I'm being forced in this direction by my MCU vendor of 30 years.

 

I haven't read all the replies, so perhaps the issue has been resolved.

Is it possible that this header file is getting included more than once during the compilation process?

In general, it is good practice to deal with this by putting the following code (or its newer equivalent) in each header file.

#ifndef MESSAGES_H
#define MESSAGES_H
// Your header file contents
#endif

Oh! That's what this thread was about.

I'm going have to change the title. Taking suggestions...

 

There are times when @ApacheKid is stuck in a rut. Well meaning but with a superficial understanding of the practical issues.
https://forum.allaboutcircuits.com/...emory-mapped-io-addresses.166512/post-1470276

 

@nsaspook tried to explain the lack of portability of nearly any language on 8 bit MCUs. You ignored him.

I tried to explain it to you and you replied with a straw man which I easily knocked down (but you then ignored).

I appreciate your academic/experiential knowledge regarding software programming. You seem not to be a hardware guy, though.

If you wanted to learn about 8 bit portability, you'd sit back and listen and maybe ask some appropriate questions (which I'd be happy to answer!), not argue irrelevant points.

Finally, just to reiterate for the zillionth time: for my work, there are qualities that are far more important than code portability. If that is the only selling point for C on MCUs (save for the lack of availability of -- say -- asm), then I am sad (ney, resentful) that I'm being forced in this direction by my MCU vendor of 30 years.

I really don't know what you're objecting too, I said " If we stuck to what we knew we'd never develop out of the cradle" which is true so far as I understand the world.

If I said something else that you disagree with, then what was it I said exactly?

 

Even better:

A |= B; may not be portable on all architectures.

Very well.

Since when is the definition of OR a function of the the number of bits? The portability or want thereof of that assignment is nothing to do with how many bits comprise A or B, but of the compiler, the language and the data type of A and B. We don't do OR differently depending on the number of bits.

 

There are times when @ApacheKid is stuck in a rut. Well meaning but with a superficial understanding of the practical issues.
https://forum.allaboutcircuits.com/...emory-mapped-io-addresses.166512/post-1470276

I don't this this thread is about me, I am not the subject under discussion.

 

Very well.

Since when is the definition of OR a function of the the number of bits? The portability or want thereof of that assignment is nothing to do with how many bits comprise A or B, but of the compiler, the language and the data type of A and B. We don't do OR differently depending on the number of bits.

Nothing to do with number of bits.

If A is targeting a hardware port, the resulting r-m-w operation will sometimes fail if the read is of the port pins rather than the register. Some architectures don't allow reading the port register, therefore the non-portability.

 

I don't this this thread is about me, I am not the subject under discussion.

Good, bad or just ugly, your ideas are part of the discussion when you say things like "If we stuck to what we knew we'd never develop out of the cradle." in a thread about software/hardware interfaces.

 

Nothing to do with number of bits.

If A is targeting a hardware port, the resulting r-m-w operation will sometimes fail if the read is of the port pins rather than the register. Some architectures don't allow reading the port register, therefore the non-portability.

I see, well I think you'll agree then that that is not specific to 8 bit CPUs. Further any lack of portability is due to the semantics of the memory model exposed for that part of the target device, for example an assignment to an address in ROM will not update said address, that is not because the code with the assignment is not portable, its because the target memory does not support the desired operation!

 

Good, bad or just ugly, your ideas are part of the discussion when you say things like "If we stuck to what we knew we'd never develop out of the cradle." in a thread about software/hardware interfaces.

Well if you disagree with "if we stuck to what we knew we'd never develop out of the cradle" say so and we can discuss that statement, as I said I regard it as true, in my experience there is a great deal of truth to that statement.

 

Well if you disagree with "if we stuck to what we knew we'd never develop out of the cradle" say so and we can discuss that statement, as I said I regard it as true, in my experience there is a great deal of truth to that statement.

No, “And now, back to our regularly scheduled program”.

 

[

I went ahead and created a jump table of function pointers as described here:

https://rmbconsulting.us/Publications/jump-Tables.pdf

Yes, the C text is now much messier and difficult to follow, and the resulting object code is bloated over what I can do in assembly...

...but the execution times are consistent and predictable regardless of the index value. That is probably the most important quality of all -- at least in the case of processing large state machines.

Thanks, @ApacheKid and @nsaspook.

Well....talk about bloat!

So, I need a state machine in an interrupt so as to quickly execute some action based upon the current state. I encoded it the same as before in the main line code, and lo and behold:

/opt/microchip/xc8/v2.40/pic/sources/c99/common/Umul16.c:15:: advisory: (1510) non-reentrant function "___wmul" appears in multiple call graphs and has been duplicated by the compiler

To select the proper state function from the function array, 16 bit multiplier code must be linked into the app. This code is non-reentrant, so the compiler must import at least two copies of the same multiplier function. I assume if I include state machines in other interrupt handlers, each will require their own respective 16 bit mulitplier routines.

This for something that I can do in .asm with a handful of instructions.

Just FYI -- as the project get bigger, the C to .asm code size ratio is getting worse. I'm at about 100:1 right now -- mostly because I needed sprintf to do some byte to ASCII conversion. Obviously, I'll have to hand turn some conversion code. I cannot depend on the stock libs to produce reasonably sized/speed code.

And...the fact that I have to perform a multiplication in an interrupt handler! Absolutely atrocious. It'll probably be quicker to decode the 16 states with the stock and if-then-else structure.

I hate C. At least for 8 bit micros. For all the reasons I've been bitching about the last 10 years. I was right.

 

[


Well....talk about bloat!

So, I need a state machine in an interrupt so as to quickly execute some action based upon the current state. I encoded it the same as before in the main line code, and lo and behold:

/opt/microchip/xc8/v2.40/pic/sources/c99/common/Umul16.c:15:: advisory: (1510) non-reentrant function "___wmul" appears in multiple call graphs and has been duplicated by the compiler

To select the proper state function from the function array, 16 bit multiplier code must be linked into the app. This code is non-reentrant, so the compiler must import at least two copies of the same multiplier function. I assume if I include state machines in other interrupt handlers, each will require their own respective 16 bit mulitplier routines.

This for something that I can do in .asm with a handful of instructions.

Just FYI -- as the project get bigger, the C to .asm code size ratio is getting worse. I'm at about 100:1 right now -- mostly because I needed sprintf to do some byte to ASCII conversion. Obviously, I'll have to hand turn some conversion code. I cannot depend on the stock libs to produce reasonably sized/speed code.

And...the fact that I have to perform a multiplication in an interrupt handler! Absolutely atrocious. It'll probably be quicker to decode the 16 states with the stock and if-then-else structure.

I hate C. At least for 8 bit micros. For all the reasons I've been bitching about the last 10 years. I was right.

Yes, if only there was a better language than C...

 

OMG! It doesn't even use the hardware multiplier! It bit-bangs the multiplication!

Yes, if only there was a better language than C...

For what I do, it's called .asm.

 

OMG! It doesn't even use the hardware multiplier! It bit-bangs the multiplication!

I did try to tell you, this does sound like a pretty poor compiler, not well suited to the target it seems.

 

I did try to tell you, this does sound like a pretty poor compiler, not well suited to the target it seems.

To be clear: we are speaking of the compiler that is offered by Microchip for use with their MCUs. Also, one is expect to pay for better optimizations (though I cannot see how a paid optimizer will fix some of the things I am seeing).

I just want to code in .asm -- with an absolute assembler -- like the old days. I'd have been done with my project already.

 

To be clear: we are speaking of the compiler that is offered by Microchip for use with their MCUs. Also, one is expect to pay for better optimizations (though I cannot see how a paid optimizer will fix some of the things I am seeing).

I just want to code in .asm -- with an absolute assembler -- like the old days. I'd have been done with my project already.

Doesn't matter who supplies the compiler, if the code generator is not exploiting (or allowing you to exploit) multiplication capabilities of the target, capabilities you can routinely use in assembler, then it is a poor compiler.

A code generator for the C language should be pretty basic so far as code generators go, the code generator - ideally - should be able to generate assembler at least as good as any reasonably experienced human, there's no excuse for anything less other than a weak implementation of the C language.

You're taking a poor compiler example and extrapolating from that to make a general claim about the C language. That's comparable to inferring that the French or Chinese or German languages are poor linguistically, just because some translator was poor at translating something into English.

(I see though that you said one must pay for certain optimizations, is that true? if it is then either dump Microchip or pay up).

 

To be clear: we are speaking of the compiler that is offered by Microchip for use with their MCUs. Also, one is expect to pay for better optimizations (though I cannot see how a paid optimizer will fix some of the things I am seeing).

I just want to code in .asm -- with an absolute assembler -- like the old days. I'd have been done with my project already.

Comical.