lyken
/
nac3
forked from M-Labs/nac3
1
0
Fork 0
Code Pull Requests Activity
1,096 Commits 24 Branches 0 Tags 4.9 MiB
Commit Graph

1096 Commits

Author SHA1 Message Date
Sebastien Bourdeauducq afb94dd299 nac3artiq: move demo to dedicated folder 2021-11-05 18:28:31 +08:00
Sebastien Bourdeauducq d6f0607ff0 nac3artiq: rename class decorator to nac3 2021-11-05 18:08:36 +08:00
Sebastien Bourdeauducq 610448fa73 nac3artiq: include parallel in demo 2021-11-05 18:07:18 +08:00
Sebastien Bourdeauducq e8228710e7 min_artiq: remove unnecessary definitions 2021-11-05 17:50:26 +08:00
ychenfo 032e1d84cf nac3parser: add and fix tests due to comment support 2021-11-04 15:03:34 +08:00
ychenfo b239806558 nac3core: adapt to ast change due to comment support 2021-11-04 15:02:51 +08:00
ychenfo 694c7e945c nac3ast: generated ast with comment fields 2021-11-04 15:01:50 +08:00
ychenfo 3b1cc02d06 nac3parser, ast: add comment support core changes 2021-11-04 15:00:27 +08:00
Sebastien Bourdeauducq 32d1fe811b flake: update nixpkgs 2021-11-03 21:54:27 +08:00
Sebastien Bourdeauducq 36e4028f5b fix and run parser tests 2021-11-03 17:39:48 +08:00
Sebastien Bourdeauducq b6ff46c39e README: update 2021-11-03 17:22:14 +08:00
Sebastien Bourdeauducq bf7e2c295a integrate nac3parser 2021-11-03 17:11:00 +08:00
pca006132 48ce6bb6c5 rustpython-parser: string interner, optimizations, thread local cache 
corresponds to M-Labs RustPython fork at efdf7829ba1a5f87d30df8eaff12a330544f3cbd
branch parser-mod
 2021-11-03 16:36:28 +08:00
Sebastien Bourdeauducq 80c7bc1cbd add RustPython parser 
based on RustPython 67b338863ee6f16b0df0a7d1aa9debba55284651
 2021-11-03 16:34:10 +08:00
Sebastien Bourdeauducq e89bc93b5f ignore expressions in class definition body (#26) 2021-11-02 23:30:12 +08:00
Sebastien Bourdeauducq 47f563908a basic string support (#30) 2021-11-02 23:22:49 +08:00
Sebastien Bourdeauducq 0e914ab7e9 composer: add range keyword 2021-11-02 18:56:14 +08:00
Sebastien Bourdeauducq 613020a717 test: add missing id_to_name entry 2021-11-02 18:34:48 +08:00
Sebastien Bourdeauducq ee2c0d8bab flake: add cargo-insta to dev shell 2021-11-02 18:13:59 +08:00
Sebastien Bourdeauducq 0d1e9262af flake: update cargoSha256 2021-11-02 15:17:10 +08:00
Sebastien Bourdeauducq 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
Sebastien Bourdeauducq 624dfe8cd1 upgrade to LLVM 12 2021-11-02 14:00:20 +08:00
pca006132 e47597bb8a Merge branch 'context-manager' 2021-11-02 11:17:00 +08:00
pca006132 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
Sebastien Bourdeauducq da2886565b runkernel: sort out cargo rigmarole with rustc link arg 2021-11-01 00:28:27 +08:00
Sebastien Bourdeauducq b37cf6de08 nac3artiq: share isa->time_fns map 2021-11-01 00:03:15 +08:00
pca006132 083eacc268 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 23:54:37 +08:00
Sebastien Bourdeauducq 137efebb33 runkernel: add simple host kernel runner 2021-10-31 23:52:43 +08:00
Sebastien Bourdeauducq 443b95d909 nac3artiq: do not use custom linker script when targeting host 2021-10-31 23:51:50 +08:00
Sebastien Bourdeauducq 8b73a123cc nac3artiq: support compiling for the host 2021-10-31 23:02:21 +08:00
pca006132 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
pca006132 558c3f03ef nac3core/codegen: list comprehension support 2021-10-24 16:53:43 +08:00
pca006132 45673b0ecc nac3core/codegen: cleanup 2021-10-24 16:53:43 +08:00
pca006132 181607008d nac3core/codegen: supports list iter 2021-10-24 14:39:50 +08:00
pca006132 fb92b6d364 nac3core: supports range iterator 2021-10-23 23:53:36 +08:00
pca006132 2f6ba69770 nac3core/typecheck: check if value is none 2021-10-23 21:31:14 +08:00
pca006132 cc83bbc63a nac3core/codegen: fix broken test 2021-10-17 13:07:45 +08:00
pca006132 279f47f633 nac3core/codegen: avoid sending unifiers 
Previously, we have to copy types from one unification table to another,
and make the table sendable. This requires cloning (processing) the
whole table 3 times per function call which is not efficient and uses
more memory than required when the unification table is large.

We now use a concrete type table to only copy the type we need. This
reduces the overhead as we only need to process the unification table
for once (when we do the function codegen), and reduces memory usage by
a bit (but not noticeable when the unification table is small, i.e. the
types are simple).
 2021-10-17 13:02:18 +08:00
pca006132 9850cbe313 nac3core/codegen: optimize for every function 
This speeds up compilation and reduces memory usage.
 2021-10-17 12:56:11 +08:00
pca006132 1f5bea2448 nac3core/codegen: refactor according to #23 2021-10-16 22:17:36 +08:00
pca006132 c4259d14d1 fixed some clippy warnings 2021-10-16 18:08:13 +08:00
pca006132 26076c37ba nac3core/typecheck: supports recursive type inference 2021-10-16 15:56:49 +08:00
Sebastien Bourdeauducq fd0b11087e nac3core: use round instead of rint. Closes #61 2021-10-11 08:18:52 +08:00
Sebastien Bourdeauducq 3a1dd893a1 nac3artiq/demo: get closer to regular ARTIQ 2021-10-10 17:45:38 +08:00
pca006132 a4ccac2329 nac3artiq: implements #55, #56 2021-10-10 16:26:01 +08:00
pca006132 77542170fd nac3core: fixes #60 2021-10-10 15:01:06 +08:00
pca006132 a3ce5be10b nac3core: fixes #32 and #57 2021-10-09 16:20:49 +08:00
Sebastien Bourdeauducq a22552a012 nac3artiq: work around #56 2021-10-09 15:52:45 +08:00
Sebastien Bourdeauducq 6ba74ed9f6 nac3artiq: allow creating drivers on device 2021-10-09 15:51:47 +08:00
Sebastien Bourdeauducq 8b32c8270d nac3artiq: explain delayed registration 2021-10-09 15:21:41 +08:00