[J-core] new here, project sounds interesting.

[BGB]

I recently encountered this project via hearing about it, and watching a 
YouTube video talking about it.

alas, I don't have an FPGA nor currently any money to buy one, so will 
not be able to test on real HW (my budget it pretty much dead right now).


however, I have briefly looked at the SH-2 ISA, and it seems reasonably 
nicely designed. kind of reminds me of MSP430 in some ways. general 
instruction coding seems a lot less hairy than Thumb.
granted, I haven't really fully looked into it, so there is always a 
potential for hidden "gotchas".

I am not sure off hand if I can do much useful for the project though.


general info (about self / projects):
I have some experience writing compilers and emulators.

most of my compilers have targeted custom bytecode VMs, generally with 
interpreter or JIT backends, and some have used C as an input language.

some of my other compilers have used variants of a custom "scripting 
language", where C isn't necessarily the best language design to use in 
a VM environment. my current script-language sort of resembles a 
C/Java/C# hybrid (will refrain from going too much into it here).

but, for anyone curious, here is a code example from a test where I 
ported a JPEG decoder over to it (reasonably direct port from C):
https://github.com/cr88192/bgbtech_bsvm2/blob/master/bstest/bs_decjpg.bs
for comparison (a C version):
https://github.com/cr88192/bgbtech_bsvm2/blob/master/bcn_decjpg.c

I have also done a C compiler, where previously I had attempted to 
address some of the technical issues which exist with C (in a variant I 
had called C-Aux), but found that they weren't so easily defeated (in a 
real-world implementation).

though, in a very simple summary: C is a reasonably expensive language 
to compile and tends to produce output that is difficult to make 
binary-portable across multiple platforms short of pretty much wrapping 
everything. I had developed theoretical mechanisms, but realized I would 
effectively still need to wrap everything to deploy them.

though, it was still modestly useful as a means to do green-threading 
(needed ~ 10us scheduler latency, wasn't going to get this with 
preemptive threading, and GCC lacks an option for running code via a 
customizable trampoline loop).


for emulators, I have written emulators for x86, x86-64, and MSP430.
have considered an ARM emulator, but haven't gotten to it (for code 
intended for ARM, had generally faked it on the PC using x86).

for x86 and x86-64, the emulators had primarily focused on userland 
code, which allowed some simplification and trickery (for example, its 
MMU was based on page-spans rather than page-tables). my initial tests 
focused on 32-bit, using MinGW and custom libraries for compiling 
programs, and basically worked.

later, there was a short-lived project to re-implement the Win32 API and 
DLLs (for a small subset), but I lost motivation and went onto other 
stuff before really getting any Win32 software working. figured 
officially I would only support 32-bit x86 with a 486-like ISA.


the MSP430 emulator was fairly straightforward, given how simple it was.

I had noted that some existing emulators existed, but were horribly slow 
(vs the real HW) and didn't seem to allow for customizable peripherals 
(say, what if one wants to simulate some external electronics the MCU is 
hooked up to?...).

I did the emulator more like my other interpreters (via dynamic 
translation to call-threaded-code), which ended up considerably faster 
than real-time (~ 150 MIPS, or an MSP at ~ 500 MHz or so).

later added logic to slow it down to real-time speeds (as controlled by 
CPU registers), as well as to account for the number of clock-cycles 
required by various instruction forms (needed to try to match the 
behavior of the emulated MSP with the real hardware, and to get more 
sensible results with the virtual IO pins).


I did also try to make an electronic simulator to go along with it (in a 
vaguely similar sense to something like LTspice mixed with a 
board-layout tool), but failed at making the simulator part not suck.

imagination was something like one could drop an MCU onto a board (keyed 
to appropriate ROM image), hook components up to it (by routing traces), 
and see in real-time how everything would behave. UI basically worked, 
but the simulation part was basically unusable (would likely need to be 
dropped and tried again, analog signaling was extremely slow).


however, the MCU simulation part did work, and it was still possible to 
use it with peripherals implemented using code.

I suspect I could probably do similar for the SuperH ISA if I had a 
reason to do so.
if done, can probably get similar speeds to the MSP, or a little faster 
if a JIT is used.


any thoughts?...