General strategy for handling return instructions and JUMP elements needed

[codemanyak]

1. In order to enable subroutine CALLs (issue #9), a coordinated strategy for the handling of return statements and JUMP instructions is necessary. For the handling of return instructions the following strategies may be considered: a) immediate return from the procedure with the given result (consistent with C, C++, C#, Java etc., cf #21); b) Just a preset of the result value (equivalent to assignments to the function name or a variable named "result", "Result", or "RESULT") which was more or less what the Structorizer behaviour before bugfix KGU#77 might have been interpreted as). In case of a) it actually represents an unstructured exit and should hence be placed in a JUMP element if it's not the very last and unconditioned instruction of the entire diagram. A new Analyser task would be to produce a warning if "return" instructions occur in ordinary instruction elements other than the very last one. In case of b), however, there are several concurring mechanisms to preset the result value, which would make sensible a new Analyser task to check if several of them occur in the same diagram. c) The flexible approach would be to let "return" have the effect a) if placed within a JUMP element and the effect b) otherwise.
2. This raises the question how to handle JUMP elements if they don't contain return instructions. The following semantic alternatives (including the return problem stated above) seem sensible: a) return instruction (as described above); b) break instruction to leave the nearest enclosing loop (being equivalent to "leave 1" according to c) below); c) multi-level leave instruction with a constant positive integer argument (to exit the specified number of loop levels - difficult to translate by the Code Generators!); d) exit instruction (with some integral argument) to exit not only the current subroutine but the entire program - i.e. end the execution). The JUMP element might / should be required to contain just a single instruction line representing one of the types listed above rather than an instruction sequence. Considering the options a) through d) above, it ought to be decided whether to use hard-coded keywords or to add JUMP-related configuration items to the ParserPreferences dialog, where b) and c) might be represented by the same keyword with argument 1 as default - if multilevel leave instructions are granted at all. New Analyzer tasks might be added in order to check whether the specified leave level is sound at all.
3. The code Generators will then have consistently to deal with the specified strategy (cf. issue #22).

[codemanyak]

Mostly done. Some of the code generators will have to be updated or tuned a little. Prototype available in branch codemanyak/Structorizer.Desktop/master. Keyword configuration still waiting for request.

[codemanyak]

Generators prepared to cope with Jump instructions (as far as possible)

• [x] C generator and descendants (C++, C#, Java)
• [x] Pascal generator
• [x] Oberon generator
• [x] Basic generator
• [x] Shell generators (KSH, BASH)
• [x] Perl generator
• [x] Tex generator
• [x] PHP generator
• [x] Python generator

[codemanyak]

Executor and all generator updates ready, only waiting for release integration.

[codemanyak]

Mechanism for Oberon actually introduced, processing of empty jumps fixed for Pascal (due by version 3.23-15)