User-facing compiler about scoria

[Rewbert]

Not tying ourselves to the directory structure sounds reasonable. I'm not sure how you usually organize these things so you two probably know this better than I do. I don't know how Linux organizes its Kernel modules, maybe you and @sedwards-lab can explain it on Tuesday? :)

Hacking on a compiler interface sounds fun!

[j-hui]

With the latest commits on #21, I should be able to remotely include the Build.mk at the project root directory, meaning we can compile C programs out of tree, and link against our runtime system.

The question that remains is what the interface for the compiler frontend should like. My original thought was that each SSM program could be its own "main" file, with each declared as an executable in ssm-edsl's configuration. The Haskell file defining the SSM program would include some boilerplate that would dump the compiled C code when executed. But doing this essentially requires the user to modify the compiler's project configuration to work, which is not how one should expect to use a compiler.

However, we can achieve a similar effect using stack runhaskell. For instance, say we have a program Fib.hs:

import SSM

-- other defs...

myfib :: Exp int32 -> Ref Int32 -> SSM ()
myfib = ...

main :: IO ()
main = compileCLI $ myfib 10 inputref

Then we could "invoke" the compiler using stack runhaskell Fib.hs. Under the hood, compileCLI would invoke transpile . compile_ under the hood to produce a String containing compiled C program.

I considered having compileCLI to simply emit the C progarm to stdout, so that the calling script can redirect it (e.g., stack runhaskell Fib.hs > path/to/Fib.c). Unfortunately, BinderAnn's output is also written to stdout. So instead, I'm thinking about having compileCLI also do some basic argument parsing, extract a filename (e.g., from -o pathname/Fib.c), and write the C file there.

Does this approach make sense/are there alternatives I should consider? Are there other CLI flags I should consider?

[Rewbert]

Now that I am hacking on LED support I have been planing on having it dump more than 1 file (peng-led.h, peng-led.c etc), since I figured it would make inspecting the generated code easier of we ever need to really dive into it. This is how I designed my additions so far. I suppose the files can be concatenated in some way to produce a single file though, but just thought I'd mention that.

If binderann is too messy to use we can always walk away from that for now and modify the plugin to better suit our needs at a later stage, when we can spare the time for it. It is only a cosmetic thing that captures names in the EDSL source, which is great for code generation, but it is not a requirement that we rely on in any way. If no name is captured, a fresh one is generated.

[j-hui]

Ah interesting, what's in peng-led.h that is needed elsewhere?

[Rewbert]

I figured it'd be a good spot for the sv_led_t struct and the prototypes for the assignment, update etc. It is imported by peng-led.c & whichever file we eventually end up dumping the generated SSM program in

[j-hui]

ah, so this would be for typegen? I've punted that for now, but my thinking on that was that we should just generate a single ssm-types.c with all the implementations, and a single ssm-types.h file that declares everything for other compilation units to use (i.e., the generated SSM code). That saves us from having to figure out which #includes we have to put at the top of the generated C SSM code.

[Rewbert]

Hm I don't think figuring that out will be too tricky - the compiler will have all the static information that it needs at hand.

It doesn't really matter what we do though, as whatever we choose to do, making the switch to the other variant shouldn't be too difficult.

[j-hui]

Having all the different type implementations in different .c files also makes the job of the build system harder, because it needs to figure which additional files it needs to link into the executable. Though it's still doable, it would be great to avoid having a variable number of objects it needs to link together.

[Rewbert]

I am not that experienced with make but isn't it possible to specify a directory and having it include/compile everything in there? E.g one include/ and one src/

[j-hui]

It is certainly possible, but it would require additional coordination between the Haskell compiler and the Makefiles that handle the C compilation. Right now, all the intermediate build artifacts etc. are just dumped flatly into the build/ directory, and Build.mk expects is that for the final target there exists a target.c in that build directory.

[Rewbert]

I guess in my head I am thinking that real example programs that doesn't to very much will still very quickly produce several thousand generated LOC, and if we need to dig into them for debugging purposes or something, it might be overwhelming if it was all gathered in a single file. There's a cost/gain balance here, and I am not sure how to specify the details of it 😅

[j-hui]

The compiler interface situation has been improved somewhat by #21 and #28 . We still need to flesh out and implement a scheme for per-platform main functions, but aside from that I think most of the compiler interface is now encapsulated underneath the build system. Since that's already being tracked in #33 , and this issue is rather open-ended, I'll close this for now; we can open up more specific issues when they crop up.