[J-core] qemu support
chrisfriedt at gmail.com
Wed Apr 27 12:49:19 EDT 2016
Thanks for the docs, Rich.
Partially because I'm intrigued after checking out some of that
documentation, and partially because I'm bored as hell at work atm,
I'm going to create a few branches in my github fork of qemu (
These branches should vaguely describe all of the integration that
have been highlighted on the list, and are going to at least be
placeholders for now until I get to each one. I'm pruning a couple
(e.g. turtle-borad support) because I would prefer to just stick to
the most immediately gating. I'll try to list them in order of
dependencies (i.e. features lower down could depend on features higher
At first glance, this doesn't actually appear to be that much work..
but I may regret saying that; I've found that step-debugging through
Qemu code on Mac OS X can be painful if using gdb, so I'll likely be
using lldb this time.
On Tue, Apr 26, 2016 at 1:05 PM, Rich Felker <dalias at libc.org> wrote:
> Actually I think I said it backwards. On sh1/sh2/j2, interrupts/traps
> load an address from (VBR+trapno*4) and jump to it. On sh3/sh4, they
> branch to VBR+0x100 with trapno*4 in a special TRA register. The way
> registers are saved/restored also differ.
The behaviour of the sh2 is analogous to cortex-m w.r.t. interrupts.
I'm going to focus on the sh2 for now.
> (Note that it seems easy for software running on sh4 that wants the
> sh2 behavior to get it just by appending some code after the last VBR
> table entry that converts the saved register state then jumps to
> VBR+TRA. But of course qemu can't do it that way because it can't
> clobber the memory at VBR+0x100.)
> Here's the SH-FDPIC ABI doc (one mistake to be aware of: the meaning
> of the EF_SH_PIC flag is inverted vs what the document says):
> And some additional ABI documents:
> There may be some minor inconsistencies in some of them vs what's
> actually used in practice. If you run into anything that seems
> questionable, just ask and I'll check it against actual existing
>> > Aside from that, support for the j2 cas.l (compare and swap)
>> > instruction should be added, and instructions not available on j2
>> > (i.e. all insns new on sh3+ except the barrel shifter) should be made
>> > to trap so that code that can't actually run on the real hardware gets
>> > caught.
More information about the J-core