[J-core] json instructions set

[BGB]

On 6/27/2017 12:11 PM, Cedric BAIL wrote:

(deciding to just post this as-is, it kind of sucks, but I am tired of 
editing it)

<snip, nothing to add>

>>> I don't think this work is impacted by the original
>>> license of the code that generate
>>> http://www.shared-ptr.com/sh_insns.html (GPLv3 doesn't apply on the
>>> output of the program and you can run that program locally). I have
>>> also not extracted the svg that the original site contain to not be
>>> affected by the GPLv3. So all in all, I think this is fine to be
>>> relicensed (I have checked in the node.js script I have used to
>>> extract the information and I made sure that all manual modification
>>> where visible in the git history).
>>>
>>> My hope here would be that the J-Core project accept this as the first
>>> J-Core github project and that we can use this for future discussion
>>> on new instructions. Maybe it could also become a documentation
>>> repository for the J-Core in general (This file only cover
>>> instructions for the  moment and there is clearly more to a CPU than
>>> just its instructions set).
>> More than happy to see if we can do that, yes!
>>
>> One thing I want to caution:  Instruction set extensions are guarded like the crown jewels.  It really, really is internally here a consensus process, with a case needing to be made for -why- they precious encoding space should be used.  There have been a large number of proposed formats, space reservations, coprocessor encodings, etc proposed... nothing has ever reached consensus with the exception of CAS.L.  Of course, the best way to get such a proposal adopted is to show it's value, so we encourage experimentation.  BGB's independent experiments for instance with compilers other than GCC and LLVM, instructions etc, while not a part of the project contribute experimental results.  It is unlikely, for instance, that a 64bit mode that isn't carefully designed, including instruction frequency counts from mainstream compiler ports, could go into either J-Core documentation or RTL repos.
> I fully agree with you here as this would be like any open source
> project. Discussing goal, building a proposal and getting a consensus
> before it become accepted and merged.
>
> I have some personnal idea that I will later write another email about
> to describe my goal and general idea to get feedback to check the
> general direction I am heading to, but I wouldn't ask a pull request
> before I have enough assembly example and some numbers from gcc or
> llvm. Ideally I would like to be able to actually have some patch for
> J-Core vhdl.

likewise; for my own design, I want to at least try to get a good 
working prototype of the extended-ISA together. issues have come up 
fairly often where I look at something and realize the specifics were 
not thought out well enough. this is along with cases where parts of my 
spec have gotten out of sync with the current working design, ...

thus far, I have a partial subset of the 32-bit extended ISA 
implemented, but the 64-bit ISA hasn't been implemented as-of yet (and 
some of the details are still a little fuzzy).

a lot of this currently hinges on having support in terms of a C compiler.


as noted already, most of my ISA extensions are the form of 32-bit 
extended I-forms, mostly under the 8Exx prefix block. this being mostly 
because there is a lot more encoding space available for new operations 
in terms of 32-bit instruction-forms (provided at least it isn't 
squandered).

I have recently repurposed the 8Cxx block from being "LDSH8" to another 
32-bit I-form block.

I have used part of this block in a functionally vaguely similar way to 
a REX prefix, mostly using it to encode operations with an explicit 
size, and also to allow a larger logical register space for 32-bit ops. 
this effectively allows 32 GPRs for 32-bit operations, mostly in the 
form of the high half of the first 16 GPRs; as a result the number of 
64-bit GPRs will be limited to 16. similar also applies to the FPU 
(which will effectively have 32 usable single-precision registers and 16 
double-precision registers).

the normal 16-bit I-forms remain limited to 16 GPRs, and many operations 
in 64-bit mode will have their size controlled by bits in SR (sort of 
similar to how FPSCR works).


>> I mention this caution because if it does become the documentation set for the cores, it has to reflect the stable, mature status of the ISA and Cores.  Experimental stuff can always go into separate repos...
> Yes, if it is on J-Core github, I would expect it to reflect only what
> is stable, mature and can be relied on.

yeah.

this is an issue on my front, namely that a lot of my specs are 
speculative/incomplete/incorrect/out-of-sync/...
partly this is because a lot of them are more a reflection of my current 
possible thoughts/ideas, than a description of stuff as it is.

as more stuff gets implemented and tested, it is likely I will start 
working on another BJX1 spec reflecting the ISA as-implemented.

as-for the 64-bit ISA, it will likely still be a little longer before I 
can begin testing it.


some initial tests on using larger constant-load and Disp8 and Disp12 
instructions has shown a somewhat smaller reduction in code-size than 
originally expected (only about 2%), but does seem to have some 
improvement in terms of emulator performance.

an uncertainty here is whether my compiler is making particularly 
effective use of these instructions.


however, the output I am getting does appear to be smaller than I am 
currently able to get from GCC (20% vs "-O2", 41% "-O0"; 5% vs "-O1" but 
binary is broken; "-Os" currently fails to compile).

it is pros/cons though, my compiler is still pretty buggy and 
incomplete, and generated code is currently slower than that produced by 
GCC; but initial results seem promising at least.