chore: implement Display for brillig

[asterite]

Description

Problem

No issue, I just found Brillig output hard to understand, and Brillig is the only language we have that doesn't have a "proper" language.

Summary

I'm mainly opening this PR for feedback as it's unfinished (blackbox ops are not implemented yet) and I'm unsure about how I'm currently displaying some things.

For the empty Noir program

unconstrained fn main() {}

we now get this when using --print-acir:

Compiled ACIR for main (non-transformed):
func 0
current witness: w0
private parameters: []
public parameters: []
return values: []
BRILLIG CALL func 0: inputs: [], outputs: []

unconstrained func 0
 0: @2 = const u32 1
 1: @1 = const u32 32836
 2: @0 = const u32 3
 3: sp[1] = const u32 0
 4: sp[2] = const u32 0
 5: @32836 = calldata copy [sp[2]; sp[1]]
 6: call 11
 7: call 12
 8: sp[1] = const u32 32836
 9: sp[2] = const u32 0
10: stop &[sp[1]; sp[2]]
11: return
12: call 14
13: return
14: @32772 = const u32 30720
15: @32771 = u32 lt @0, @32772
16: jump if @32771 to 19
17: @1 = indirect const u64 15764276373176857197
18: trap &[@1; @2]
19: return

Some notes and questions:

1. I chose to add line numbers because, if I'm understanding things correctly, "call 11" would jump to line 11? Not sure.
2. Direct memory addresses are displayed like @1, while relative are displayed like sp[1], "sp" being "stack pointer".
3. HeapArray is shown as [pointer; size] and HeapVector as &[pointer; size]
4. I wonder if assigning to @0 should be shown as assining to sp as that's where the stack pointer is stored (for clarity)
5. Why does an empty program produce all of that brillig? Maybe it's boilerplate for all programs? (Ah, I think those are the three stdlib functions?)

Also, let me know if this is totally not needed and I'll close this PR 😅

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 6349c2a	Previous: 5524470	Ratio
test_report_zkpassport_noir_rsa_	2 s	1 s	2

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[jfecher]

Also, let me know if this is totally not needed and I'll close this PR 😅

I think this is helpful

[vezenovm]

Also, let me know if this is totally not needed and I'll close this PR 😅

I think this is helpful

Yes agreed, we need a clear human-readable Brillig format in general but also to implement a more concrete Brillig parser as well.

[asterite]

Thanks!

I'll continue working on the blackbox calls then. The actual name of instructions and how they are printed is all up for debate, I chose the ones that looked easier to understand and eventually parse.

[vezenovm]

1. I chose to add line numbers because, if I'm understanding things correctly, "call 11" would jump to line 11? Not sure.

Yes, call is going to set the program counter to the label you see there. Call differs from jump in that it also pushes the current program counter to a call stack, so when we hit a return opcode we will go back to that location previous location.

• Direct memory addresses are displayed like @1, while relative are displayed like sp[1], "sp" being "stack pointer".
• HeapArray is shown as [pointer; size] and HeapVector as &[pointer; size]

This is good with me. Makes it clear to what the address is relative.

• I wonder if assigning to @0 should be shown as assining to sp as that's where the stack pointer is stored (for clarity)

Might be good to display assigned registers. We can consider that separately.

5. Why does an empty program produce all of that brillig? Maybe it's boilerplate for all programs? (Ah, I think those are the three stdlib functions?)

No it is not the stdlib. It is the generated entry point logic. You see the "calldata copy" instruction? It looks like we still generate all the surrounding entry point logic even if the arguments and return values are empty. I would need to look into where this chunk of code comes from:

11: return
12: call 14
13: return
14: @32772 = const u32 30720
15: @32771 = u32 lt @0, @32772
16: jump if @32771 to 19
17: @1 = indirect const u64 15764276373176857197
18: trap &[@1; @2]

However, up to opcode 10 is all entry point logic.

[asterite]

I moved it out of the queue just a bit because I just implemented the remaining blackbox bits. For blackbox I chose a call with all "named arguments", even the output(s), so it looks like this:

aes_128_encrypt(inputs: &[sp[5]; sp[6]], iv: [sp[7]; 16], key: [sp[8]; 16], outputs: &[sp[9]; sp[10]])

I initially thought about doing something like:

&[sp[9]; sp[10]] = aes_128_encrypt(inputs: &[sp[5]; sp[6]], iv: [sp[7]; 16], key: [sp[8]; 16])

but I went with the first form because blackboxes seem to be special, and it might also be easier to parse, and even clearer.