add codegen plugin support for special functions #24

New Issue

sb10q · 2021-09-24T13:31:26+08:00

sb10q commented

2021-09-24 13:31:26 +08:00

This is to enable the implementation of now_mu(), at_mu() and delay_mu() on RISC-V ARTIQ core devices, which use now-pinning.
Ideally nac3embedded would emit the LLVM IR for those functions.

This is low priority because we can use Zynq in the meantime, where those functions are regular syscalls.

This is to enable the implementation of ``now_mu()``, ``at_mu()`` and ``delay_mu()`` on RISC-V ARTIQ core devices, which use now-pinning. Ideally nac3embedded would emit the LLVM IR for those functions. This is low priority because we can use Zynq in the meantime, where those functions are regular syscalls.

sb10q added the

low-priority

label 2021-09-24 13:31:26 +08:00

sb10q referenced this issue

2021-09-24 14:05:24 +08:00

ARTIQ RPC support #25

sb10q referenced this issue from a commit

2021-09-24 14:45:47 +08:00

nac3embedded: switch to Zynq (#24)

pca006132 commented

2021-09-25 22:54:21 +08:00

Maybe we can mark certain definition IDs as special, and delegate the codegen of them to a special callback?

@ychenfo Is it possible to modify composer such that we can get the definition of class method definition IDs?

Maybe we can mark certain definition IDs as special, and delegate the codegen of them to a special callback? @ychenfo Is it possible to modify composer such that we can get the definition of class method definition IDs?

sb10q commented

2021-09-26 07:51:48 +08:00

Those are module functions and are not inside classes.

pca006132 commented

2021-09-26 15:04:54 +08:00

Those are module functions and are not inside classes.

I thought we may also use this for implementing RPCs, which can be methods inside classes.

> Those are module functions and are not inside classes. I thought we may also use this for implementing RPCs, which can be methods inside classes.

pca006132 referenced this issue from a commit

2021-09-26 22:17:42 +08:00

nac3core: implementing #24

pca006132 commented

2021-09-26 22:18:49 +08:00

A callback can now be defined by the application (nac3embedded/nac3standalone) to handle call codegen. A HashSet is used to decide what functions would be passed to the callback.

sb10q commented

2021-09-29 15:47:22 +08:00

Why should the user register the functions manually, and then match the obtained DefinitionIds in the callback?

Wouldn't it make more sense to have a HashMap of callbacks instead, with nac3core calling the matching callback directly?

Why should the user register the functions manually, and then match the obtained ``DefinitionId``s in the callback? Wouldn't it make more sense to have a ``HashMap`` of callbacks instead, with ``nac3core`` calling the matching callback directly?

pca006132 commented

2021-09-29 17:00:00 +08:00

Why should the user register the functions manually, and then match the obtained DefinitionIds in the callback?

Wouldn't it make more sense to have a HashMap of callbacks instead, with nac3core calling the matching callback directly?

Yes we can do that. Or we can just put the callback in the function definition so we do not need a hashmap. Which approach do you prefer?

> Why should the user register the functions manually, and then match the obtained ``DefinitionId``s in the callback? > > Wouldn't it make more sense to have a ``HashMap`` of callbacks instead, with ``nac3core`` calling the matching callback directly? Yes we can do that. Or we can just put the callback in the function definition so we do not need a hashmap. Which approach do you prefer?

sb10q commented

2021-09-29 17:01:07 +08:00

I just suggested HashMap as an internal implementation detail. Putting the callback in the function definition API call sounds good.

I just suggested ``HashMap`` as an internal implementation detail. Putting the callback in the function definition API call sounds good.

pca006132 commented

2021-09-29 17:05:04 +08:00

I just suggested HashMap as an internal implementation detail. Putting the callback in the function definition API call sounds good.

I mean we can store it as an optional field here: https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/toplevel/mod.rs#L59

and no HashMap would be needed. Maybe I would go for this approach and add an API for setting the callback.

> I just suggested ``HashMap`` as an internal implementation detail. Putting the callback in the function definition API call sounds good. I mean we can store it as an optional field here: https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3core/src/toplevel/mod.rs#L59 and no HashMap would be needed. Maybe I would go for this approach and add an API for setting the callback.

sb10q commented

2021-09-29 18:43:00 +08:00

Ok, fine by me.

pca006132 referenced this issue from a commit

2021-09-30 17:08:10 +08:00

nac3core: better impl of #24

sb10q closed this issue

2021-10-02 23:34:20 +08:00

Sign in to join this conversation.