On 2014-03-31 12:26, Sebastian Huber wrote:
On 2014-03-31 12:17, Daniel Cederman wrote:
Branch always is a special case in which the ",a" causes the delay
instruction
to not be executed. From the Sparc architecture manual:

"However, a bit in the delayed control-transfer instruction can cause
the delay
instruction to be annulled (that is, to have no effect) if the branch
is not
taken (or in the branch always case, if the branch is
taken)."

Ok, I didn't have this "(or in the branch always case, if the branch is
taken)" in my documentation.


So I think it should be safe to remove the nop instruction.

Since nobody knows which instruction will be after "ba,a" I think we
should keep the nop.


According to our hardware guys that should not be a problem. But we can keep the nop for peace of mind.


On 2014-03-31 12:03, Sebastian Huber wrote:
On 2014-03-31 11:48, Daniel Cederman wrote:
See errata of respective chip. Some code-cleanup as well.
---
  c/src/lib/libbsp/sparc/leon3/startup/bspidle.S |    7 ++-----
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/c/src/lib/libbsp/sparc/leon3/startup/bspidle.S
b/c/src/lib/libbsp/sparc/leon3/startup/bspidle.S
index 714d4e5..0924658 100644
--- a/c/src/lib/libbsp/sparc/leon3/startup/bspidle.S
+++ b/c/src/lib/libbsp/sparc/leon3/startup/bspidle.S
@@ -23,8 +23,5 @@
  SYM(bsp_idle_thread):
  SYM(leon3_power_down_loop):
  pwdloop:  mov   %g0, %asr19
-          ba    pwdloop
-          nop
-          retl
-          nop
-
+          lda   [%sp] 1, %g0            ! Needed for UT699 and GR712
+          ba,a    pwdloop


If I understand this ",a" notation correctly, then the instruction
following the branch is not executed in case the branch is not taken.
Since we branch always, this ",a" seems to be superfluous.  Is it safe
to remove the nop instruction in the delay slot here?

_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel


_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to