[J-core] Breaking the x86 Instruction Set - Lot's of undocumented instructions found in x86 at this years black hat conference

[Joh-Tob Schäg]

..

> ) Speaking of which we really need somebody to bring qemu up
> to speed with j-core, so far it just does superh.
>
​Currently there are only a few instructions to backport.​


>
> > A Sandsifter like tool can be used to compare actual behavior and
> > simulated behavior of a CPU family. That approach might be interesting
> > for j-core too.
>
> Indeed. I'd be interested in seeing what you come up with if you give it
> a try.

​I hope you do not mean *you* in the sense that i should give it a try.​


> However j-core has a fixed length instruction set (every
> instruction is 16 bits, the trick is you can index relative to any
> register so constants are loaded relative to code pointer and stuck
> right before or after the function by the compiler).
>
​Sounds very default.​

>
> So the main new trick of drilling down to see what variable length stuff
> gets parsed is difficult to apply to this context.
>
​Oh please keep instruction lengths ​

​constant or have two different sizes at max. Once you have flexible
instruction size things scale more badly. (In a talk about the Mill CPU i
heard that parsing fixed length takes O(N) while size flexible parsing does
cost O(N*ln(N)))

>
> That said, the proposed j64 design (which I need to write up and post to
> the website on my next trip to Japan) adds a mode bit that interprets
> some instructions differently. (16 bit operations become 64 bit
> operations, for example, so you have 8, 32, and 64 bit and the compiler
> would need to do funky things for "short". Or maybe toggle the mode bit,
> dunno what'll wind up being cheapest.)

​Good that you take  a look at a wide set of options​
​.​


> So that's somewhat unavoidably
> going to introduce complexity to the instruction set parsing, and it'd
> be nice to have a systematic test to prove we didn't screw something up
> when we get around to implementing that. :)
>
​Well you have not proven anything! You just performed an experiment which
suggested that there are no faults in a small area of the source space.
Formal verification is king in the end.​


>
> Thanks,
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20170909/5355adf2/attachment.html>