[J-core] Debug jump log?

[BGB]

On 2/23/2017 6:18 PM, Rich Felker wrote:
> On Thu, Feb 23, 2017 at 01:35:53PM -0600, Rob Landley wrote:
>> What would it take to add a debug feature to j-core which recorded the
>> address each jump came from into a ring buffer when we set a status
>> flag? I.E "start debugging mode", then run until breakpoint, then dump
>> the buffer to have all the "come from" addresses so we can reconstruct
>> the path that got us here back into the runtime history?
>>
>> Even if it was writing the data straight into DRAM (thus slowing
>> execution down a lot) it would be a really useful feature for things
>> like profiling the interrupt path. (Doing that would need a register to
>> set the size/location of the buffer...)
> Is there a reason you'd want this in the hardware rather than an
> emulator?

yeah. my emulator more-or-less has this already, but ATM it is sort of 
broke as it doesn't mix well with how part of the new JIT works. I will 
probably fix it, but the ability to dump execution traces will likely be 
an optional feature (likely controlled with a command-line option or 
similar), and come at a cost to execution speed.

though, ATM, the same optimization also currently poses issues for the 
ability of Linux to run reliably, so for now I have it disabled in SH2 mode.

basically, it is a cache allowing traces to jump between each other more 
directly without having to go through the main hash-table used for PC 
lookups each time. apparently in some cases, control-flow still manages 
to get into places it shouldn't (namely instruction traces which have 
since been destroyed, ...).

so, probably more debugging work needed, and trying to verify that 
everything works as intended (sadly, a JIT adds a lot more potential 
area for things to go wrong in subtle or intermittent ways).


I decided to split most of my extension ideas off into its own SH-based 
ISA, and re-added some of my previous ideas for a 64-bit ISA onto that 
(so, it would be a design for a core with 32 and 64 bit operating modes, 
backwards compatible with the existing ISA).

I may at some point do a C compiler and emulator for it as a "proof of 
concept" (I personally lack the ability to do a VHDL or ASIC version 
though, so this is rather unlikely, I can just "hope" that the design 
choices wouldn't be too overly painful for real HW).

unlike the normal SH-ISA, it would have the existing 16-bit 
instructions, as well as a number of 32 and 64-bit instruction forms. 
both 32 and 64 bit I-forms are effectively are a partial repeat of the 
16-bit ISA (reusing the same basic bit-patterns), mostly differing in 
the addition of significantly larger immediate values and displacements 
(ex: 48-bit immediate values in some cases).

for now, I am calling this new ISA "BJX1", decided to leave out a more 
detailed description, as I am not certain anyone here really cares (and 
probably not directly relevant).


or such...