On 06/27/2014 09:46 AM, Tim Northover wrote:> Hi Philip,
>
>> Aside: From the documentation, it's actually unclear how strong a
barrier
>> ISB actually is. The "fetched after the ISB" gives a lot of
room for
>> interpretation. (i.e. is it legal for a cpu to fetch every instruction
in a
>> function, queue them for execution under wait conditions, *then* fetch
the
>> ISB? This would be a *really* weird implementation, but would it be
legal
>> according to this spec? If so, the ISB provides *no* guarantees.)
>>
>> Reference:
>>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGHHIE.html
> You've actually linked to the assembler (as in "armasm")
reference
> manual there. The architectural documentation of these barriers is
> better, though still not airtight in my opinion. From section A3.8.3,
> the bit about "program order" is new, and it's after the ISB
has
> *completed*:
Figured there had to be something better, but that's what google found
me. Thanks.>
> "An ISB instruction flushes the pipeline in the processor, so that all
> instructions that come after the ISB instruction in program order are
> fetched from cache or memory only after the ISB instruction has
> completed."
Not seeing the full text, this still looks incomplete. I think we can
infer what was actually meant here, so it doesn't make much of a
practical difference.>
> It's behind a registration wall, but the v7 version can be had as a
> .pdf here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html
Also behind a registration wall. I might bother find my old account
info at some point, but not right now.
Philip