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.
mP 7 - bugs
Re: mP 7 - bugs
We will fix this, thanks.
Re: mP 7 - bugs
Fixed and optimized. Now it has only two assembler instructions.janni wrote:The duplicate label errors I've found so far (PIC18 libs):
1. system.mcl - swap
Fixed.janni wrote:2. math_double.mcl - JPKSETIOV3224
System.mcl, fixed.janni wrote:3. stringsLib.mcl - length
Thanks for the reports.
Re: mP 7 - bugs
Now, that's something I like .srdjan wrote:Fixed and optimized. Now it has only two assembler instructions.
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.
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:janni wrote: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.
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.
Thanks, srdjan. You did more than I hoped for .
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.
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.srdjan wrote: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..
This one is even weirder than I thought. ThisOne 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.
Code: Select all
program test;
var Ccoef:real;
const NiCcoef=3E3;
begin
Ccoef:=NiCoef;
end.
this works however :
seems there is some misinterpretation of the const value unless you explicitely tell what the type is.
Code: Select all
program test;
var Ccoef:real;
const NiCcoef: real =3E3;
begin
Ccoef:=NiCcoef;
end.
- 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.janni wrote:Thanks, srdjan. You did more than I hoped for .
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.srdjan wrote: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..
- 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 wrote:This one is even weirder than I thought. ThisOne 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.
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.Code: Select all
program test; var Ccoef:real; const NiCcoef=3E3; begin Ccoef:=NiCoef; end.
I would never...srdjan wrote: - 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.
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 wrote: - 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.
- 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.janni wrote:I would never...srdjan wrote: - 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 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.janni wrote: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 wrote: - 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.
Sorry for the confusion. Totally my fault.