Re: V4 core speculative execution?

--000e0cd24492c56ddc046794c7d2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Tim,
 Sorry I was mistaken. 55555555 is cacheable and changing it to a
non-cacheable address stops the bus error. The problem is though that
55555555 was just an arbirtary example. In general it could be anywhere,
including I/O address, where random reads could cause some very obscure
bugs.

Regards, Chris

2009/4/15 nop head <[email protected]>

> Hi Tim,
>
>
>> We have our RTOS running very reliably on V4E processors and aren't
>> having any problems like this. These issues are related to your
>> RAMBAR, ACR, and MMU configuration, and whether regions are set for
>> precise or imprecise accesses. Imprecise mode allows speculative
>> accesses, precise mode doesn't.
>
>
> Yes I also have an RTOS running and as far as I can tell that works.
> Normally in C pointers point to a valid object, or one past the end of an
> array, or are NULL, in which case you could get away with speculatively
> derefencing them as long as address 0 was readable. It is only where I have
> unions where a pointer and a scalar share the same 32 bit field.
>
> I am not using the MMU. 55555555 matches no ACRs RAMBARs or chip selects so
> it should use the default cache mode in CACR which is inhibited precise.
>
>
>>
>>
>> > Why does it sometimes lock the processor rather than giving an XLB
>> > interrupt.
>>
>> May be related to the fact that bus errors in background debug mode
>> can hang the processor.
>
>
> It locks up even with BDM not connected. When BDM is connected the debugger
> has to assert reset to get the CPU to enter background mode.
>
> Oddly if I set A0 to an invalid address that doesn't make the branch
> condition, e.g. 55555554, then it actually tries to jump to that address and
> always gets an XLB bus error as expected. It only seems to be this
> speculative fetch that sometimes locks up, sometimes bus errors. For a
> particular program it will always do the same thing but if code moves about
> a bit it can either work, lock up, or bus error.
>
>  I don't know whether this just applies to pointers to function or whether
> pointers to objects could be speculatively dereferenced as well. It seems
> like a major bug in the core but I can't find any referenc to it. I do
> vaguely remember a few years ago reading that somebody had to make address 0
> readable to prevent bus errors on NULL pointers. I foolishly thought such a
> major bug would have been fixed by now.
>
> The really wierd thing is that having an active breakpoint seems to fix it.
> Does that mean that having a dormant breakpoint modifies the processors
> prefetch behavior, reducing its performance? If so, it allows a whole new
> class of Heisenbugs.
>
> Chris
>
>>
>>
>> Best regards,
>> Tim
>>
>> nop head wrote:
>>
>>> I am having a problem with code that works on 68K and V3 Coldfires not
>>> working on V4. I find it hard to believe, but it looks like the V4 core
>>> partially executes code that is branched around. Here is a distilled example
>>> of the sort of code that fails, not pretty but I think it is valid C: -
>>>
>>> typedef void (*f_ty)(void);         // a function pointer
>>>
>>> // A union of an integer and a pointer, initialised to an integer that is
>>> not a valid address
>>> union {
>>>    int x;
>>>    f_ty  f;
>>> } p = { 0x55555555 };
>>>
>>> // This is the sort of sequence that fails
>>> {
>>>       dword d = p.x;
>>>        f_ty f = p.f;
>>>        if(d != 0x55555555)
>>>             f();
>>>  }
>>>
>>> This compiles to: -
>>>
>>>     movea.l  _p,a0
>>>     cmpa.l  #0x55555555
>>>     beq.s    skip
>>>     jsr       (a0)
>>> skip
>>>
>>> So a0 should contain all 5's, which is not a valid address in my map, but
>>> the branch should prevent it being used as an address. What actually
>>> happends seems to depend on the code alignment, etc.
>>>
>>> It can simply run past the code OK.
>>>
>>> It can give an XLB interrupt with 55555554 in the address capture
>>> register.
>>>
>>> It can lock up the processor. When I hit break in my BDM debugger the PC
>>> is a couple of instructions past this block.
>>>
>>> If I set a breakpoint anywhere in the program the code runs OK,
>>> regardless of whether the breakpoint is triggered.
>>>
>>> So it looks like the core sometimes does a pre-fetch on 55555555, even
>>> though it will not be executed. My questions are: -
>>>
>>> Is this a known bug/feature in the V4 core?
>>> Why does it sometimes lock the processor rather than giving an XLB
>>> interrupt.
>>> Why does having a breakpoint active make it work?
>>> Is that a workaround or do I have to find all the places in my code that
>>> this could happen an insert NOPs or something. A complete nightmare because
>>> I have a whole state machien architecture that relies on being able to
>>> contain addresses and some flags in the same 32 bit value!
>>>
>>> Chris
>>>
>>>
>>> [email protected] Send a post to the list.
>>> [email protected] Join the list. [email protected] the list in digest mode.
>>> [email protected] Leave the list.
>>>
>>
>> ------------------------------------------------------------
>> Tim Stoutamore, Principal Engineer
>> Blunk Microsystems, LLC
>> 6576 Leyland Park Drive
>> San Jose, CA 95120-4558
>> Tel: 408/323-1758
>> [email protected]
>> www.blunkmicro.com
>> ------------------------------------------------------------
>> ---
>> [email protected]              Send a post to the list.
>> [email protected]        Join the list.
>> [email protected]    Join the list in digest mode.
>> [email protected]     Leave the list.
>>
>>
>

--000e0cd24492c56ddc046794c7d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Tim,<br>=A0Sorry I was mistaken. 55555555 is cacheable and changing it t=
o a non-cacheable address stops the bus error. The problem is though that 5=
5555555 was just an arbirtary example. In general it could be anywhere, inc=
luding I/O address, where random reads could cause some very obscure bugs.<=
br>
<br>Regards, Chris<br><br><div class=3D"gmail_quote">2009/4/15 nop head <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">nop.head@goog=
lemail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"bor=
der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-=
left: 1ex;">
Hi Tim,<br><br><div class=3D"gmail_quote"><div class=3D"im"><blockquote cla=
ss=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); marg=
in: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br></div>
We have our RTOS running very reliably on V4E processors and aren&#39;t<br>
having any problems like this. These issues are related to your<br>
RAMBAR, ACR, and MMU configuration, and whether regions are set for<br>
precise or imprecise accesses. Imprecise mode allows speculative<br>
accesses, precise mode doesn&#39;t.</blockquote><div>=A0</div></div><div>Ye=
s I also have an RTOS running and as far as I can tell that works. Normally=
 in C pointers point to a valid object, or one past the end of an array, or=
 are NULL, in which case you could get away with speculatively derefencing =
them as long as address 0 was readable. It is only where I have unions wher=
e a pointer and a scalar share the same 32 bit field.<br>

<br>I am not using the MMU. 55555555 matches no ACRs RAMBARs or chip select=
s so it should use the default cache mode in CACR which is inhibited precis=
e.<br>=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D=
"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd=
ing-left: 1ex;">

<div><br>
<br>
&gt; Why does it sometimes lock the processor rather than giving an XLB<br>
&gt; interrupt.<br>
<br></div>
May be related to the fact that bus errors in background debug mode<br>
can hang the processor.</blockquote></div><div><br>It locks up even with BD=
M not connected. When BDM is connected the debugger has to assert reset to =
get the CPU to enter background mode. <br><br>Oddly if I set A0 to an inval=
id address that doesn&#39;t make the branch condition, e.g. 55555554, then =
it actually tries to jump to that address and always gets an XLB bus error =
as expected. It only seems to be this speculative fetch that sometimes lock=
s up, sometimes bus errors. For a particular program it will always do the =
same thing but if code moves about a bit it can either work, lock up, or bu=
s error.<br>

<br>=A0I don&#39;t know whether this just applies to pointers to function o=
r whether pointers to objects could be speculatively dereferenced as well. =
It seems like a major bug in the core but I can&#39;t find any referenc to =
it. I do vaguely remember a few years ago reading that somebody had to make=
 address 0 readable to prevent bus errors on NULL pointers. I foolishly tho=
ught such a major bug would have been fixed by now.<br>

<br>The really wierd thing is that having an active breakpoint seems to fix=
 it. Does that mean that having a dormant breakpoint modifies the processor=
s prefetch behavior, reducing its performance? If so, it allows a whole new=
 class of Heisenbugs.<br>

<br>Chris<br></div><div><div></div><div class=3D"h5"><blockquote class=3D"g=
mail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Best regards,<br>
Tim<br>
<br>
nop head wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><=
div>
I am having a problem with code that works on 68K and V3 Coldfires not work=
ing on V4. I find it hard to believe, but it looks like the V4 core partial=
ly executes code that is branched around. Here is a distilled example of th=
e sort of code that fails, not pretty but I think it is valid C: -<br>


<br>
typedef void (*f_ty)(void); =A0 =A0 =A0 =A0 // a function pointer<br>
<br>
// A union of an integer and a pointer, initialised to an integer that is n=
ot a valid address<br>
union {<br>
 =A0 =A0int x;<br>
 =A0 =A0f_ty =A0f;<br>
} p =3D { 0x55555555 };<br>
<br>
// This is the sort of sequence that fails<br>
{<br>
 =A0 =A0 =A0 dword d =3D p.x;<br>
 =A0 =A0 =A0 =A0f_ty f =3D p.f;<br>
 =A0 =A0 =A0 =A0if(d !=3D 0x55555555)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 f();<br>
=A0}<br>
<br>
This compiles to: -<br>
<br>
 =A0 =A0 movea.l =A0_p,a0<br>
 =A0 =A0 cmpa.l =A0#0x55555555<br>
 =A0 =A0 beq.s =A0 =A0skip<br>
 =A0 =A0 jsr =A0 =A0 =A0 (a0)<br>
skip<br>
<br>
So a0 should contain all 5&#39;s, which is not a valid address in my map, b=
ut the branch should prevent it being used as an address. What actually hap=
pends seems to depend on the code alignment, etc.<br>
<br>
It can simply run past the code OK.<br>
<br>
It can give an XLB interrupt with 55555554 in the address capture register.=
<br>
<br>
It can lock up the processor. When I hit break in my BDM debugger the PC is=
 a couple of instructions past this block.<br>
<br>
If I set a breakpoint anywhere in the program the code runs OK, regardless =
of whether the breakpoint is triggered.<br>
<br>
So it looks like the core sometimes does a pre-fetch on 55555555, even thou=
gh it will not be executed. My questions are: -<br>
<br>
Is this a known bug/feature in the V4 core?<br>
Why does it sometimes lock the processor rather than giving an XLB interrup=
t.<br>
Why does having a breakpoint active make it work?<br>
Is that a workaround or do I have to find all the places in my code that th=
is could happen an insert NOPs or something. A complete nightmare because I=
 have a whole state machien architecture that relies on being able to conta=
in addresses and some flags in the same 32 bit value!<br>


<br>
Chris<br>
<br>
<br>
</div></div><a href=3D"mailto:[email protected]" target=3D"_blank">cold=
[email protected]</a> Send a post to the list. <a href=3D"mailto:coldfire-j=
[email protected]" target=3D"_blank">[email protected]</a> Join the=
 list. <a href=3D"mailto:[email protected]" target=3D"_blank">co=
[email protected]</a> Join the list in digest mode. <a href=3D"mai=
lto:[email protected]" target=3D"_blank">coldfire-leave@wildrice.=
com</a> Leave the list.<br>


</blockquote>
<br>
------------------------------------------------------------<br>
Tim Stoutamore, Principal Engineer<br>
Blunk Microsystems, LLC<br>
6576 Leyland Park Drive<br>
San Jose, CA 95120-4558<br>
Tel: 408/323-1758<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">stout@blunkmicro.=
com</a><br>
<a href=3D"http://www.blunkmicro.com" target=3D"_blank">www.blunkmicro.com<=
/a><br>
------------------------------------------------------------<br>
---<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire@wildric=
e.com</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0Send a post to the list.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-jo=
[email protected]</a> =A0 =A0 =A0 =A0Join the list.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-=
[email protected]</a> =A0 =A0Join the list in digest mode.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-l=
[email protected]</a> =A0 =A0 Leave the list.<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>

[email protected]=09Send a post to the list.
[email protected]=09Join the list.
[email protected]=09Join the list in digest mode.
[email protected]=09Leave the list.
--000e0cd24492c56ddc046794c7d2--