<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Oct 26, 2017 16:14, "Rob Landley" <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 10/25/2017 06:59 PM, Ken Phillis Jr wrote:<br>
> I figure I will include my Idea for an easy to use SIMD Extension for<br>
> the J-Core. In general this extension will be used for Three Types of<br>
> number formats...<br>
<br>
</div>One of the blue sky J64 proposals Jeff mentioned (let me see if I can<br>
remember the details) was 2 control bits per register letting you<br>
specify that register contains 8/16/32/64 bit SIMD, meaning a single 32<br>
bit control register could control SIMD state for 16 general purpose<br>
registers. Then you use the normal operations to deal with<br>
signed/unsigned, multiply, and so on.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">That does sound like a clever trick. But I am not sure of how you differentiate between simd being on or off for that register (you could have a 256 bits register with operation on 32 bits). Still the idea of a register is neat and could make it easy during context switch.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The next question was how to deal with source/target size mismatches: in<br>
theory a 64 bit source iterating over 8 bit targets could apply a single<br>
64 bit source value to all 8 targets, a 32 bit source could go<br>
1-2-3-4-1-2-3-4, etc. In practice what that makes the ALU look like is a<br>
question that needs some code prototyping I think...<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I am guessing the microcode will also look crazy complex. Is there a limit on this side to ?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> New Registers: simd0 to simd15<br>
> These Registers are 128-bits in size, and are used to perform a bulk<br>
> of the SIMD Math.<br>
<br>
</div>Is there a way to do that and _not_ quadruple the size of the processor?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">If you are not looking for massive performance improvement, but just more compact core loop. You would have to pay for the increase in the register bank, but you do not need to multiply the ALU by more than the max word than you operate on (and have the microcode iterate over each word in a register). That would keep things in check, no?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> SIMD Configuration Instructions:<br>
><br>
> SIMD.IMODE - This configures the Integer Math mode of the Integer SIMD<br>
> Operations. The accepted modes should include the following:<br>
> * Integer Carry Mode - See ADDC and SUBC for example.<br>
> * Value UnderFlow and OverFlow Mode - See ADDV and SUBV¬† for examples.<br>
> * Integer Type: Signed and Unsigned values with sizes of 8-bit,<br>
> 16-bit, 32-bit, and 64-bits.<br>
<br>
</div>We're really short on instruction space. We fit j64 in, but had to<br>
repurpose several existing instructions in 64 bit mode to do it.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">For the needed addition, as they will not be used very often, having a prefix that enable a new instruction set temporary would limit the problem. Even then, the instruction space is quite limited and adding an instruction require careful thinking and testing different scenario.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> Data Loading/Conversion Instructions:<br>
> Bulk Conversion From Integers to Floats, and Floats to integers is a<br>
> must. That said, I'm not exactly sure how many Instructions are needed<br>
> for this, but It would be reasonable to say that four to seven<br>
> instructions may be required.<br>
<br>
</div>In Jeff's design you'd copy from register in one mode to register in<br>
another mode, then do a rotate by enough bits you could do the next one,<br>
and a rotate at the end if you needed to restore the register? (Hmmm,<br>
that sounds like it would need an xor on the mode thing between those so<br>
the rotate wasn't within the simd division? Possibly I misunderstood, it<br>
was a while ago...)<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">One of the thing that killed the performance of early simd cpu was the lack of efficient way of shuffling bits around. I think there is still potentially patent on power pc shuffling instruction, but something that allow rotation by word step would go a long way (again that can be in the vector instruction space).</div><div dir="auto"><br></div><div dir="auto">Cedric</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Rob<br>
</font><div class="elided-text">______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a><br>
</div></blockquote></div><br></div></div></div>