Re: V4 core speculative execution?

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

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] the list.
>> [email protected] Join 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.
>
>

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

Hi Tim,<br><br><div class=3D"gmail_quote"><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 class=3D"im"><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>Yes I al=
so 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 N=
ULL, in which case you could get away with speculatively derefencing them a=
s long as address 0 was readable. It is only where I have unions where a po=
inter 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><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 class=3D"im"><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><br>It locks up even with BDM not =
connected. When BDM is connected the debugger has to assert reset to get th=
e CPU to enter background mode. <br><br>Oddly if I set A0 to an invalid add=
ress that doesn&#39;t make the branch condition, e.g. 55555554, then it act=
ually tries to jump to that address and always gets an XLB bus error as exp=
ected. 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 t=
hing but if code moves about a bit it can either work, lock up, or bus erro=
r.<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><blockquote class=3D"gmail_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 class=3D"h5">
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><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.
--000e0cd24492e184c00467943024--