Proposed Changes to Compiler

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Proposed Changes to Compiler

· Posted: 27.04.2022 - 15:42 · #1

Consider the following

Code

{--------------------------------------------------------------}
{ Type Declarations }

type
  TTestStr = string[25];

{--------------------------------------------------------------}
{ Const Declarations }

{--------------------------------------------------------------}
{ Var Declarations }
{$IDATA}
var
  TestStr : TTestStr;

{--------------------------------------------------------------}
{ functions }
procedure Test1( pRec : TTestStr );
begin
  pRec := 'Fred';
end;

procedure Test2( var pRec : TTestStr );
begin
  pRec := 'Jim';
end;

procedure Test3( const pRec : TTestStr );
begin
  pRec := 'Sam';
end;

The current compiler will compile all three, but in Test3 the 'const' term is simply ignored.

This means that pRec uses 2 bytes of Frame in Test2, but 26 bytes of frame in Test1 and Test3.

In the next release 'const' will no longer be ignored.

Test3 will fail at

Code

pRec := 'Sam';

with a 'Left side cannot be assigned to'.

Also, with const, parameters longer than 2 bytes will be passed by reference, meaning that pRec in Test3 will consume 2 bytes of Frame instead of 26.

I will also be removing upper limit for serial speeds at a users request.

miparo

Administrator

Gender:
Location: Germany
Age: 58
Posts: 960
Registered: 09 / 2007

Subject:

Re: Proposed Changes to Compiler

· Posted: 27.04.2022 - 20:17 · #2

Hi Merlin
Super. :angel11:

Const parameters had never worked before.!

Whereby most are not aware of the difference.

miparo

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Re: Proposed Changes to Compiler

· Posted: 28.04.2022 - 18:17 · #3

I will also be implementing 'default parameters' in the next release.

Previously

Code

{--------------------------------------------------------------}
{ Var Declarations }
{$IDATA}
var
  Test : word;

{--------------------------------------------------------------}
{ functions }
function TestInc( x : word; pRec : word = 1 ) : word;
begin
  return( x + pRec );
end;

{--------------------------------------------------------------}
{ Main Program }
{$IDATA}

begin

  EnableInts;

  loop
    Test := TestInc( Test );
    Test := TestInc( Test, 4 );
  endloop;
end Test3.

would fail (effectively the parameter modifier '= 1' would be simply ignored so the first call to TestInc would fail). After the next release it will succeed and work as expected.

Cannot be used in combination with var or const parameter keywords. Also complex types such as record or array are not supported (but string is).

Regards

UPI

Subject:

Re: Proposed Changes to Compiler

· Posted: 30.04.2022 - 16:15 · #4

Hello Merlin,

very good idea and thanks for removing the baudrate limitation

Greetings
Udo

Avra

Schreiberling

Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002

Subject:

Re: Proposed Changes to Compiler

· Posted: 05.05.2022 - 10:35 · #5

const fully implemented
+1

pass const param by ref for 3+ bytes
+1

default params
+2

baud rate limit removal
+2

It would be nice to see someday an inline keyword for procedures and functions, and a compiler switch like {$inline on|off}

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Re: Proposed Changes to Compiler

· Posted: 05.05.2022 - 16:00 · #6

Thank you Avra.

Quote

It would be nice to see someday an inline keyword for procedures and functions, and a compiler switch like {$inline on|off}

This is a feature I want to add to the optimiser when I get back to it, but worked slightly differently. I think it is better suited to the optimiser than the compiler.

Some inlining is already done. If the procedure is very short in length it is inlined.

My implementation would check to see how many times a big function is used. If it is only once then I would inline it.

I guess your proposal addresses the intermediate situation when a function is used more than once and is too big to be inlined automatically but you are prepared to trade off size for speed, whereas the optimiser always goes for size at the moment. The answer to that would, I think, be to use the INLINE keyword. But be aware that just as in Delphi, this would be a request not an instruction. If fulfilling the request would take you over the code limit, for instance, it would want to ignore it (if I can detect that situation). There may be other situations where it is ignored too.

Currently if you try to use INLINE you get the error message 'INLINE not supported'. When the time comes I will consider how to handle this.

Avra

Schreiberling

Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002

Subject:

Re: Proposed Changes to Compiler

· Posted: 11.05.2022 - 08:38 · #7

Quote by Merlin

Thank you Avra.

You're most welcome!

Quote by Merlin

My implementation would check to see how many times a big function is used. If it is only once then I would inline it.

As you've noticed this is just a single use case.

Quote by Merlin

...use the INLINE keyword. But be aware that just as in Delphi, this would be a request not an instruction. If fulfilling the request would take you over the code limit, for instance, it would want to ignore it (if I can detect that situation). There may be other situations where it is ignored too.

I would not like compiler to be that smart and take decisions for me without notification. I would prefer to always stop compilation when code limit is reached, and then decide if I will completelly switch off inlining, or ifdef one or more inline groups for fine code size tuning.

Thanks for considering!

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Re: Proposed Changes to Compiler

· Posted: 11.05.2022 - 10:01 · #8

Quote

I understand.

Proposed Changes to Compiler

Registered users in this topic