4 ms·

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_simple.x https://github.com/google/xls/blo

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_simple.x https://github.com/google/xls/blob/main/xls/examples/riscv_s...

fmakunbound 6y ago
Comments indicate it implements a subset of various things.
Traster 6y ago
It's kind of a good demonstration of the problem with software versus hardware, here's xls solution (just for one function): fn decode_i_instruction(ins: u32) -> (u12, u5, u3, u5, u7) { let imm_11_0 = (ins >> u32:20); let rs1 = (ins >> u32:15) & u32:0x1F; let funct3 = (ins >> u32:12) & u32:0x07; let rd = (ins >> u32:7) & u32:0x1F; let opcode = ins & u32:0x7F; (imm_11_0 as u12, rs1 as u5, funct3 as u3, rd as u5, opcode as u7) } here's the systemverilog solution {im_11_0,rs1,funct3,rd,opcode} <= ins; Obviously, in software, you can't slice data in the same way since as far as I can tell, it's assuming all variables are a certain size and so there's no naturally way of bit slicing.
- learyg 6y ago
  Thanks again for the detailed thought! We actually [developed more advanced bit slicing syntax]( https://github.com/google/xls/blob/1b6859dc384fe8fa39fb901af3de8453661ff345/xls/dslx/interpreter/tests/bit_slice_syntax.x#L32 https://github.com/google/xls/blob/1b6859dc384fe8fa39fb901af... ) since that example was written, you can do things like a standard slice `x[5:8]` or a Verilog-style "width slice" that has explicit signedness `x[i +: u8]`. There's currently no facility for "destructuring" structs as bitfields like pattern matches, but there's no conceptual reason it can't be done, I think that'd be an interesting thing to prioritize if there's good bang for the buck. [Github issue to track!](https://github.com/google/xls/issues/131 https://github.com/google/xls/issues/131) Let me know if I missed out on details or rationale, thanks!
  - Traster 6y ago
    Hey, thanks for replying, the project looks like it has a lot of potential. You're right, bit slicing gets you like 99% of the way there (the rest is just syntax sugar). It's interesting because from what I remember there were some non-trivial issues for the people using LLVM for their IR because of fundamental assumptions in the representation, but bit-slicing is the core functionality. Is there a reason you guys decided on your own IR?
- FullyFunctional 6y ago
  That's untrue. You need to include the declarations of im_11_0, etc. for the above to work and then you end up with just as much code. There's no reason they couldn't extend match to operate on bit slices also which would make this identical. Frankly, combinatorics is not where I expect the most interesting differences. Sequential logic is surely more interesting.

I love their RISC-V implementation in 500 lines of code: https://github.com/google/xls/blob/main/xls/examples/riscv_simple.x https://github.com/google/xls/blob/main/xls/examples/riscv_s...

fmakunbound 6y ago

Comments indicate it implements a subset of various things.

Traster 6y ago

It's kind of a good demonstration of the problem with software versus hardware, here's xls solution (just for one function): fn decode_i_instruction(ins: u32) -> (u12, u5, u3, u5, u7) { let imm_11_0 = (ins >> u32:20); let rs1 = (ins >> u32:15) & u32:0x1F; let funct3 = (ins >> u32:12) & u32:0x07; let rd = (ins >> u32:7) & u32:0x1F; let opcode = ins & u32:0x7F; (imm_11_0 as u12, rs1 as u5, funct3 as u3, rd as u5, opcode as u7) } here's the systemverilog solution {im_11_0,rs1,funct3,rd,opcode} <= ins; Obviously, in software, you can't slice data in the same way since as far as I can tell, it's assuming all variables are a certain size and so there's no naturally way of bit slicing.

learyg 6y ago
Thanks again for the detailed thought! We actually [developed more advanced bit slicing syntax]( https://github.com/google/xls/blob/1b6859dc384fe8fa39fb901af3de8453661ff345/xls/dslx/interpreter/tests/bit_slice_syntax.x#L32 https://github.com/google/xls/blob/1b6859dc384fe8fa39fb901af... ) since that example was written, you can do things like a standard slice `x[5:8]` or a Verilog-style "width slice" that has explicit signedness `x[i +: u8]`. There's currently no facility for "destructuring" structs as bitfields like pattern matches, but there's no conceptual reason it can't be done, I think that'd be an interesting thing to prioritize if there's good bang for the buck. [Github issue to track!](https://github.com/google/xls/issues/131 https://github.com/google/xls/issues/131) Let me know if I missed out on details or rationale, thanks!
- Traster 6y ago
  Hey, thanks for replying, the project looks like it has a lot of potential. You're right, bit slicing gets you like 99% of the way there (the rest is just syntax sugar). It's interesting because from what I remember there were some non-trivial issues for the people using LLVM for their IR because of fundamental assumptions in the representation, but bit-slicing is the core functionality. Is there a reason you guys decided on your own IR?
FullyFunctional 6y ago
That's untrue. You need to include the declarations of im_11_0, etc. for the above to work and then you end up with just as much code. There's no reason they couldn't extend match to operate on bit slices also which would make this identical. Frankly, combinatorics is not where I expect the most interesting differences. Sequential logic is surely more interesting.