From: lkcl Date: Sun, 24 Jan 2021 11:57:50 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~362 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=a13ea210520824aeac8649fe55a52fdadee6977c;p=libreriscv.git --- diff --git a/openpower/sv/ldst.mdwn b/openpower/sv/ldst.mdwn index e019d9e9b..4ef90b1c3 100644 --- a/openpower/sv/ldst.mdwn +++ b/openpower/sv/ldst.mdwn @@ -178,7 +178,7 @@ others like it provide an explicit operation width. There are therefore *three* widths involved: * operation width (lb=8, lh=16, lw=32, ld=64) -s src elelent width override +* src elelent width override * destination element width override Some care is therefore needed to express and make clear the transformations, @@ -278,3 +278,13 @@ min/max Vectorised instructions as post-processing stages. Thus we do not need to provide specialist LD/ST "Structure Packed" opcodes because the generic abstracted concept of "Remapping", when applied to LD/ST, will give that same capability, with far more flexibility. + +# notes from lxo + + sv.ld r#.v, ofst(r#).v -> the whole vector is at ofst+r# + sv.ld r#.v, ofst(r#.v) -> r# is a vector of addresses + similarly sv.ldx r#.v, r#, r#.v -> whole vector at r#+r# + whereas sv.ldx r#.v, r#.v, r# -> vector of addresses + point being, you take an operand with the "m" constraint (or other memory-operand constraints), append .v to it and you're done addressing the in-memory vector + as in asm ("sv.ld1 %0.v, %1.v" : "=r"(vec_in_reg) : "m"(vec_in_mem)); + (and ld%U1 got mangled into underline; %U expands to x if the address is a sum of registers