@MSGID: <jwvedil530g.fsf-monnier+comp.arch@gnu.org>
cc090be2
@REPLY: 1@dont-email.me> 6584331c
@REPLYADDR Stefan Monnier
<monnier@iro.umontreal.ca>
@REPLYTO 2:5075/128 Stefan Monnier
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<jwvedil530g.fsf-monnier+comp.arch@gnu.org>
<57c5e077-ac71-486c-8afa-edd6802cf6b1n@googlegroups.com> -3ce5e24aec0cn@googlegroups.com><5fa92a78-d27c-4dff-a3dc-35ee7b43cbfan@googlegro
ups.com><c9131381-2e9b-4008-bc43-d4df4d4d8ab4n@googlegroups.com> 4b4-ae81-5ab1ef234f8en@googlegroups.com><43901a10-4859-43d7-b500-70030047c8b2n@g
ooglegroups.com><jwvzg1acja6.fsf-monnier+comp.arch@gnu.org> email.me><jwvil7yces1.fsf-monnier+comp.arch@gnu.org> e>
@TZUTC: -0400
@PID: Gnus/5.13 (Gnus v5.13)
@TID: FIDOGATE-5.12-ge4e8b94
>> E.g. load 3 chunks (C1, C2, and C3) of 256bits each using standard SIMD
>> load, and then add an instruction to turn C1+C2 into two 256bit vectors
>> of 4x64bit floats, and another to do the same with C2+C3 (basically, the
>> same instruction except it uses the other half of the bits of C2).
> I don`t really have a good way to do 256-bit loads or work with 256-bit
> vectors in my core.

Then do 3x 64bit loads which you then split into 4 64bit floats:

        64bit                64bit                 64bit
     +---------+   +-------------------------+  +---------+
     A0-31 B0-31   A32-47 B32-47 C32-47 D32-47  C0-31 D0-31

It`s an admittedly unusual layout, but lets you load&store in standard
sized chunks, and hence full-bandwidth.  And lets you "reshuffle" things
using only "2-in" operations: if your pipeline can do "2-in 2-out" you
can do it two (parallel) instructions and otherwise you can do it in
4 (parallel) instructions.  Of course, if your pipeline can accommodate
"3-in 4-out", then you can use a more standard layout.

> The Float48 format is basically special case Load/Store ops which pad the
> value to 64 bits on Load, and narrow it to 48 bits on Store.

So you`re wasting the extra L1 bandwidth since you`re using a load which
can fetch 64bit but only use 48 of those bits (you admittedly still
gain w.r.t to the bandwidth of higher levels of the memory hierarchy).


        Stefan
--- Gnus/5.13 (Gnus v5.13)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441