Andreas says the assumption at the start of this post is wrong, so this approach does not work, please ignore.
Does the TESTSET instruction go out to the target core via the write mesh? (I assume it does unless read mesh is 64 bit data path solely to accomodate this instruction) If so there is a possible alternative to the Read after Write sync problem.
Advantages: Core B RAM content effectively unchanged by the synchronisation. No flooding the mesh with polling read operations.
Comments welcome, especially spotting any flaws!
; Syncing remote Reads after Writes
; Program running on Core A
; Do your writes to Core B here
MOV R1,#%low(CoreBaddress) ; CoreBaddress can be any writable location in ordinary RAM
MOVT R1,#%high(CoreBaddress)
MOV R0,#0
TESTSET R0,[R1,R0] ; Do a test set on location CoreBaddress
; First a write goes from Core A to Core B (from way TESTSET works)
; This write arrives at Core B after any previous writes there from Core A program because of Write after Write guarantee
; The TESTSET acts at Core B. What happens here is cunning but irrelevant to the Read after Write sync
; if the target address is non-zero, it is unchanged.
; If it is target address is zero it is overwritten with zero in an atomic operation, effectively leaving it unchanged
; The outcome of the TESTSET goes from Core B to Core A via the write mesh
ADD R0,R0,R0 ; arbitrary instruction referencing R0, to force Core A to wait for the data to return from Core B
; Do your reads from Core B here
; Results from the reads are returned via the write mesh from Core B to Core A.
; They must come after the write the TESTSET did from B to A because of the Write after Write guarantee
TimStatistics: Posted by timpart — Fri Mar 07, 2014 8:26 am
]]>