Generate C code using quasiquotation library

ssm-lang / Scoria

This is an embedding of the Sparse Synchronous Model, in Haskell!

BSD 3-Clause "New" or "Revised" License

4 stars 0 forks source link

Generate C code using quasiquotation library #9

Closed j-hui closed 3 years ago

j-hui commented 3 years ago

Overall, a few changes:

The 4-byte integer is now type aliased to int32 rather than using the native int. This makes clear the size of the type, and also avoids using the C keyword int in the place of an identifier (and streamlines the type naming scheme too).
The generated code no longer uses gotos to simulate if and while statements. Instead, the case labels are directly inserted into C's conditional and loop statements. This should be functionally equivalent.
The priority calculation arithemtic during fork statements is inlined rather than declaring new temporary variables. This should be functionally equivalent.
Some of the debugging responsibility is pushed into the runtime library. Ideally, all of this should be handled outside of LowCodeGen; it shouldn't be the responsibility of the code generator to figure out what to print and when.

j-hui commented 3 years ago

I still need to merge in the Changed operator from 3c44426e9c2f91c56c132ae87064fdf4eee3baf8. I'll do that tomorrow.

j-hui commented 3 years ago

I merged the Changed operator from master, and this seems to be passing valgrind tests, but it's not passing the prop_correct tests.

@Rewbert , what's the workflow for debugging that? It just dumps a program but I'm not really sure where to find the compiled .c file and inspect it myself etc.

j-hui commented 3 years ago

Oh and of course, I still need to document this entire file. That should happen before this PR is merged

Rewbert commented 3 years ago

So you issue stack test and it will start randomly running programs against your property. When it finds a program that fails the property it will shrink it and then dump it to a few files. E.g if the property failed it will dump them to fail.c, fail.out and fail.ssm. fail.c is just the generated code, fail.out contains a prettyprint of the traces of the two runs, so that you can see where they performed differently. fail.ssm contains a show'd version of the program. If you issue stack install you can then run print-ssm-from-file fail.ssm and it will show you a prettyprinted version of the program.

Similarly, it will create comperror.c & comperror.ssm if the program did not compile without errors/warnings, execerror.c & execerror.ssm if the program was compiled but crashed during execution (e.g by an assertion failing). Finally, parseerror.c & parseerror.ssm, if it could run the program but then not parse the results to a format Haskell understands.

j-hui commented 3 years ago

I fixed that bug, and tests are passing! Your suggestion was correct---it was a formatting issue after all. I also added a bunch of documentation to this module.

There are still some changes I would like to make to this module, but probably for a later PR/task.

Rewbert commented 3 years ago

I let the tests run for a while and found two bugs, which I've fixed above! Now I can run the tests and several thousand of them passes. I see no reason why we could not merge this PR now :)