<jevinskie[m]>
I highly doubt it, they probably just took the lm32 verilog from lattice and connected the data wishbone bus to an arbiter that lets it access the other buses on the AMD SoC
<jevinskie[m]>
* I highly doubt it, they probably just took the lm32 verilog from lattice and connected the data wishbone bus to a decoder/arbiter that lets it access the other buses via MMIO on the AMD SoC
<cr1901>
I still like lm32... it's decent Verilog code and doesn't have a proliferation of extensions lol
<jevinskie[m]>
they extended lm32 further to am32 for their SAMU (Secure Asset Management Unit) thats half used for DRM and half used for Secure Boot (but not any standard secure boot, ps4 specific). Xbox One has a SMU too but I don't own an Xbox One since their security is harder to break and thus not as much fun. I believe the Xbox One has a SAMU too but it goes unused since at least later models of the APUs they use have a PSP like you'd find in
<jevinskie[m]>
Zen-class CPUs
<jevinskie[m]>
cr1901: i saw some benchmarks showing lm32's simple design keeping up with some much more complicated cores. maybe this was it? https://antmicro.github.io/embench-tester/
<cr1901>
Main issue is that no LLVM port so no Rust (for now, until the gcc backend takes hold)
<jevinskie[m]>
yeah its proprietary extensions added by AMD (including crypto accelerator w/ key slots concept). some poor souls weren't so clean with their OPSEC so we found the gcc/binutils toolchain in an obscure place online. Someone else managed to extract the cgen data from the binaries and make an IDA processor module for it :) https://sourceware.org/cgen/
<tpb>
Title: CGEN (at sourceware.org)
<cr1901>
The thing about LM32 is that it has only a single opcode out of 64 for a custom insn. So they must've done some more major modifications if they added the extensions you mentioned
<cr1901>
(My preferred use for a custom insn would've been to add a CAS, but you technically don't need atomics to run Linux if it's single core only w/ kernel helpers)
<jevinskie[m]>
There was this stab at lm32 backend for LLVM but it stalled out 8 years ago =\ I'd love a LLVM with a lm32 backend and it is simple enough an architecture it can't be any more difficult than the other intro/tutorials for making a new LLVM backend. Hmm, only one I really know of was cpu0 and that was still quite a bit of work
<cr1901>
I started an LM32 backend using cpu0 as a basis. Yes, it's too much work to write an LLVM backend :'D.
<cr1901>
Maybe I should try again
<cr1901>
Look, if someone can write a 6502 backend for LLVM that doesn't entirely suck, it's probably a "skill issue" on my end
<jevinskie[m]>
I consider myself to be pretty well versed in LLVM (at least up until 2018 era, don't ask me about MLIR!) and I've always wanted to make my own backend for Forth. Then you could obfuscate C/C++/ObjC(++) with different metainterpreter (themselves obfuscated and layered on each other). :P
<cr1901>
Main issue I ran into is that the lm32 calling convention doc is a bit underspecified, so I need to figure out where in the gcc source calling convention is defined
<cr1901>
metainterpreter?
<jevinskie[m]>
But the conversion of SSA register for to stack form still has me at a roadblock.
<jevinskie[m]>
forth metacompiler* basically a forth interpreter/compiler written in forth but not via typical emulation means but by building a new version of itself https://github.com/howerj/embed
<jevinskie[m]>
that + a forth frontend for LLVM (there are a couple) + the LLVM obfuscation passes) might blow away a reverse engineer's mind, or not, I never had the time to do the work :(
<jevinskie[m]>
<cr1901> "Look, if someone can write a 650..." <- Exactly. The guy who started or is one of the major devs of that project is married to an ex-girlfriend of mine. Maybe LLVM emits some pheromones? :P
<cr1901>
I hope you and ex-gf and him are on good terms :P
<cr1901>
I'll have to check your link when I'm in more of a mode to do so (stuck in FPGA land rn)
<jevinskie[m]>
For am32 I think they added a bunch of CSRs to interface with the crypto engine as a coprocessor, not unlike ARM's MRC/MCR instructions to do terrible FPU in the early versions
<tpb>
Title: compiler construction - Converting SSA to stack machine - Stack Overflow (at stackoverflow.com)
<cr1901>
(I assume they mean "do register coloring on SSA to figure out what temporaries you need before converting it into something suitable for a stack machine")