Support for ARM code

[codemanyak]

Alessandro Simonetta proposed to add a generator for ARM code and (optionally) even to enhance the debugger to execute ARM code in a suited syntax (possibly via a DiagramController).

[codemanyak]

Prepared a branch issue967 as intermediate target for pull requests by contributors to this ER.

[codemanyak]

Fixed a highlight mapping problem between diagram and code preview.

[codemanyak]

Several unsatisfying aspects will still have to be fixed:

• [ ] A complete syntactical model of the source diagram is needed in order to decide how far a translation is feasible (currently the code generation is based on assumptions of a far more restricted syntax, causing exceptions, inconsistency, and other kind of trouble). At least token-based mechanisms are to be preferred over regex-based ones, ideally syntax trees should be used.
• [ ] Complex expressions (at least over integer types) should be decomposed into ARM sequences rather than be rejected or to cause exceptions (depending on an export option).
• [ ] A standard routine call paradigm is to be implemented, passing the first three arguments via registers R0, R1, R2, and all further arguments via the stack. A register (R12) should be reserved for the stack frame address.
• [x] It is to be checked in advance what registers (i.e. variables with names R0 ... R15) are explicitly used such that conflicts can be avoided as far as possible.
• [ ] If more variables are needed than registers being available, some standard swapping mechanism is to be applied. Subroutines should reserve space on the stack (addressed via R12 minus certain offset?), main programs may store their unmapped variables in memory (also preferrably addressed via R12?). It should be decided (or maybe configured via an option) whether all variables are generally to be allocated in memory or on the stack, respectively, or if only supernumerous variables are to be allocated on demand.
• [x] Array declarations have to be harmonized with Structorizer syntax rules. Type compatibility rules will be needed to allow array allocation. Currently, array initialization and assignments, even within in the apparent syntactic expectations of ArmGenerator produce a lot of nonsense:

[codemanyak]

Intermediate problems to be solved (just as reminder):

• [x] The condition check in REPEAT loops (analogous to IF statements and WHILE loops) is missing.
• [x] The condition check is too strict, at least single registers and (boolean) variables like R5 or isNice should also be accepted (meaning an implicit test for non-zero value), then of course the same should apply to a negated register or variable, e.g. !R5 or !isNice, respectively. Also we should allow and translate Boolean literals like true and false. All this is of course a heuristic incremental improvement not replacing the necessary full syntax tree approach.
• [x] Type definitions and mere variable declarations in Structorizer syntax must be skipped.

[codemanyak]

Debugging tools like CPUlator expect a global definition of a label "_start", which is to be placed on the first line of code of the program.

• [x] Such a combination might be generated by ARM generator (possibly requiring an export option?):

  .global _start
  .data
  ...
  .text
  _start:
  MOV R1, #4
  ...

  EDIT: In GNU mode, the "_start" label will be placed from version 3.32-04 on.

[codemanyak]

On occasion of bugfixes #1013 and #1014, the ARM syntax for arrays was changed from version 3.32-04 on such that it goes along with the rest of Structorizer (now an empty bracket pair must be appended to the element type as in Java declarations):

[codemanyak]

• [x] It may be sensible to add some ARM-specific syntax checks to Analyser (at least while there are ARM-specific syntactic constructs and limitations). A difficulty is of course that the generators are plugins, such that ideally the syntax check specifications (e.g. Regex patterns or grammar rules - or a path to a GOLDparser egt file?) should be provided via the XML-based plugin configuration. Might be related to #800.