Try-Finally-end; & Exit??

[balabuev 97]

7 minutes ago, Dalija Prasnikar said:

You are right, I forgot that there could be code in the loop after the finally, which requires additional jump. 

You are wrong. Can you provide sample code, in which a single Break will require more than one jump? I mean the code in which I can comment the Break and compare generated asm.

[Stefan Glienke 1905]

Could a goto out of a try block be supported - yes. It would require properly transferring control to the finally blocks and then transferring control to the target label. This would require significant work in the compiler. Given how popular the use of goto is, that would be a complete waste of resources.

 

See how the C# spec defines the behavior of a goto out of a try block: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#13104-the-goto-statement

Edited November 17, 2023 by Stefan Glienke

[Dalija Prasnikar 1341]

3 hours ago, balabuev said:

I cannot imagine, where the difference come from. Moreover, handling finally is a "call", not jump. So, what Break do, is a single "call" to handle each exiting try/finally, and then - usual jump.

 

 

The jump to finally happens behind that call. If you use Continue, the jump will become more obvious.

3 hours ago, balabuev said:

So, goto should do the same.

File a QP report if you think it is important to have it.

 

4 minutes ago, balabuev said:

You are wrong. Can you provide sample code, in which a single Break will require more than one jump? I mean the code in which I can comment the Break and compare generated asm.

 

You can use any code you wish. Like I have already said, I was wrong that there is only single jump involved for the Break and Continue. 

[balabuev 97]

1 minute ago, Stefan Glienke said:

It would require properly transferring control to the finally blocks and then transferring control to the target label

It would require transferring control to the finally blocks just identically to Break and Continue - One "call" instruction for each exiting finally and one unconditional jump.

[Stefan Glienke 1905]

It's cute that you only have x86 in mind when discussing this.

[balabuev 97]

2 minutes ago, Dalija Prasnikar said:

The jump to finally happens behind that call.

Things, which happens inside finally handling block is not relevant to the discussion, because it happening independent of what exactly causes finally code to execute. It may be Break, it may be exception raising.

 

6 minutes ago, Dalija Prasnikar said:

Like I have already said, I was wrong that there is only single jump involved for the Break and Continue. 

If we speak about "involved" - yes, several jumps are involved. But, this is a nature of try/finally. They are equally emitted for any finally block, and involved even when finally is executed because of exception raising - the main reason for "finally" to exist. So, these jumps are not even related specifically to Break or Continue.

 

However, we mostly discussing here enchancing of the compiler - the newly required functionality is matter, not existing currently. So, I claim that to support goto with finally(ies) the emitted code will not be in any way more complex than it is now for Break. Specifically, a single "call" instruction for every exiting finally, and a single unconditionnal jump instruction.

 

To be honest, managed local variables in a destination scope complicates the thing, but this is a separate, independed of try/finally aspect.

 

 

[balabuev 97]

23 minutes ago, Stefan Glienke said:

It's cute that you only have x86 in mind when discussing this.

You right, but I think other platforms work similarly. Can check in Win64 and Android. But, what is more important is that it's absolutely identical to Break or Continue, and because of that it will not require, as you said, "significant work in the compiler".

23 minutes ago, Stefan Glienke said:

See how the C# spec defines the behavior of a goto out of a try block

Yes, I wanted to mention that also.

Edited November 17, 2023 by balabuev

[David Heffernan 2300]

Why are you arguing. Surely you have an actual problem to solve. Why don't you just do that. You know all you need to know now. 

[balabuev 97]

2 minutes ago, David Heffernan said:

Why are you arguing. Surely you have an actual problem to solve. Why don't you just do that. You know all you need to know now. 

Actually, I occasionnaly found my old post with possible combinations of try/finally and try/except and gotos. Re-read it, and found that all cases are ok, except of one. After that I simply followed comments in the topic 🙂. It's strange to me that people here do not want to make the language more self-consistent, especially in this particular case, where not big amount of work in the compiler is required.

[Stefan Glienke 1905]

16 minutes ago, balabuev said:

It's strange to me that people here do not want to make the language more self-consistent

I do, but I know a dozen other things I would rather like to have, and know most of them have been reported for almost a decade or longer and nothing has happened about them - such as this no-brainer.

[Kas Ob. 91]

8 minutes ago, balabuev said:

It's strange to me that people here do not want to make the language more self-consistent

No, you are wrong here, sorry, we love Delphi and we love the Language and the IDE, but ( talking for myself)i don't trust Embarcadero to make it better, based on history and experience.

10 minutes ago, balabuev said:

especially in this particular case

No saying this is less than any other cases, but me to would love to see it better and better for each and every cases, the thing is the compiler in big part is still belong to early 90s from TP7, asking for this is like asking plastic car toys to build spaceship to go to space as they already understand something about motion.

13 minutes ago, balabuev said:

where not big amount of work in the compiler is required.

It is big, the compiler is so outdated, that will need huge adjustment to produce such code right, break and continue the current Delphi compiler know the breaking point before hand, with goto and the need to enter the finally and exit it without losing all the content of CPU register and variables, is again like the example above with plastic car toys, (used cars example because Uwe love those)

 

@balabuev and don't get me wrong i agree 100% it is doable, but for me it is not priority.

I would love if the Embarcadero Delphi compiler could generate good code for A+B like B+A, which IS NOT capable to do in 2023!

[Kas Ob. 91]

@Stefan Glienke Please research this and report it.

1 minute ago, Kas Ob. said:

Delphi compiler could generate good code for A+B like B+A,

for integers, yes for integers and their family.

 

ps : tested and known to fail to do so in Delphi's up to Seattle .

[balabuev 97]

If we speak about priority, then I agree, goto is not a frequently used feature. And goto with try/finally - even more rare :). 

 

9 minutes ago, Kas Ob. said:

It is big, the compiler is so outdated

They created code generation for other platforms, like x64 and Android. They added anonimous methods and inline variables - features much more complex than the discussing "goto". So, I understand the answers, like "its not a high priority thing". But, I cannot understand the answers like "its impossible/hard to implement" or "ooo, it will require one additional conditional jump" :) Who cares really about one additional jump?..

 

I'm personally would prefer that they fix "undo" functionality in the code editor. Code editor, like compilers, is the heart of the IDE...

[Kas Ob. 91]

4 minutes ago, balabuev said:

I'm personally would prefer that they fix "undo" functionality in the code editor. Code editor, like compilers, is the heart of the IDE...

That i agree on, as i started to steer the topic away, and i am sorry.

 

29 minutes ago, Kas Ob. said:

@Stefan Glienke Please research this and report it.

32 minutes ago, Kas Ob. said:

Delphi compiler could generate good code for A+B like B+A,

for integers, yes for integers and their family.

 

ps : tested and known to fail to do so in Delphi's up to Seattle .

I am in no place to ask this, so sorry too.

 

but if you want to research and confirm it, then please, it might help the performance in few (thousands) places.

Code to reproduce this piece of gem with optimization on of course, we need the best code, only the best

function AddAB(A, B: Integer): Integer;
begin
  Result := A + B;
end;

function AddBA(A, B: Integer): Integer;
begin
  Result := B + A;
end;

procedure TForm10.FormCreate(Sender: TObject);
begin
  AddAB(10, 5);
  AddBA(12, 8);
end;

And the assembly 

 

Again sorry @Stefan Glienke but that one of many that really boil my blood and it is almost everywhere.

[Stefan Glienke 1905]

That code only wastes 2 bytes of binary code because the CPU will most likely apply register renaming and mov elimination (yes, there is some cost for decoding the unnecessary mov). But from all the possible optimizations in the x86 and x86-64 codegen this is one of the least important ones I can think of. FWIW x86-64 code will emit the lea instruction for both.

Edited November 17, 2023 by Stefan Glienke

[David Heffernan 2300]

1 hour ago, balabuev said:

It's strange to me that people here do not want to make the language more self-consistent, especially in this particular case, where not big amount of work in the compiler is required.

None of us can do this though. Why are you posting here instead of submitting a QP request? We aren't the people you need to convince. 

[Kas Ob. 91]

17 minutes ago, Stefan Glienke said:

But from all the possible optimizations in the x86 and x86-64 codegen this is one of the least important ones I can think of.

The thing is.. it is the same line so this window if optimized or just checked for one thing and one only, switching the register and see if the an instruction can be omitted, it will have some impactable performance everywhere, also in x64 which it does nice lea code because three registers involved, but fail in many different places when like that simple integer addition if one register is already used, like when the addition is in the middle of code.

[Stefan Glienke 1905]

What you actually want to say is that the register allocator is bad (and that also applies to Win64) - which I agree with and has been reported repeatedly. However, pointing out one of the thousands of different specific cases is not getting us anywhere. Especially since there are way more impactful situations where this causes excessive stack spilling.

[Kas Ob. 91]

Sure, but i don't think they can fix this for one single situation like addition without fixing or rethinking the register allocator, at least that what i hope for, after all nothing stopping them from doing anything.

[balabuev 97]

43 minutes ago, David Heffernan said:

Why are you posting here instead of submitting a QP request?

No sense to report QP.

 

[Dalija Prasnikar 1341]

1 hour ago, balabuev said:

additional conditional jump

Because conditional jump requires more logic in compiler than simple single jump. Yes, there are other more complicated things in the compiler, that is besides the point. We are talking about goto command which is rarely used and often even considered obsolete. While it has its use cases, extending the goto functionality is really the last thing we need. In that context how complicated feature might be matters. That is why I (erroneously) opened discussion with how many jumps it needs and this could have been a reason why using goto to jump outside try...finally was not implemented.

[Sherlock 632]

Just as a totally unqualified insertion: We are talking about the GOTO statement right? The one Dijkstra is rotating in his grave about? Ok, just checking. Carry on....

[Kas Ob. 91]

23 minutes ago, Sherlock said:

Just as a totally unqualified insertion: We are talking about the GOTO statement right? The one Dijkstra is rotating in his grave about? Ok, just checking. Carry on....

https://english.stackexchange.com/questions/107785/is-there-a-clean-version-of-no-sht-sherlock

 

I am really sorry, i just couldn't resist 

Hope it make you smile 

[balabuev 97]

3 minutes ago, Dalija Prasnikar said:

In that context how complicated feature might be matters.

Well, if Embarcadero afraid every single conditional jump, I have nothing more to say. However, even this additional stuff, which has been noted several times, have not been explained. Seems to me invented on-the-fly...