On Mon, Mar 19, 2018 at 9:43 PM, Richard Henderson < richard.hender...@linaro.org> wrote:
> On 03/20/2018 02:35 AM, Michael Clark wrote: > > FYI - I also have an experimental branch containing a RISC-V TCG back-end > > that I started on during the RISC-V Hackathon in Portland last week: > > > > - https://github.com/michaeljclark/riscv-qemu/tree/wip-riscv-tcg-backend > > Cool. > > > I'm able to run a very simple x86_64 hello world program on RISC-V, > > avoiding all of the usual libc startup. However, it may be some time > before > > I submit a patch series for this branch. So far the RISC-V TCG backend > > doesn't implement softmmu, have bigendian byteswapping in its load/store > > implementation ... > > Before you work too hard on this last, ping me. I've been intending to > change > TCG such that hosts that do not support byte-swapping memory operations do > not > need to handle them specially. Instead, we'd expand a "normal" byte swap > from > a temporary after a load (and similarly before a store). > Okay. I'll leave the byte swapping out for now. The first priority is to test the basic codegen with little endian front-ends e.g. riscv -> riscv and x86 -> riscv, and the second priority is to implement softmmu. I still have some bugs as its pretty new code, but as I mentioned, the bones are there. i.e. we have relocs and instruction encoders for riscv. > I expect this to improve the state of affairs for i386 (without movbe), > where > we are currently extremely limited in the available registers. > Okay, so this would move byte swapping into TCG generic code instead of the TCG backend, unless the backend explicitly supports load/store with byte swap?
