Status of smptests ...?

[Sebastian Huber]

----- Am 11. Dez 2018 um 16:47 schrieb Jiri Gaisler jiri at gaisler.se:

> On 12/11/18 4:01 PM, Sebastian Huber wrote:
>> On 11/12/2018 15:55, Jiri Gaisler wrote:
>>>> Even if the screen is a guide of what to expect in some cases.
>>>>
>>>> How does the smp support in sis switch back and forth between the
>>>> cores? Per cycle, instruction, etc. Qemu switches per instruction
>>>> translation block as I recall.
>>> The scheduling slice is (dynamically) configurable in number of clock
>>> cycles. I currently have it set to 50 but the smp tests works also at
>>> 1000. The scheduling overhead is ~ 10% at 50 cycles, so the slowdown is
>>> acceptable even for non-smp loads. My plan is to simulate each cpu
>>> instance in a separate host thread, and synchronize them on events in
>>> the event queue. Not quite sure how well that will work though ...:-)
>>
>> How do you synchronize the simulated memory accesses across the threads?
> 
> For regular LD/ST instructions, reading and writing memory is atomic
> (single host instruction) so no particular synchronization is needed.
> For SPARC atomic instructions (CASA, SWAP, LDST) and peripheral access
> (APB bus), I plan to use mutexes around the memory access function call.
> This might fail if RTEMS uses standard ST instructions to write to
> semaphores instead of CASA etc. Having mutexes on all memory access will
> probably be too slow ...

This works only if the simulator host has the same or stronger memory ordering guarantees as the simulated target.  On a x86_64 host this is probably all right, but not if you run the simulator on an ARM or RISC-V machine.

Maybe you can use C11 atomic operations for the memory accesses to ensure the implicit acquire/release and TSO.