usage of arrays can result in large generated c files

[frameworklabs]

Describe the bug

When I declare a variable which is an array of say 1024 nat8 in an activity, the generated code contains 1024 assignments:

static blc_pc_t blc_main (blc_nat8 blc_main_v[1024], blc_pc_t *pc_1) {
    loopHead:
    if ( *pc_1 == 2 ) {
        memset(blc_main_v, 0, 1024 * sizeof(blc_nat8));
        blc_main_v[0] = 0;
        ... a lot of repetitions here...
        blc_main_v[1023] = 0;

This is not the case when I declare a variable of 1024 float32.

Independent, the printState function seems to be quite bloated too:

    printf("\t\t\t\t\t");printf("%hu", blc_main_v[0]);
    printf(",\n");
        ... a lot of repetitions here...
    printf("\t\t\t\t\t");printf("%hu", blc_main_v[1023]);

To Reproduce

@[EntryPoint]
activity main()
  var v: [1024]nat8
  await false
end

Expected behaviour More compact code.

Screenshots %

Additional context %

[FriedrichGretz]

Thank you for the report. I confirm the code generation produces different results for nats and floats. We will look into that.

Regarding the print function: this is correct as is. The purpose of the trace printer is to generate a JSON representation of the memory contents (after each reaction step). For this every struct or array (or combination thereof) is broken down to its atomic subelements which are then printed.

[frameworklabs]

Could the print function use a for loop instead as every element of an array should be of the same type.

If I have an array the size of a screen buffer (1024x1024 pixels) this could lead to 1 million lines of c code :-o

Maybe also have an compiler option to disable generation print functions?

[schorg]

For the moment the printState function is just a quick way of testing the code generation. Blech programs are deterministic concerning the state after each reaction. Changes to the code generation should not change the behavior. Comparing old and new trace files guarantees this.

Tracing should become a part of a test framework, which still has to be designed. The upcoming module system with separate compilation for modules is a pre-requisite for this.

A compiler switch to disable generation of print functions in the meantime is a good solution.

[frameworklabs]

If you have not started with the compiler switch I can give it a try and provide a PR for it - getting some F# experience ;-)

[FriedrichGretz]

@frameworklabs that would be really nice, go ahead :) The code that deals with generating the various code fragments is a bit convoluted at the moment, so feel free to ask if you start getting lost.

[schorg]

@frameworklabs: There is already a command line parameter trace - see Arguments.fs and blechc --help. It should switch the printState function on. Currently the code generator does not test this and always generates the printState function - see CodeGeneration.fs

[frameworklabs]

Thanks for the pointers! With this it should be quite straight-forward to implement it.

[FriedrichGretz]

Fixed as of 79bf0d0cff4ad82e848d451057450b249787a652 on develop branch.

[FriedrichGretz]

Fixed with Release 0.6.0