On Thu, 1 Oct 2020, Hev wrote:
> > I see your point, but isn't taking an exception already more than a
> > compiler barrier ? Does the missing sync hurt in real life ?
>
> As far as I known, the optional sync instruction has been used in user
> space programs (such as firefox), and the illegal instruction
> exception does not include the semantics of the memory barrier, so if
> the optional sync instruction is not simulated, the memory access
> order of these programs it may be different from the order in the
> code.
Your concerns as to ERET not implying any of the SYNC semantics seem
valid to me.
> About the compiler barrier, What if the hardware does not support SYNC
> 0? I think it does not support SMP, so smp_mb() is only a compiler
> barrier and will not cause infinite recursion in the simulation.
However both SYNC 0 is mandatory (save for ancient MIPS I ISA processors)
and other SYNC operations have to fall back to SYNC 0 if not specifically
implemented. Even MIPSr1 had this[1][2]:
"SYNC does not guarantee the order in which instruction fetches are
performed. The stype values 1-31 are reserved for future extensions to
the architecture. A value of zero will always be defined such that it
performs all defined synchronization operations. Non-zero values may be
defined to remove some synchronization operations. As such, software
should never use a non-zero value of the stype field, as this may
inadvertently cause future failures if non-zero values remove
synchronization operations."
and MIPSr0.95 was even stricter[3][4]:
"SYNC does not guarantee the order in which instruction fetches are
performed. The stype values 1-31 are reserved; they produce the same
result as the value zero."
so I suggest a board/CPU-specific workaround.
References:
[1] "MIPS32 Architecture For Programmers, Volume II: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 1.00, August 29, 2002, p. 209
[2] "MIPS64 Architecture For Programmers, Volume II: The MIPS64
Instruction Set", MIPS Technologies, Inc., Document Number: MD00087,
Revision 1.00, August 29, 2002, p. 295
[3] "MIPS32 Architecture For Programmers, Volume II: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 0.95, March 12, 2001, p. 215
[4] "MIPS64 Architecture For Programmers, Volume II: The MIPS64
Instruction Set", MIPS Technologies, Inc., Document Number: MD00087,
Revision 0.95, March 12, 2001, p. 300
HTH,
Maciej
