mP 7 - bugs

[janni]

The duplicate label errors I've found so far (PIC18 libs):

1. system.mcl - swap
2. math_double.mcl - JPKSETIOV3224
3. stringsLib.mcl - length

swap and length seem to be duplicated because they were used both as function names and assembly labels.

[zristic]

We will fix this, thanks.

[srdjan]

The duplicate label errors I've found so far (PIC18 libs):

1. system.mcl - swap

Fixed and optimized. Now it has only two assembler instructions.

2. math_double.mcl - JPKSETIOV3224

Fixed.

3. stringsLib.mcl - length

System.mcl, fixed.
Thanks for the reports.

[janni]

Fixed and optimized. Now it has only two assembler instructions.

Now, that's something I like .

[janni]

As you're fixing things so nicely , srdjan, what about points 2 & 3 of this post
http://www.mikroe.com/forum/viewtopic.php?t=11711? Those bugs should certainly not prolong their existence.

[srdjan]

As you're fixing things so nicely , srdjan, what about points 2 & 3 of this post
http://www.mikroe.com/forum/viewtopic.php?t=11711? Those bugs should certainly not prolong their existence.

I have to say that I'm disappointed by the new release - in particular by inattention to our posts after beta 4. Initial check of the new version indicates that:

1. The convertor works as before (see http://www.mikroe.com/forum/viewtopic.php?t=11517).

- The converter component has to be rewritten.

2. Typecasting of Dword does not work (compiler looks for _Float2Longword - vide http://www.mikroe.com/forum/viewtopic.p ... sc&start=0).

- Fixed

3. Minus sign in real constants defined in a unit is still omitted (see http://www.mikroe.com/forum/viewtopic.php?t=11404 - all the other postulates in same post were ignored, as well).

- Fixed.

4. Strcat function still leads to linker error '?main_Local_Text: const not found' (last post here: http://www.mikroe.com/forum/viewtopic.php?t=10988).

- The code you have written is illegal because strcat expects two RAM strings and one of your strings is in constant space. An error should be reported here. So the only way I can help you with this one, is to persuade our pascal developer to forbid such assignment, because const and ram space access are different.

5. It's still more effective to switch the optimizer off in logical expressions using volatile variables declaration than to let it 'optimize' things (vide http://www.mikroe.com/forum/viewtopic.php?t=11388).

- I'll investigate this issue further more and see what can be done at this moment.

One new thing I've noticed - numbers like 1E-3 confuse the compiler. Editor recognizes that it's real number, but compiler reacts with 'incompatible type (?0 to real)' while trying to assign such constant to a variable. Placing minus sign before such a constant leads to 'improper use of of operator -' error.

- Please give me a code example on this one.

[janni]

Thanks, srdjan. You did more than I hoped for .

4. Strcat function still leads to linker error '?main_Local_Text: const not found' (last post here: http://www.mikroe.com/forum/viewtopic.php?t=10988).

- The code you have written is illegal because strcat expects two RAM strings and one of your strings is in constant space. An error should be reported here. So the only way I can help you with this one, is to persuade our pascal developer to forbid such assignment, because const and ram space access are different..

There goes the infamous text patch then... Or will it be still active in selected cases? Certainly it would be better if the compiler reported error instead of sometimes accepting and somtimes not the same procedure call.

One new thing I've noticed - numbers like 1E-3 confuse the compiler. Editor recognizes that it's real number, but compiler reacts with 'incompatible type (?0 to real)' while trying to assign such constant to a variable. Placing minus sign before such a constant leads to 'improper use of of operator -' error.

- Please give me a code example on this one.

This one is even weirder than I thought. This

Code: Select all

program test;

var Ccoef:real;
const NiCcoef=3E3;

begin
  Ccoef:=NiCoef;
end.

produces error 'Incompatible types (string[3] to real)'. If one moves the constant declaration to a unit (leaving main as before), error 'Incompatible types (?0 to real)' is reported. In both cases, placing minus sign in constant definition leads to 'improper use of of operator -' error.

[jpc]

this works however :

Code: Select all

program test;

var Ccoef:real;
const NiCcoef: real =3E3;

begin
  Ccoef:=NiCcoef;
end.

seems there is some misinterpretation of the const value unless you explicitely tell what the type is.

[srdjan]

Thanks, srdjan. You did more than I hoped for .

4. Strcat function still leads to linker error '?main_Local_Text: const not found' (last post here: http://www.mikroe.com/forum/viewtopic.php?t=10988).

- The code you have written is illegal because strcat expects two RAM strings and one of your strings is in constant space. An error should be reported here. So the only way I can help you with this one, is to persuade our pascal developer to forbid such assignment, because const and ram space access are different..

There goes the infamous text patch then... Or will it be still active in selected cases? Certainly it would be better if the compiler reported error instead of sometimes accepting and somtimes not the same procedure call.

- We have agreed that this needs to be done thoroughly. This easiest was for us would be to forbid such action, but then some of you would eat us alive. The other option is to implement it for all cases. At the moment we are closer to the second option. However it is not an easy task and can not be done in a short time period. That is why it will stay as it is for now and will be solved in future compiler versions. Thanks for understanding.

One new thing I've noticed - numbers like 1E-3 confuse the compiler. Editor recognizes that it's real number, but compiler reacts with 'incompatible type (?0 to real)' while trying to assign such constant to a variable. Placing minus sign before such a constant leads to 'improper use of of operator -' error.

- Please give me a code example on this one.

This one is even weirder than I thought. This

Code: Select all

program test;

var Ccoef:real;
const NiCcoef=3E3;

begin
  Ccoef:=NiCoef;
end.

produces error 'Incompatible types (string[3] to real)'. If one moves the constant declaration to a unit (leaving main as before), error 'Incompatible types (?0 to real)' is reported. In both cases, placing minus sign in constant definition leads to 'improper use of of operator -' error.

- The 3E3 is no a valid real number format. It should be written as 3.E3 (there has to be a dot character preceding E). Also -3.E3 will work. However the compiler should have reported an error here. We will fix it.

[janni]

- We have agreed that this needs to be done thoroughly. This easiest was for us would be to forbid such action, but then some of you would eat us alive.

I would never...

- The 3E3 is no a valid real number format. It should be written as 3.E3 (there has to be a dot character preceding E). Also -3.E3 will work. However the compiler should have reported an error here. We will fix it.

It's apparently a valid format for the editor, which color-codes the constants. On any priorities list, this would be at the far end, but sometime in the future it should also be cleared-up.

[srdjan]

- We have agreed that this needs to be done thoroughly. This easiest was for us would be to forbid such action, but then some of you would eat us alive.

I would never...

- Maybe, you would not, but I do not know about the others... Anyway, let it be as it is for now. You can always not use such code.

- The 3E3 is no a valid real number format. It should be written as 3.E3 (there has to be a dot character preceding E). Also -3.E3 will work. However the compiler should have reported an error here. We will fix it.

It's apparently a valid format for the editor, which color-codes the constants. On any priorities list, this would be at the far end, but sometime in the future it should also be cleared-up.

- I have to correct myself. 3E3 is a valid number, 3.E3 is not. We'll fix the issue you have described. Also the highlighter will be fix not to highlight 3.E3 as a valid real number.
Sorry for the confusion. Totally my fault.

[srdjan]

Update,
we have decided to allow both floating point representations 3E3 and 3.E3. This issue is fixed and closed.