<div dir="ltr">..<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">) Speaking of which we really need somebody to bring qemu up<br>
to speed with j-core, so far it just does superh.<br></blockquote><div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">Currently there are only a few instructions to backport.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> A Sandsifter like tool can be used to compare actual behavior and<br>
> simulated behavior of a CPU family. That approach might be interesting<br>
> for j-core too.<br>
<br>
</span>Indeed. I'd be interested in seeing what you come up with if you give it<br>
a try.</blockquote><div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">I hope you do not mean *you* in the sense that i should give it a try.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> However j-core has a fixed length instruction set (every<br>
instruction is 16 bits, the trick is you can index relative to any<br>
register so constants are loaded relative to code pointer and stuck<br>
right before or after the function by the compiler).<br></blockquote><div style="font-family:monospace,monospace" class="gmail_default">Sounds very default.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So the main new trick of drilling down to see what variable length stuff<br>
gets parsed is difficult to apply to this context.<br></blockquote><div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">Oh please keep instruction lengths </div> <div style="font-family:monospace,monospace;display:inline" class="gmail_default">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)))<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That said, the proposed j64 design (which I need to write up and post to<br>
the website on my next trip to Japan) adds a mode bit that interprets<br>
some instructions differently. (16 bit operations become 64 bit<br>
operations, for example, so you have 8, 32, and 64 bit and the compiler<br>
would need to do funky things for "short". Or maybe toggle the mode bit,<br>
dunno what'll wind up being cheapest.)</blockquote><div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">Good that you take a look at a wide set of options</div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So that's somewhat unavoidably<br>
going to introduce complexity to the instruction set parsing, and it'd<br>
be nice to have a systematic test to prove we didn't screw something up<br>
when we get around to implementing that. :)<br></blockquote><div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">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.<br></div><div style="font-family:monospace,monospace;display:inline" class="gmail_default">Formal verification is king in the end.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Rob<br>
</blockquote></div><br></div></div>