[Libre-soc-dev] LD/ST Elwidth Overrides

[lkcl]

On September 2, 2021 5:26:52 PM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Thu, Sep 2, 2021, 03:56 lkcl <luke.leighton at gmail.com> wrote:
>
>>
>>
>> On September 1, 2021 8:48:43 PM UTC, Jacob Lifshay <
>> programmerjake at gmail.com> wrote:
>>
>> >
>> >idk, but the point is the encoding supports it, so we have to
>account
>> >for
>> >malicious programmers.
>>
>> thought about it: no *we*, as spec writers, do not. the *hardware
>> implementors* have to take responsibility for that.
>>
>> in many cases when writing specifications the delineation and
>separation
>> between those two responsibilities is not at all clear, in fact the
>total
>> opposite, they are very closely interrelated. however in this unique
>and
>> special case they are separatable.
>>
>> implementors in this particular unique special case *may* choose to
>> terminate fail-first at any point.
>>
>
>Umm, I don't think that should be left up to implementers, since iirc
>the
>semantics of ffirst is it fails when it hits a page fault
>(deterministic
>from a spec perspective), not that it fails for any arbitrary reason...

that's incorrect: it's described clearly that (aside from the very first element which MUST behave as if ffirst was not active at all, i.e. MUST raise exceptions if any) that implementors from that second element onwards are entirely at liberty to truncate VL to absolutely any point they feel like...

... up to the limit of a point where an exception might occur.

you may be confusing Data-Dependent FFIRST with LD/ST FFIRST.

Data-Dependent FFIRST is **NOT** permitted to perform abitrary truncations.  Data-Dependent FFIRST **MUST** truncate (set) VL to the point at which the Element-based Condition Test fails, and to no other point, certainly not an arbitrarily-chosen one.

this is not Data-Dependent FFIRST, it is LDST FFIRST, and the behaviour is subtly different.


>Therefore, the exact algorithm for choosing ffirst stopping point needs
>to
>be in the spec and be deterministic, 

no, it really doesn't.  if this were Data-Dependent FFIRST you would be correct, but it's not, it's LDST FFIRST.

the reasons why implementors have near-total freedom on what point they truncate VL to is two-fold:

1) resources.

it may be that the hardware just doesn't have enough in-flight Reservation Stations.

ordinarily this would be a serious (hard) "stall" condition however by truncating VL they can continue immediately.

2) alignment.

by choosing to exercise the OPTION to truncate just before a misaligned LD/ST (or page boundary, or any other arbitrarily-chosen boundary which would otherwise consume excessive resources to process) the **NEXT** time round a LD/ST inner loop the NEXT batch of ffirst LD/STs will be much more efficient.

that next batch size may then also be chosen (within the limit 1..VL) to be a perfect match for memory alignment at the hardware level, again, regardless of what VL was actually set to


with the option already well defined it is trivial to mention that implementors may choose to make truncation to VL=1 non-optional, and that is their choice and responsibility.


>How about this: ffirst works in all vector addressing modes (including
>strided, gather, unit stride, etc.) but it stops the first time it
>tries to
>access more than 1 page (or some other small spec-determined number
>such as
>2 or 4) regardless if that would cause a page fault or not.

the hardware is already entirely at liberty to be implemented that way and that freedom DOES NOT require making it entirely mandatory and does not require the spec to state that because it is up to the implementor to choose what to do and what design criteria to take into account.

l.