On 5/14/2017 4:43 PM, Rob Landley wrote:
> On 05/14/2017 03:06 PM, Fabjan Sukalia wrote:
>> Hi!
>>
>> Am 14.05.2017 21:36 schrieb "Rob Landley" <rob at landley.net
>> <mailto:rob at landley.net>>:
>>
>> Doing a good hardware instruction set is a significantly harder problem.
>> The main reason we haven't finalized and published our proposed 64-bit
>> instruction set for j-core is until we implement it in hardware (a ways
>> down the todo list) it's subject to change. (Last year Jeff and I
>> printed out the instruction set list and worked out that there _is_
>> enough space to do a 64-bit implementation. I believe Jeff has those
>> pages, but we could do it again if we need to.)
>>
>>
>> Is the draft open and maybe also in a Git repository? It would be fine
>> if we can review and comment it before the specification is finalised.
>> The folks at RISC-V have this open design process and it works good.
> Ours is simple enough we haven't really seen the need for bikeshedding,
> but I can ask Jeff.
FWIW (unrelated, I have no idea what you and Jeff designed):
my earlier design for a 64-bit SH was setting a control bit and having
some of the MOV.W ops change into being MOV.Q ops (with the GPRs
expanding to 64-bits), and relatively few other changes.
my current design expanded some, and changed/dropped some things, though
at its core is basically similar (it mostly just adding some extended
32-bit I-forms, which are a mostly orthogonal feature);
the space for 16-bit I-forms is, as can be noted, pretty much full.
some of the encodings I used would conflict with SH-DSP, but as I
understand it, SH-DSP was pretty much incompatible with SH4 already.
in 64-bit mode, the use of 32-bit I-Forms would allow both MOV.W and
MOV.Q to coexist, as they are both assigned opcode numbers in this space
(taking over the space from some other operations where it "didn't make
sense" to add an immediate field or otherwise expand them).
it should be possible to get along ok in 64-bit mode purely using 16-bit
instructions, though at the cost of reduced efficiency (MOV.W takes a
penalty in that effectively its only remaining I-Forms are "MOV.W @Rm,
R0" and "MOV.W R0, @Rn" and similar).
this seemed like a reasonable tradeoff as, typically, 16-bit types are
much less common in 64-bit code. there is a cost in that "MOV.W
@(PC,disp), Rn" no longer exists (became a MOV.Q form); this is partly
offset by the existence of a 32-bit "MOV #imm16, Rn" I-Form
("8Eii-Enii"; maybe also technically 2A's "0ni0-iiii"/MOVI20 form).
I have since assumed that the 32-bit I-Forms would be assumed to exist
in 64-bit mode (in the ISA).
FWIW, I have generally also been assuming a few things about their behavior:
32-bit I-forms will generally take 2+ cycles, vs 1+ cycles for
16-bit ops;
because the prefix word would take up a spot in the pipeline.
they will generally calculate PC relative to the final word.
handled as if the prefix were another instruction.
32-bit I-forms would be illegal in the delay slot.
...
some unclear issues relate to the behavior of the FPU in 64-bit mode.
some recent thinking is that effectively the FPU register space remains
the same overall size, however, the pairing for doubles changes from
(FR0,FR1) to (FR0,XF0). this should allow more efficiently using the
same amount of register space (1).
also, probably have "FMOV.S @Rm, DRn", ... properly respect the machine
endianess.
1: (register bits: old; new)
0000: DR0=(FR0,FR1); DR0=(FR0,XF0)
0001: XD0=(XF0,XF1); DR1=(FR1,XF1)
0010: DR2=(FR2,FR3); DR2=(FR2,XF2)
0011: XD2=(XF2,XF3); DR3=(FR3,XF3)
...