[J-core] Sorry for the radio silence.

[BGB]

On 5/17/2017 4:25 PM, Rob Landley wrote:
> On 05/15/2017 12:17 AM, BGB wrote:
>>> There's a fun talk an AMD guy gave a while back about how they can't
>>> simulate their chip design in even the highest-end FPGAs because it's
>>> just way too big:
>>>
>>>     https://www.youtube.com/watch?v=eDmv0sDB1Ak&t=52m0s
>>>
>>> Meanwhile, our stuff fits in the cheap low-end FPGAs. :)
>> yeah; granted, a modern x86 chip is a pretty big complicated thing.
> That's an understatement.
>
> https://twitter.com/0xabU/status/862345132363755520

yeah, FWIW, there are also several thousand I-forms IIRC (and a fair bit 
more of one counts the various ModR/M forms separately).

it isn't quite as bad if one sticks to a 486-like subset (sufficient for 
a majority of 32-bit code).


but, my own thinking has been more like:
     the existing SH ISA would remain as the primary ISA
         probably also what compilers would target by default.
     a 64-bit mode could exist as an extension
     some extensions would exist mostly to pave over some "rough areas"
         as a result, the vast majority to the extensions in this case 
ended up being MOV forms.
         ex: larger displacements, and an analog of x86's 
[base+index*scale+disp] addressing.
             the thinking is these could potentially improve both code 
density and performance.
         these would likely be optional features intended for more 
performance-oriented cores.
     optional extensions to the FPU (ex: to add SIMD, ...)
         these are intended more as a special purpose feature (1).
         probably most cores would skip this in favor of a more basic FPU.
         unlike the memory ops, SIMD is less directly relevant for 
normal C code.
             it is admittedly intended more for running something more 
like GLSL or similar.

as for the random idea of reorganizing the FPU registers in 64-bit mode; 
I dropped it as I realized soon afterwards than this would have an 
adverse effect on the C ABI.


sort of a running "idea spec" for the SIMD design (as-is):
     https://github.com/cr88192/bgbtech_shxemu/wiki/BJX1-NV_SIMD1

a similar idea spec for the BJX1 ISA extensions:
     https://github.com/cr88192/bgbtech_shxemu/wiki/SH-BJX1-ISA

though, it is likely that only parts of BJX1 would be implemented, a 
partial goal of the compiler effort is to identify what can potentially 
offer the most "bang for the buck" here.


a grey area though is what all parts of the opcode space may be reserved 
for larger escape-coded I-Forms.

as-is, the space for escape-coded forms looks like:
     0xx0 (SH 2A), MOVI20
     0xx1 (SH 2A), MOVI20S
     3xx1 (SH 2A), various
     3xx9 (SH 2A), various
     4nF8 (BJX1), LDSH16 #imm16, Rn (Rn=(Rn<<16)|Imm)
     82xx (BJX1), reserved (probably various)
     8Axx (BJX1), MOV #imm24, R0
     8Exx (BJX1), various
     FxxF (BJX1), reserved (probably mostly for FPU/SIMD ops)

use of anything from 2A is debatable, and would probably be limited 
mostly to its MOV I-forms.


or such...