Commit Graph

61 Commits

Author SHA1 Message Date
d9cb506f6a nac3core: refactored for better error messages 2022-02-21 18:24:19 +08:00
bf52e294ee nac3artiq: RPC support 2022-02-12 22:50:32 +08:00
fa04768a77 redo "nac3core: fix #84"
This reverts commit 86005da8e1.
2021-12-27 22:56:26 +08:00
86005da8e1 Revert "nac3core: fix #84"
This reverts commit 0902d8adf4.
2021-12-26 08:35:27 +08:00
9e3f75255e update inkwell. Closes #67 2021-12-25 22:17:06 +08:00
0902d8adf4 nac3core: fix #84 2021-12-23 15:26:48 +08:00
ba08deada6 nac3core: refactor codegen 2021-11-20 19:50:25 +08:00
bf7e2c295a integrate nac3parser 2021-11-03 17:11:00 +08:00
bc0f82cad8 Revert "nac3artiq/codegen: fixed smax problem"
We have LLVM 12 now and can use the intrinsic.

This reverts commit 98d9f73afb.
2021-11-02 14:00:28 +08:00
98d9f73afb nac3artiq/codegen: fixed smax problem
It turns out the smax intrinsic I use is a new one that is not supported
in LLVM11. Now implemented with signed integer compare and select.
2021-11-02 11:10:21 +08:00
84c5201243 with parallel/sequential support
Behavior of parallel and sequential:
Each function call (indirectly, can be inside a sequential block) within a parallel
block will update the end variable to the maximum now_mu in the block.
Each function call directly inside a parallel block will reset the timeline after
execution. A parallel block within a sequential block (or not within any block) will
set the timeline to the max now_mu within the block (and the outer max now_mu will also
be updated).

Implementation: We track the start and end separately.
- If there is a start variable, it indicates that we are directly inside a
parallel block and we have to reset the timeline after every function call.
- If there is a end variable, it indicates that we are (indirectly) inside a
parallel block, and we should update the max end value.

Note: requires testing, it is difficult to inspect the output IR
2021-10-31 17:16:21 +08:00