[J-core] Sorry for the radio silence.
cr88192 at gmail.com
Wed May 17 21:56:52 EDT 2017
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:
>>> 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.
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
the thinking is these could potentially improve both code
density and performance.
these would likely be optional features intended for more
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):
a similar idea spec for the BJX1 ISA extensions:
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.
More information about the J-core