create the main SVP64 Chapter which contains the SVP64 Prefix format, as well as the four different "Modes".
mostly written, now, after doing significant inline updates from copies of multiple SVP64 pages, those are now put *back* into their respective wiki pages and an "include" system used instead. caveats: LD/ST Data-Dependent-Fail-First needs implementing first as a safety-check (bug #1047) so this RFC cannot be submitted until that's done.
Luke, on page 4 of ls010.pdf (after "However if elwidth overrides are set to 16 for both source and destination:"), the pseudo-code modifies the int_regfile.halfs struct member, however 'halfs' has not been defined in the earlier struct definition. Is it meant to say 'hwords' instead?
> Is it meant to say 'hwords' instead? done, to match figure 97 in Public v3.1 p 258 i think.
in https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=e06a0faffba0c18150d3ba09c7b16f637885c40f you say: > It should be self-evident that being able to > Vectorise and then truncate a sequence of Atomic Store-Conditional > operations at the point where a store was not performed, should > be pretty important. its importance isn't self-evident to me, because, unless we create an extension to lr/sc to have multiple reservations, every store-conditional after the first one will always fail, because the first one cleared the reservation. this makes any vectorized store-conditional a misuse of features -- yeah, you can write it and it runs, but it doesn't usefully do anything different than the scalar version... that's all unless you can use vertical-first mode and have it still work or something... If PowerISA gains atomic fetch-add with Rc=1 or similar fetch-op instructions, then data-dependent fail-first will actually be useful, because the fetch-op instruction wouldn't need a paired load-reserve to function.
(In reply to Jacob Lifshay from comment #4) > in > https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff; > h=e06a0faffba0c18150d3ba09c7b16f637885c40f > > you say: > > It should be self-evident that being able to > > Vectorise and then truncate a sequence of Atomic Store-Conditional > > operations at the point where a store was not performed, should > > be pretty important. > > its importance isn't self-evident to me, because, unless we create an > extension to lr/sc to have multiple reservations, every store-conditional > after the first one will always fail, yep seriously-important catch. we're running out of time and i'm missing things, so thank you. > that's all unless you can use vertical-first mode and have it still work or > something... yes, it's possible. LRs will be in sequence with SCs, back round the explicit-loop to the next register. DD-FF-conditions spot the fail and exit the loop. > If PowerISA gains atomic fetch-add with Rc=1 or similar fetch-op > instructions, then data-dependent fail-first will actually be useful, > because the fetch-op instruction wouldn't need a paired load-reserve to > function. i'll put a note about leaving the RISC-paradigm concept in, for future expansion.
commit fba04aa8ae27751053f558ad0a1a48784e578d0d Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Apr 5 20:09:18 2023 -0700 switch to using mdwn_inline instead of special-cases in Makefile also automatically tracks [[!include]] dependencies commit 6682d9d673c8cff1323c4979b2d0bfb74e2cc9ac Author: Jacob Lifshay <programmerjake@gmail.com> Date: Wed Apr 5 20:00:50 2023 -0700 add inlines in prep for using mdwn_inline.py instead of special-cases in Makefile
submitted to the OPF ISA WG today https://ftp.libre-soc.org/opf_ext_rfc/ls010.v1.13apr2023.pdf