Project Proposal: Bril-related extensions (e.g. variable number of arguments to main)

[AliceSzzze]

What will you do? I would like to modify the typescript interpreter (and maybe the other interpreters too) so that main could take any number of arguments, much like how main in C/C++ has the signature int main (int argc, char *argv[]). This would purely be an extension and current Bril programs would not have to be changed. At the moment, we can only pass a fixed number of arguments to main, and we have to manually add a function to pack the arguments into an array, which is not only extra implementation but also limits our ability to test the programs and see the effect of our optimizations for larger inputs.

If time permits (which it should), I would like to also add support for arrays to the TypeScript compiler, make a debugger, or extend Bril in other ways, but the one above is the minimum viable project goal.

How will you do it? Most of the changes for the main change will happen in brili.ts in the Bril repository. We will check if main in a Bril program has the particular signature and feed in the input accordingly. We should also be able to parse large arrays from files.

How will you empirically measure success? I plan to create variable argument versions of existing Bril benchmarks and check that they work for argument arrays of any sizes. I would also want to see if I could speed up argument parsing for larger inputs. For the TypeScript compiler, I would test the correctness of the extension with TypeScript programs that use arrays.

[sampsyo]

This sounds good, @AliceSzzze! Can I ask you to please do the following early-stage check-in, hopefully within ~1 week?

It would be really helpful to have a list of benchmarks that could plausibly benefit from this. I am thinking that the various matrix multiplications, sorting algorithms, etc. could also benefit from taking in an entire array (i.e., a pointer to an allocated region using the memory extension) all at once. These benchmarks all use different workarounds for the lack of array inputs, so they will need to take different tactics to modify them.

Could you please make a list of the benchmarks you hope to target, maybe grouped into "definitely will do these ones" and "maybe will do these ones if I have time"? Having these listed up front, I hope, will really help clarify exactly what modifications you need to make to the interpreter to make them all work.

[AliceSzzze]

Of course! Most if not all of the benchmarks I will rewrite will use the memory extension since the other programs require a fixed number of operands. I plan to definitely do all the benchmarks in the mem folder, except for the following, which already allocate variable-length arrays / it might not make sense for them to take an input array, but I plan to revisit them after implementing the changes and rewriting the other mem benchmarks:

• mem/adj2csr.bril
• mem/csrmv.bril
• mem/eight-queens
• mem/fib.bril
• mem/primitive-root.bril
• mem/quicksort-hoare.bril
• mem/sieve.bril

I have a question: should I push my rewritten benchmarks to the Bril repo? If so, should I overwrite the original versions or should I create new ones? Thanks!

[sampsyo]

Sounds great!!

Good question about what to do when changing the benchmarks. I think, for now, it makes the most sense to add copies with your new variable-sized-input feature (in its own special directory), leaving the old ones around. The reason is that there are multiple implementations of Bril with the memory extension, and it would be great to be able to benchmark the ones that don't support this feature yet. Eventually, when support is more widespread, we can replace the old ones.