search

sampsyo / cs6120

advanced compilers
https://www.cs.cornell.edu/courses/cs6120/2023fa/
MIT License
739 stars 157 forks source link

Project Report: Bril Bytecode Interpreter #337

Closed charles-rs closed 2 years ago

charles-rs commented 2 years ago

here we go!

closes #304

charles-rs commented 2 years ago

Does the compiler work? - yes, it passes all of our tests compiling to armv8-a with no register allocation.

Well, then why aren't we seeing performance numbers?? - Ran the benchmarks on my (much faster) x86 chip, so adding the compiled code performance would be apples to oranges, so i would have to rerun everything. I didn't do this since the arm chip is slow.... I'll do it now though

The bytecode format: this is documented separately here, so I didn't duplicate the info. I'll make the link more clear.

The bar chart: yes. good idea.

charles-rs commented 2 years ago

ran the benchmarks on my arm laptop. 10 seconds of timeout wasn't enough....

sampsyo commented 2 years ago

Woohoo! Nice bar chart!

While linking to the reference for the bytecode format is nice for the complete details, the thing I think would be useful to have here (to make the post self-contained) is just an overview of the strategy. There are lots of degrees of freedom in how the bytecode might be designed, and some "big questions" about how to even think about an appropriate bytecode (should the types be kept? how do you preserve string names of things, if at all? how do you index functions and labels—the same way as variables?). Instead of giving an exhaustive description of the bytecode here, just giving us enough information to understand the overall design would help a lot. (That's why I mentioned the idea of showing off a single instruction… like, you could demonstrate what a simple x: int = add x y looks like once encoded, and that would answer a lot of these questions.)

charles-rs commented 2 years ago

ohhhh ok i understand now sorry for the confusion. This makes sense.