Not it's not. Eieio is the only instruction that is designed to effect store gathering.
Sync vs Isync
sync: Waits for all instructions to complete and no subsequent instructions are initiated until the sync itself has been completed. Also ensures memory accesses complete so other processors, mechanisms, and devices see the effects.
isync: Waits for all instructions to complete, but doesn't apply to memory accesses. Store gathering and out of order load/stores can still occur. Instructions after the isync are refetched and executed with whatever context (privilege, translation, protection) that was established by the previous instructions.
Basically sync is a memory barricade, while isync is an instruction barrier in lamest terms.
Sync is also used to wait for data cache updates/flushes/etc to complete, while isync is used to wait for instruction cache updates/flushes/etc to complete.
Regarding Wii codes, isync is used for self modifying code. Sync is not required because Broadway is a single processor with a single core and we don't care about other devices seeing the effects.
example:
lis r0, 0x4E80 #Example compiled instruction for a blr
ori r0, r0, 0x0020
stw r0, 0 (r4) #Write in new instruction to memory
dcbst 0, r4 #Clean data cache block. Push cache contents to physical memory
icbi 0, r4 #Whatever instruction(s) was in the instruction cache beforehand is invalidated
isync #Purge prefetched instructions, refetch. isync is not needed if first instruction of self modified code is at least 5 would-be executed instructions ahead. This because Broadway can only fetch up to 4 instructions at a time
At this point the new blr instruction in memory is there and will be executed if called upon
Sync vs Isync
sync: Waits for all instructions to complete and no subsequent instructions are initiated until the sync itself has been completed. Also ensures memory accesses complete so other processors, mechanisms, and devices see the effects.
isync: Waits for all instructions to complete, but doesn't apply to memory accesses. Store gathering and out of order load/stores can still occur. Instructions after the isync are refetched and executed with whatever context (privilege, translation, protection) that was established by the previous instructions.
Basically sync is a memory barricade, while isync is an instruction barrier in lamest terms.
Sync is also used to wait for data cache updates/flushes/etc to complete, while isync is used to wait for instruction cache updates/flushes/etc to complete.
Regarding Wii codes, isync is used for self modifying code. Sync is not required because Broadway is a single processor with a single core and we don't care about other devices seeing the effects.
example:
lis r0, 0x4E80 #Example compiled instruction for a blr
ori r0, r0, 0x0020
stw r0, 0 (r4) #Write in new instruction to memory
dcbst 0, r4 #Clean data cache block. Push cache contents to physical memory
icbi 0, r4 #Whatever instruction(s) was in the instruction cache beforehand is invalidated
isync #Purge prefetched instructions, refetch. isync is not needed if first instruction of self modified code is at least 5 would-be executed instructions ahead. This because Broadway can only fetch up to 4 instructions at a time
At this point the new blr instruction in memory is there and will be executed if called upon