Standard function support

[ghaith]

The IEC61131 standard defines some conversion functions as builtin. How should we support these functions?

Examples would be :

• ADD
• MUX
• XXX_TO_YYY conversion functions
• String concatenation functions
• String conversion functions
• REF (ADR in codesys) for reference/pointer adresses.
• ...

I suggest writing these in a library that is always included.
Such an "std" library could eventually also be repurposed to define the standard data types.

[ulmer-a]

I quite like the idea of a separate library that is always included 👍

[ghaith]

@riederm Ideas?

[riederm]

Definitely a good idea so we can even have different standard libs for different versions and/or targets.

Should this be its own repository or do you suggest it as part of this repo?

[ghaith]

I think it has to be a mix.
I'm looking at the functions in the standard and many of them require the ANY_XXX or ANY type.
I think the best way would be to solve these functions at compile time using predefined templates that we would fix for the correct types.
The conversion functions could still go to a different repository if needed.
I think the function blocks (TON/R_TRIG...) belong in a different repository.

[ghaith]

To go back to the initial idea of having them replaceable, I think some of those functions have to be built in:

• ADD, SUB, DIV, MUL, MOD, ADR, REF are already added, just with different operators
• ADD and MUL should support variadics, however.
• MUX, SEL, and MOVE are fixed across targets, they also require the ANY type
  The rest could be separated and solved with a generic for the ANY_XXX type.

[JoelLinn]

*_TO_** are pretty basic and would eventually be translated to some llvm type-cast IR (plus rounding mode tweaks as REAL_TO_INT(-1.5) is -2, whereas it is -1 in C)
I don't see what is target specific about those simple functions.

Of course a function like ADD is defined in ST quite easily.
Also function blocks like TOF, TON, etc. can be defined in ST but they indeed do require functions to retrieve timestamps.
Timestamps is something which llvm can not or does not provide, so that is one thing which is in fact target specific.

To wrap it up, I think a lot of functionality in the standard library is target independent while some very basic functions need in fact be interchangeable (i.e. for Linux, Posix or embedded targets like ESP32/moongoose os for example)

[ghaith]

Thank you for your input!

*_TO_** are pretty basic and would eventually be translated to some llvm type-cast IR (plus rounding mode tweaks as REAL_TO_INT(-1.5) is -2, whereas it is -1 in C) I don't see what is target specific about those simple functions.

Indeed, Datatype conversion functions should be relatively simple and I would assume could / would always be in-lined by LLVM.
Same applies for bit-wise functions defined by the standard (SHL/SHR/ROL/ROR)

Some functions, however, need more complex handling such as the Numeric / Arithmethic functions (COS/SIN/LOG...) and the String conversion functions.

Of course a function like ADD is defined in ST quite easily. Also function blocks like TOF, TON, etc. can be defined in ST but they indeed do require functions to retrieve timestamps. Timestamps is something which llvm can not or does not provide, so that is one thing which is in fact target specific.

I agree that some functions like MIN and MAX could be written in ST, as well as many of the datatype conversion functions, but some of the functions (ADD, AND, MUX, ...) define a variable number of parameters, and these would have to be written in C, or ST has to be extended to support using Variadic Arguments (We currently only support that on external functions)
Functions like MUX also require some kind of generic support.

Function Blocks like TON and TOF could also be ST if the required time functions are exposed from another language, but this still requires some kind of 'standard' lib.

I would opt to initially write the standard library functions in a more flexible language and then slowly move some parts to ST when enough building blocks are there if needed.
We can easily call native functions from ST with our current state as long as they are defined using a C calling convention. So a mix of different languages for the library would not be that alien here.

To wrap it up, I think a lot of functionality in the standard library is target independent while some very basic functions need in fact be interchangeable (i.e. for Linux, Posix or embedded targets like ESP32/moongoose os for example)

I would like to aim for a target independent implementation of a standard lib where possible. Maybe even split it up so functions that need system functions are separated and imported externally so that these functions can be re-implemented differently for embedded targets.