> 2023年5月3日 22:04，Maciej W. Rozycki 写道：
>
> On Wed, 3 May 2023, Richard Sandiford wrote:
>
>>> speculation_barrier for MIPS needs sync+jr.hb (r2+),
>>> so we implement __speculation_barrier in libgcc, like arm32 does.
>>
>> Looks reasonable, but do you have a source for the fallback
>> pre-r2 handling? (Thanks for adding that btw, since I realise
>> it's not your focus here.)
>
> Seconded WRT legacy MIPS support, really appreciated.
Hi all,
Just my two cents on legacy MIPS support.
Since it’s possible to run R2- binary on R2+ processor, we’d better find a
semantic that do eliminate speculation on all processors. While SSNOPs
on R2+ processors is pretty much undefined, there is no guarantee that
SSNOP sequence can eliminate speculation.
My proposal is for R2- CPUs we can do a dummy syscall to act as instruction
hazard barrier, since exception must clear the pipeline this should be true
for all known implementations.
The most lightweight syscall I know is to do a MIPS_ATOMIC_SET with
sysmips. A dummy variable on stack should do the track. Do let me know if there
is a better option.
I have a vague memory about a discussion finding that exception does not
indicate
a memory barrier, so perhaps we still need a sync preceding to that syscall.
>
> I think there may be no authoritative source of information here, this is
> a grey area. The longest SSNOP sequences I have seen were for the various
> Broadcom implementations and counted 7 instructions. Both the Linux
> kernel and the CFE firmware has them.
Was it for SiByte or BMIPS?
>
> Also we may not be able to fully enforce ordering for the oldest devices
> that do not implement SYNC, as this is system-specific, e.g. involving
> branching on the CP0 condition with the BC0F instruction, and inventing an
> OS interface for that seems unreasonable at this point of history.
I guess this is not a valid concern for user space applications?
As per R4000 manual BC0F will issue “Coprocessor unusable exception”
exception and it’s certain that we have Staus.CU0 = 0 in user space.
BC0F is not mentioned in MIPS-IV and later MIPS specs.
Thanks
Jiaxun
>
> OTOH Linux emulates any traps on SYNC and even though the handler does
> nothing beyond decoding the instruction the exception handling overhead
> ought to make all the effects from before the exception invocation fully
> visible after its completion. So for Linux targets I think we ought to
> just emit SYNC unconditionally; glibc has already relied on it for years
> now.
>
> Overall, oh well, I guess we'll have to live with the limitations.
>
> Maciej
