Knowing bug list in Freescale S12 compiler.

[grzegorzK]

Dear

I need a support for S12 compiler (IDE version 5.9.0 build 5294). I use it not for fun but for serious application and is very important for me. Few days ago I asked for support from processor expert team and they claim there is some "ambiguous" (ambiguous = not isolated in my understanding) bugs in compiler, especially when use optimization. I try to force them to report them this bug in order to isolate and pass to compiler team what I hope will fix bug. I do not know if there is any communication between "Processor Expert team" and "Compiler team" and it is important issue for me. Pleas advise :

1. Is there any knowing bug list for S12 compiler? Processor expert force user to use specific optimization option because they claims there is bug: please follow thread:

https://community.freescale.com/message/99810#99810

2. Is it valid to execute C compiled code without proper set stack pointer? Processor Expert generate file Cpu.c where use it. Please see attachment. From my understanding is bug.

Best Regards

/Greg 

[NavidadRedivivu]

Hi Greg,

It is not obvious to me what compiler bug are you reporting in fact. It would be best if you could copy paste a code snippet which malfunctions or provide a more detailed explanation. Short answers for your questions:

1. The known bug list is in the compiler release notes. On my machine it is located here: C:\Program Files (x86)\Freescale\CWS12v5.1\Release_Notes\HC12\Notes_HC12_Compiler.txt. Both the known bugs and the compiler limitations are listed here.

2. Sometimes. When you really know what you are doing. The screenshot you provided shows a piece of code that is executed even before the startup code, which in turn executes before your "main" function. The startup code can setup your SP (and generally it does), initializes the intialized globals and zeroes out the unitialized ones. If the core does not get into executing any instruction that actually requires the stack (e.g. JSR) it does not matter that the SP is not yet initialized.

A general comment: I would not jump into calling this a compiler bug. Compilers for MCU's can sometimes be very aggressive in optimizing code, and this is ultimatly for the user's best interest. Processor exper is simply not tested with _all_ of the potential compiler options (or so I guess). Some of them induce non-ANSI behavior, others may assume a certain memory layout, etc. You need to provide some more information on the particular error you are getting, but I really suspect a configuration error. I would really advice using processor expert as what it is meant to be: a rapid application development tool, good for prototyping and trying things out. 

[grzegorzK]

Hi

I am not reporting any bug at all yet.

I have reported bug but and addressed it to processor expert (see link in my first post, there is also open ticket), not for compiler vendor. It is not my business where bug is. I just want to get some more knowledge.

1. I have read release of compiler for S12, bug list is short and without impact at all! I understand that compiler vendor do not acknowledge to any bug! Good. So far so good.
2.  My description maybe was not perfect, now I attached a project with Cpu.c file generated by Processor Expert. My question is: is it valid executing body of Ansi C function: void _EntryPoint(void) without SP set? See screenshot from previous post, SP is 0!

From _EntryPoint(); is called _Startup() when SP is set.

I am not consider situation when “user know what are doing”, all what I consider is simply Ansi C code.

Once again: I am not say there is a bug, Processor Expert guy claim there is a bug in compiler and my concern is to know: WHERE THE BUG IS and what to do next with it?

Do you suggest that Processor Expertt code is not Ansi C compliant or you know it?

Regards

/Greg

[kef]

As far as I know ANSI C knows nothing about stack. Some vendor could provide compiler for S12, which would not use stack at all. Function calls could be made using jump to subroutine, jump back from subroutine. Local storage variables could reuse some part of RAM. No problems, except of slower and bigger code.

[grzegorzK]

---

kef wrote:

As far as I know ANSI C knows nothing about stack. Some vendor could provide compiler for S12, which would not use stack at all. Function calls could be made using jump to subroutine, jump back from subroutine. Local storage variables could reuse some part of RAM. No problems, except of slower and bigger code.

---

The problem is with Freescale compiler (what is similar as any other). Question is practical, not theoretical. I left university few years ago

Compiler is free to use as many stack to simply copy register to register as only want, it also not defined in Ansi C standard, this is my concern and doubts! 

Regards

/Greg

[kef]

certainly not a bug.

[grzegorzK]

---

kef wrote:

certainly not a bug.

---

what do you mean?

Processor Expert in generated source file: Cpu.c do not allow to use (by #pragma) some more optimization than default, argue: there is bug in compiler. So in my understanding the bug is there! .. somewhere... I do not care where it is, I am patiently waiting on information where, in order to evaluate risk in my product!

Regards

[kef]

I mean that of course you can have C code with SP not initialized, provided you are sure compilerr won't use stack in this routine. I hope Processor Expert team know what they are doing.

So I don't see what other bugs are you talking about. Just something fuzzy about smart sliders, but what specific errors and in what conditions do you see? Is it so hard to CTRL-C CTRL-V error messages you see, plus compiler command line string?? Is sending tens of abstract messages more productive than providing required minimum of information about the problem? You attached zipped project, but why did you send it with settings, that not trigger any errors? Was it hard to pack project with smart sliders in positions, which trigger errors? Frankly, hope I'm wrong, but it seems you must be a pain for support persons.

Now I see what the error is, but you owe me an hour of your work time :smileyhappy:.

Error   : C52: Error in command line '-Of -OnCstVar -OnPMNC ...

Error   : Error in command line!

Error   : C4202: Invalid pragma OPTION, Invalid Options

Cpu.c line 132  

Error   : Compile failed

So compiller command line string "-CPUHCS12XE -D__NO_FLOAT__ -Mb -Ous -Of -OnCstVar -OnPMNC"

for some reason is incompatible with this pragma in the code:

#pragma OPTION ADD "-Onf"

Yes, this is a bug.

[NavidadRedivivu]

So that was the reported "bug" ! Well, then it is certainly not a compiler bug. The command line contains "-Of", which means "create sub-functions with common code". The pragma adds "-Onf" which means "do not create sub-functions with common code". If I were a compiler I would not know what to make of that either !

The only thing to clear out is why PE did disable this optimization in the first place and this is probably Greg's question too (in a complicated way ). I don't know what compiler bug would that option expose, PE guys are the only ones who can answer that (if there is nothing related to it in the release notes, which I cannot check right now since I don't haveCW installed).

[kef]

Navidad,

yes, switches seem to be conflicting, but if this is not compiler bug, then compiler driver bug or IDE bug. I'm not sure what part of CW is responsible for those smart sliders, maybe compiler driver, maybe IDE. But certainly something is wrong.

It is OK to modify compiler switches on the fly, like it is done in PE code. But error messages you get with wrong set of compiler switches are at least little confuising. I think wrong set of switches should be handled little better. "-Ofn is ignored" warning. Or "-Ofa conflicts with -Ofz" or something. Or smartsliders should be fixed. I remember that moving them adds some adds some option, which is at all not supported by current compiler.

[NavidadRedivivu]

The SmartSliders are a feature of the compiler, but a rather isolated one. What I mean to say is that the logic only handles option setting based on some heuristics without knowing the shape of the compiled code. It does not make sense to parse each and every file in the project prior to allowing the user to move the sliders (because this is the solution to take into account all the pragmas in the user code). I guess the compiler could be more permissive here, giving just a warning instead of an error and going by default for either the command line or the pragma. I just checked and unfortunatelly I cannot remap the error message to a warning. If anyone considers this as a usability issue, a service request should be open for Freescale. I for one prefer getting the error. If I ever get conflicting options between pragmas and the command line, it is most probably a mistake and I like being notified when I make mistakes like that.

[NavidadRedivivu]

Greg,

I did not see your reply before posting. Here goes:

>>1. Do they? is it possible to compile cpu.c with more aggressive optimization? No because they force to use low

>>optimization because it was not working with aggressive optimization! See statement of Petr from PE team in link from my

>>first post

Ok, I understand your problem, but I really cannot guess why did they add that pragma there. So from that point of view I cannot help otherwise than by giving you the location of the compiler release notes .

>>I do not understand your statement that SP may be not initialized if they know what  they are doing, what if compiler

>>will be upgrade and compiler will take advantage (in the same level of optimization what PE forced) of SP but SP will be

>>not set?! Compiler is free to use SP if like and is implementation behavior. No one except compiler author do not

>>know side effects of such code in next version of compiler. Please someone fix me if I am wrong. 

I'm not discussing here why PE chose to replace the startup code, but this is not entirely wrong. Embedded programming is sometimes about hacking, knowing the compiler and the target. I guess you already know that. And yes, the PE guys should know what they are doing and I really thing they do. I just opened Cpu.c myself (you owe me some time too for installing CW). Look what I found:

#pragma OPTION ADD "-Onf"              /* 'Create Sub-Functions with Common Code optimalization' must be disabled because stack is not yet initialized */

So there are your answers:

• The error is due to the fact that the file contains a pragma to disable the common code optimization.
• The pragma is there because the stack is not yet initialized and this optimization needs to generate JSR instructions and hence needs a stack.
• There only issue is that you are getting an error while using the smartsliders, which do not have the information about the source code. This is minor, you can edit the command line after you use the smart sliders and remove the "-Of". You will still get the optimization for the other files since it is enabled by default if targetting size. If targetting execution speed you do not need it anyway.

All in all: no bug, the code is safe.

[grzegorzK]

---

NavidadRedivivus wrote:

I'm not discussing here why PE chose to replace the startup code, but this is not entirely wrong. Embedded programming is sometimes about hacking, knowing the compiler and the target. I guess you already know that. And yes, the PE guys should know what they are doing and I really thing they do. 

---

Hi

You say: "but this is not entirely wrong", so is it a little wrong?

Howerer

I know is kind of hacking but it has to be limited. compiler provide full (or almost full) Ansi C compatibility, Processor Expert should provide full Hardware Abstract Layer, where is place for hacking here? I think is misunderstood each other if you encourage people to hacking. I am buying tools to do for me all "hacking job", I want to write Ansi C code. That's all my needs.

/Greg

[NavidadRedivivu]

This is turning into an endless debate and I am not sure what are we trying to achieve. The idea of my previous posts is simple: there is no obvious compiler bug there for you to worry about. 

>>You say: "but this is not entirely wrong", so is it a little wrong?

As far as I see PE needs to run some initialization prior to the standard startup code, namely some register initialization, which have to happen at startup time (for instance the MMCTL settings). They probably chose this solution in order not to patch the startup code itself, I can only speculate.

>>I know is kind of hacking but it has to be limited.

I'm not arguing this. I'm only saying that there are times when you need to.

>>Processor Expert should provide full Hardware Abstract Layer, where is place for hacking here

I can't think of any other way of executing code before the main function call other than customizing the startup code or having it replaced altogether.

>>I think is misunderstood each other if you encourage people to hacking. 

I don't encourage hacking. However, there are situations when you have to go and customize your startup code, and then it is a good thing you can actually do that. Freescale provides libraries with all the source code precisely for this purpose. You can customize the startup code and even the library if you need to, for instance compile it with different compiler options.

>>I am buying tools to do for me all "hacking job", I want to write Ansi C code. That's all my needs.

You don't have to write anything else but ANSI code yourself. If you are questioning the quality of the PE-generated code, I am not an expert here. The only comment I can make is that I find it understandable that they do not support any permutation of the compiler options. This would be a huge (not even sure ever possible) validation overhead.

Also, if you have your mind set on saying these tools are no good, there is litte I can do about that other than what I already said. There are compiler bugs, there is no question about that, some of which documented as known bugs in the release notes. But none seems to directly affect your work. Just my My .02c.

[grzegorzK]

---

NavidadRedivivus wrote:

This is turning into an endless debate and I am not sure what are we trying to achieve. 

---

Hi

you right, it is going in to endless, it was just my opinion (like your last post yours yours), I do not want to debate at all.

Thank you for support!

I am not clamming this tools are bad! Other tools are not perfect also. I do not want debate about it.

Best Regards

/Greg

[Lundin]

There was a disasterous bug in "create sub-functions with common code" early on in CW for S12, back in the Metrowerks days. Not sure whether it has been fixed or not, but that must be the reason for -Onf. I always compile my CW projects with -Onf out of old habbit, I bet the PE folks do the same.

[grzegorzK]

Kef, NavidadRedivivus: I think you do not read cerfully, I do not report any bug on this forum, I attached project what show that SP is not set while Ansi C code is executing.

Bug was reported before I post on this forum and discussing about my bug (indeed.. with an compilation error what kef found) where PE people claim that is a bug in compiler. Link to this discussion is in my first post, please read it, and my service ticket request is still open.

I suspect there is no compiler bug, but I want to discussion about not setting SP before executing Ansi C code.

Kef: you are saying it is OK if PE people know what they are doing, but:

1. Do they? is it possible to compile cpu.c with more aggressive optimization? No because they force to use low optimization because it was not working with aggressive optimization! See statement of Petr from PE team in link from my first post

2. Kef: I do not understand your statement that SP may be not initialized if they know what  they are doing, what if compiler will be upgrade and compiler will take advantage (in the same level of optimization what PE forced) of SP but SP will be not set?! Compiler is free to use SP if like and is implementation behavior. No one except compiler author do not know side effects of such code in next version of compiler. Please someone fix me if I am wrong. 

Regards

/Greg

[kef]

1. Yes they do and do it properly, IMO. What can break their startup code? Only attempt of compiler to reuse some part of their routine, putting part of their routine to additional subroutine, which won't work with SP not set up. The problem is that compiler breaks when some conflicting switches are applied at the same time. PE code IMO is correct.

2. Same as above. New optimization in compiler? PE will adapt to this new optimizaion, no problem.

Do you think that it is not possible to have C startup routine coded in C, because SP is not set up out of reset? Of course you can. The only danger I know, and what PE team is handling properly, optimization when identical code sequences are placed into subroutine to be reused in other parts of code. #pragma in PE code temporarily disables such optimization. But this doesn't apply to your code or other parts of PE generated code. So? The only problem is that compiler switch applied through #pragma is conflicting with set of switches from smart sliders. Compiler or compiler driver should handle this somehow.

BTW. These days, when parts with 1M of flash are available, does it make sense to optimize for code size? I think no, unless you selected wrong part initially and now you lack few bytes. Optimization for speed makes more sense, since this allows to save energy. Faster = more time to stay in wait or stop modes.