Can't understand simple program result

[440bx]

Now, VTwin, can you elaborate on that ?  In practise, what is the delivered value of const ?

"const" has one very nice "side effect".  By letting the compiler know that the parameter value won't change (it's "const") and, depending on the parameter, the compiler doesn't need to make a local copy of the parameter on the stack.  Note: pass by value is implemented by making a local copy on the stack, if the parameter is "const" then that local copy is not necessary.

For example, suppose I had a function that took a parameter and will need to either change that parameter or declare a new local variable, which produces faster, small, sweeter code ?

In the example you showed, BlarTwo generates smaller code (and a tiny, tiny little bit faster because it doesn't have to assign the parameter value to the local variable.)

The doc, somewhere, infered that using const and making X read only somehow makes for smaller, faster code but is the gain greater than the loss implied by having to declare a new local var and assign X to it ?

That is true when the parameter being passed by value does not fit in a register, otherwise, it doesn't make any difference.  If the parameter fits in a register then the register is a copy of whatever value was assigned to the parameter.  If the value does not fit in a register and, the parameter is not declared as "const" then the compiler will make a local copy and act on that copy, making that copy requires the compiler generate the code for it and the CPU spend time executing those instructions.

HTH.

[dbannon]

look after the microseconds and the seconds look after them selves !

(old adage that some members may not be familiar with "look after the pennies and the pounds will look after them selves", where I come from, we have not used pounds for 50 years !)

Seriously, I consider performace is something that needs to be considered constantly. In the examples I quote above, there really is no difference in effort, if I knew some golden rule that says one is better than the other, I would use it as no cost.

And I come from a HPC background, big, very expensive supercomputers. We would kill user jobs that were not running efficiently.....

Davo

[dbannon]

Great, thanks 440bx, its what I would have guessed but nice to confirm.

So, my (one line) rules might be -

If the parameter being passed to a function/procedure -

* won't change then set const.
* will be used as a local var in the function/procedure for efficency, set nothing
* already has a value needed by the func/proc and will be used to pass something back to caller, set var
* is just to bring something back to caller, set out

Hmm, nice !

Davo

[440bx]

Great, thanks 440bx, its what I would have guessed but nice to confirm.

You're welcome.  Glad to help.

If the parameter being passed to a function/procedure -

* won't change then set const.
* will be used as a local var in the function/procedure for efficency, set nothing
* already has a value needed by the func/proc and will be used to pass something back to caller, set var
* is just to bring something back to caller, set out

You got it.  I see #3 and $4 are the "cautious" approach <chuckle>. 

[VTwin]

440bx answered the benefit, giving the compiler some useful information.

I also prefer not to reuse an input parameter as a local variable. To me it is more clear to keep them distinct. Just style I guess.

Of course that does not prevent you from doing something like this:

Code: Pascal  [Select][+][-]

1. type
2.   vector = array of double;
3.  
4. procedure MulBy2(const a: vector; out b: vector);
5. var
6.   i, n: integer;
7. begin
8.   n := Length(a);
9.   SetLength(b, n);
10.   for i := 0 to n-1 do
11.     b[i] := a[i] * 2.0;
12.   a[0] := b[0]; // oops!
13. end;

[MarkMLl]

* won't change then set const.
* will be used as a local var in the function/procedure for efficency, set nothing
* already has a value needed by the func/proc and will be used to pass something back to caller, set var
* is just to bring something back to caller, set out

Exactly, which were the points I tried to make but which Thaddy took offence to.

My recollection from Delphi discussions is that  const  is particularly important for strings: I can't remember the detail but it was something to do with preventing an extra local copy being created.

MarkMLl

[PascalDragon]

Fortunately, I don't see the nonsense about discarding the value of "out" parameters ever being implemented because the compiler has better thing to do than waste its time generating code to trash parameters.

The language reference allows implicitly:
outparam := 3; // whole statement can be removed by optimization (because unused in next call)
func( outparam); // outparam must! be set inside to get a defined value

That is indeed a very good example what the compiler is allowed to do thanks to the definition of out parameters. Currently the compiler does not do that, but I'm definitely inclined to implement this just to mess with 440bx's assumption that it's always the implementation that trumps and not the documentation / language specification.

[Bart]

Currently the compiler does not do that, but I'm definitely inclined to implement this just to mess with 440bx's assumption that it's always the implementation that trumps and not the documentation / language specification.

+1

Bart

[lucamar]

the procedure could internally use the parameter passed by value as a local variable - it would be "weird"/strange but, not illogical.

I tend to do that quite a lot so I must be weird/strange. Wel, at least I'm not illogical

Oh! Thanks for the explanation re. var vs. inout, etc.

[440bx]

Currently the compiler does not do that, but I'm definitely inclined to implement this just to mess with 440bx's assumption that it's always the implementation that trumps and not the documentation / language specification.

Fortunately, it won't affect me.  It will simply give me one more reason to stick to FPC v3.0.4. 

OTH, if you wanted to be really cruel then you'd have to "back implement" it in v3.0.4 but, you're not like that

I tend to do that quite a lot so I must be weird/strange. Wel, at least I'm not illogical

Oh! Thanks for the explanation re. var vs. inout, etc.

You're welcome and you're right, there are plenty of cases where there is nothing strange about using parameters as local variables.  When I wrote that, I was thinking about the fact that the caller could pass a parameter just for it to be used as a local variable in the callee.  That is weird but, perfectly fine.

[dbannon]

I really hope cris75 has got something out of this discussion, it went way beyond what he/she asked. But turned into a really interesting thing !

...... which were the points I tried to make but which Thaddy took offence to.

My recollection from Delphi discussions is that  const  is particularly important for strings: I can't remember the detail but it was something to do with preventing an extra local copy being created.

Yes, that would make sense, strings and other managed vars are quite a different model than poking an int into a register. I am going to start being very careful to apply const to passed strings where ever I can. And I would not worry about upsetting Thaddy, he once called me a die-hard windows user and never apologized 

@VTwin - agreed, it would be bad style to use a passed parameter var as a local var for uses unrelated to its original purpose. Would make code a lot harder to understand, and it would not gain much anyway.  But using it for something where it already has an appropriate initial value, good !

@440bx - sorry, deserting you. While it works now, I'll not assume it will work forever. Who know, maybe PascalDragon will sneak a change in just to see if we are paying attention !   

Thanks folks, I feel so much more on top of that issue now. Just hope cris75 is still with us.....

(Might put a little summary on the wiki)

Davo

 

[440bx]

@440bx - sorry, deserting you. While it works now, I'll not assume it will work forever. Who know, maybe PascalDragon will sneak a change in just to see if we are paying attention !   

It's ok Davo, I understand.  There is something to be said for playing it safe.  I do (most of the time )

[VTwin]

That is indeed a very good example what the compiler is allowed to do thanks to the definition of out parameters. Currently the compiler does not do that, but I'm definitely inclined to implement this just to mess with 440bx's assumption that it's always the implementation that trumps and not the documentation / language specification.

 

The argument is clear. Relying on undocumented features is a fool's game that will bite you in the end, with bugs hidden deeply in code.

[440bx]

The argument is clear. Relying on undocumented features is a fool's game that will bite you in the end, with bugs hidden deeply in code.

I think that's a little too simplistic.  For FPC v3.0.4, it's rather unlikely that is going to change.   You test and look at the code the compiler generates in every case.  Once you've done that, you can rely on the behavior until you decide to upgrade to a new version.

That's also true for other things.  For instance, in the case of Windows, there are times when relying on undocumented features is the only way to implement a feature.  Of course, code that uses undocumented features like that should include sanity/assert checks to ensure that it is getting what it expects.

In the specific case of "out" parameters, trashing the "out" parameter is simply bad compiler design.  When a programmer sets a variable to some value, the programmer is fully entitled to expect the variable to hold that value.  Anything else is a little too "creative".

[nanobit]

trashing the "out" parameter is simply bad compiler design.  When a programmer sets a variable to some value, the programmer is fully entitled to expect the variable to hold that value. Anything else is a little too "creative".

If you want to keep the old value, do you also complain
that managed-type outparams are auto-"trashed" (released).
And what about records which contain references and are auto-finalized.