Bril to x86 Blog #546
Bril to x86 Blog #546
Conversation
|
|
||
|
|
||
| ## The Tricky Parts | ||
| Although at a high level, things were simple, the details were tricky to get right. The first big hurdle was actually getting a compiled program to run. This required support for several Bril instructions, you would need to support constants, and either printing or returning in order to observe that some changes had happened. But it also required support for some calling conventions to be supported, otherwise the program wouldn't terminate. What helped got me over this hurdle proved to be quite useful in general for developing this compiler. I spent a lot of time modeling Bril programs as C programs and comparing my Bril -> x86 results with Clang's C -> x86 results. This helped me find stuff like the following snippet of text, which I would include at the beginning of every file for macs: |
There was a problem hiding this comment.
What helped got me over this hurdle proved to be quite useful in general for developing this compiler.
I don't understand this sentence… what exactly was helpful, and with what?
|
|
||
|
|
||
| ## The Tricky Parts | ||
| Although at a high level, things were simple, the details were tricky to get right. The first big hurdle was actually getting a compiled program to run. This required support for several Bril instructions, you would need to support constants, and either printing or returning in order to observe that some changes had happened. But it also required support for some calling conventions to be supported, otherwise the program wouldn't terminate. What helped got me over this hurdle proved to be quite useful in general for developing this compiler. I spent a lot of time modeling Bril programs as C programs and comparing my Bril -> x86 results with Clang's C -> x86 results. This helped me find stuff like the following snippet of text, which I would include at the beginning of every file for macs: |
There was a problem hiding this comment.
for macs
To be more precise: "when generating code to target macOS"
|
|
||
| These directives seemed to vary quite a bit device-to-device; but I found comparing with a reference compiler was a reliable way of finding out what directives are necessary. Online sources often lack the specific things you need for your own device. | ||
|
|
||
| It was also quite tricky to get printing right. I implemented Prof. Sampson's suggestion of linking the printing with a helper [rt.c file](https://github.com/sampsyo/bril/blob/main/brilift/rt.c) to avoid printing Booleans by hand. To get linking right, again it helped a lot to model the behavior I would expect in an equivalent c program, and guide my implementation to match that output. |
| ret; | ||
| } | ||
| ``` | ||
| This program takes in a single int as a command line argument, and keeps printing its value and incrementing it until it hits 10. The tricky part comes from the fact that this function also calls itself. So this means the assembly code for this function must somehow handle both command line parsing and support proper calling conventions when it's called as a normal function. More concretely, in x86, it's expected that the main function's first and second parameters are `argc` and `argv` respectively. But we also want the main function's first function to be `x`. |
There was a problem hiding this comment.
You've stated the problem here, but what was the solution?
FWIW, the solution used in other native compilers is to add a "main wrapper" function that calls the true Bril @main function. The "main wrapper" parses the CLI arguments and then immediately calls @main.
There was a problem hiding this comment.
I ended up coming to the same solution, I could include that in the blog post
| This program takes in a single int as a command line argument, and keeps printing its value and incrementing it until it hits 10. The tricky part comes from the fact that this function also calls itself. So this means the assembly code for this function must somehow handle both command line parsing and support proper calling conventions when it's called as a normal function. More concretely, in x86, it's expected that the main function's first and second parameters are `argc` and `argv` respectively. But we also want the main function's first function to be `x`. | ||
|
|
||
| ## Correctness | ||
| I wanted to automate checking for correctness in comparison to the interpreter, but I didn't get to it in time. |
There was a problem hiding this comment.
It's too bad that you didn't get to test for correctness, but is there a way you could give a brief summary of how complete you think your implementation is? As in, how much of the Bril language do you think you covered, and what do you think is still not working? Just a couple of sentences of theorizing about this could help clarify to readers where you think things stand.
There was a problem hiding this comment.
Woah, I'm sorry, that section is completely wrong. I had rephrased it but I guess it didn't save. I didn't have time to compare to other AOT compilers like you suggested in the proposal PR, but I did test it for correctness and the output matches every core benchmark when compared to the interpreter.
|
I see you've marked this PR as a draft—let me know when it's ready for me to take another look and I'll publish it. |
|
Hi, I think this is ready for another look |
|
Looks good; I'll publish this now! |
2 participants
Resolves #506