v 4.80 Beta: Assigning float to integer allowed - bug

[sasa72]

Following code is compiled with warnings only:

Code: Select all

var
  i: integer;
  rr: real;
begin

  i:= 19.87654321;    // i=19
  rr:= 19.87654321;
  
  i:=rr   // i=19
  ...

Instead, compilation should be stopped with "Incompatible types" error.

Compiler assigns integer part (19) of float values. In both cases accepted syntax is incorrect - Pascal do not allow direct conversion from real to integer type. Further, in this case, code is very difficult to maintenance and keep semantically correct.

[janni]

You're right, mP indeed replaces strict type-checking with implicit typecasting. One may not like it as it leaves space for mistakes (though warnigs are issued), but mostly it simplifies programming and code space is precious in small processors.

In fact, I don't remember anyone protesting so far , but anybody with fresh mind is welcome to point out things others may have got used to and do not notice anymore. I'm sure mE will also appreciate that.

There are other spots in mP that do not go along with Pascal definition, but some of them were introduced on user requests or are a compromise to which users agreed (like the case discussed). Still, there are things many of us would like to see changed or implemented, but mE cannot (and sometimes would not - especially if it would make mP differ too much from other compilers) spare the effort to fulfill our wishes. Feel free to place suggestions or actively support others in the common effort to better mP .

[sasa72]

Unfortunately, I have had no time to read or search the forum more carefully. Feel free to point on discussion you refer.

As a senior programmer mostly spent professional life programming in Pascal and Delphi, I simply do not appreciate much radical syntax/semantic language difference, since that will asks too much time in debugger for a bit more complex code and especially during code optimization.

In this matter, reducing resulted code should be compiler's optimizer task, keeping source code syntax rigid as much is possible to avoid any problems (keeping track in compiler's log is very demanding).

Since this issue was discussed already, just additional suggestion: adding an "Strict syntax check" in compiler options regarding similar issues will be useful compromise. Implementation should be trivial.

[janni]

Unfortunately, I have had no time to read or search the forum more carefully. Feel free to point on discussion you refer.

Well, discussions flame and die out. The most intense discussions lately concerned expression evaluation rules and presence of booleans (the latter were for some time removed from mP and mB compilers - they're still absent in mP PRO manual).

Present expression evaluation rules are a compromise between ease of use and saving limited processor resources but there are still differences between runtime and compile-time calculations, and boolean is not a real type (it's in fact identical with byte). If you need more starting points for discussion, there is the for..to loop where final value expression is evaluated every loop and continue statement is followed by loop counter increment. Some libraries resemble C more than Pascal, etc. etc.

As a senior programmer mostly spent professional life programming in Pascal and Delphi, I simply do not appreciate much radical syntax/semantic language difference...

Who does? It would be ideal, if one could switch from platform to platform following one set of rules. The sad truth is that Pascal is not a popular language in embedded world and there's very little choice, if any, when one looks for Pascal compilers. And small processors also limit the programming language - what would be the use of a beautifully written object Pascal compiler, if, due to ROM and RAM limitations only very simple programs could be written?
What I'm driving at is that one has to make some compromises and you'll find them in mP, but by no means one has to stop expecting reasonable improvements.

Strict type checking as an option would be welcome, beginners would certainly appreciate it and more demanding users could always switch it off when code space becomes scarce or for writing optimised libraries.

There's a place for posting such suggestions - it's mP PRO for PIC Wishlist forum. Please post your proposal there for mE to find it.

[sasa72]

AFICS, there is much space to improve optimizer, which is the main figure to produce smaller and efficient code. I already sent to mE team several suggestions regarding optimizer improvements about month ago, including other suggestions regarding IDE (some of them are already implemented in v 4.80, as is project wizard small tweaks to simplify creating new project)... I may translate it later when find some spare time and post some of them which may be of interest for community to discuss...

In short, despite MCU PIC platform, RISC architecture, limited ROM and RAM, etc., Pascal with further improving of optimizer, can produce fast, small and efficient code comparing equivalent code written and compiled in C or perhaps even in pure ASM (in some cases, though).

[janni]

I may translate it later when find some spare time and post some of them which may be of interest for community to discuss...

That'd be interesting.

In short, despite MCU PIC platform, RISC architecture, limited ROM and RAM, etc., Pascal with further improving of optimizer, can produce fast, small and efficient code comparing equivalent code written and compiled in C or perhaps even in pure ASM (in some cases, though).

There's nothing special in C, besides popularity , only compilers are better or worse.

[sasa72]

That'd be interesting.

One of suggestion is allowing overload method. As number of libraries grows it will rise need for different version of the same functions which woks slightly/moderately differently/faster according to their types. Let see your abs() function for example. Calculating error in iterations need mostly real type, in other situations integer/long etc - with a mentioned "problem" implicit typecasting involving, it is necessary to create and use a family of abs*() functions, which is not very practical.

The second may be followed: if constants are arguments of math functions (as well involving expressions), result can be calculated by compiler, leave readability of code and improve maintenance.

The third may be about optimizer: to ignore variable/code which produce no effect. At least warning would be also helpful. Work on MCU with more ROM would be easier, at least for maintenance and code cleaning.

There's nothing special in C, besides popularity , only compilers are better or worse.

For those write no "cryptic" code to "help" compiler to optimize code properly, there is no big difference.