Change godbolt to Compiler Explorer

content/blog/2023-12-11-lowering/index.md

@@ -152,7 +152,7 @@ We found it surprisingly easy to convert a Bril program to abstract assembly and
 with instructions very similar to RISC-V, these initial passes to create RISC-V instructions were fairly simple. Trivial register allocation was slightly more complicated, 
 but still was easily implemented with a mapper to assign and keep track of stack offsets. The hardest part to get right was definitely lowering function calls via RISC-V calling conventions. 
 
-A meta-problem we ran into was finding an environment that runs basic, 32-bit RISC-V assembly code. Due to a lack of foresight, we underestimated the amount of work required to get such an environment set up. In any case, we ended up settling on a few RISC-V interpreters that display the architectural state at the end of each program execution. Note that we did not add support for `print` instructions. Using an admittedly error-prone and somewhat monotonous procedure, we lowered Bril [programs](https://github.com/JohnDRubio/CS_6120_Advanced_Compilers/tree/main/rv32_backend/test) to RISC-V using our system. Next, we wrote C++ programs that were semantically equivalent to the same Bril programs and obtained the compiled RV32 code using [Compiler Explorer](https://godbolt.org/). Lastly, we ran both our RISC-V program and the godbolt RISC-V program on RISC-V interpreters and compared the end architectural state of each program. On the programs we tested, our RISC-V programs yielded identical architectural states to the Compiler Explorer programs, save quite a few more items on the stack in our case since we used trivial register allocation. Obviously, there are some issues with this approach - it does not provide a high degree of coverage and it does not provide any details on performance. We concede these two points. This approach does show that, at the very least, our lowering system can produce RISC-V programs that are semantically equivalent to non-trivial Bril programs. We would've liked to explore performance speedups in further detail but ultimately information on the performance of the JavaScript runtime and that of compiled RISC-V programs is not difficult to find.
+A meta-problem we ran into was finding an environment that runs basic, 32-bit RISC-V assembly code. Due to a lack of foresight, we underestimated the amount of work required to get such an environment set up. In any case, we ended up settling on a few RISC-V interpreters that display the architectural state at the end of each program execution. Note that we did not add support for `print` instructions. Using an admittedly error-prone and somewhat monotonous procedure, we lowered Bril [programs](https://github.com/JohnDRubio/CS_6120_Advanced_Compilers/tree/main/rv32_backend/test) to RISC-V using our system. Next, we wrote C++ programs that were semantically equivalent to the same Bril programs and obtained the compiled RV32 code using [Compiler Explorer](https://godbolt.org/). Lastly, we ran both our RISC-V program and the Compiler Explorer RISC-V program on RISC-V interpreters and compared the end architectural state of each program. On the programs we tested, our RISC-V programs yielded identical architectural states to the Compiler Explorer programs, save quite a few more items on the stack in our case since we used trivial register allocation. Obviously, there are some issues with this approach - it does not provide a high degree of coverage and it does not provide any details on performance. We concede these two points. This approach does show that, at the very least, our lowering system can produce RISC-V programs that are semantically equivalent to non-trivial Bril programs. We would've liked to explore performance speedups in further detail but ultimately information on the performance of the JavaScript runtime and that of compiled RISC-V programs is not difficult to find.
 
 # Were we successful?