Update SH-1 status

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1225 42af7a65-404d-4744-a932-0658087f49c3

1 files changed, 25 insertions, 0 deletions

diff --git a/nuttx/TODO b/nuttx/TODO
index 397b43319..f1ebc0ac0 100644
--- a/nuttx/TODO
+++ b/nuttx/TODO
@@ -22,6 +22,7 @@ NuttX TODO List (Last updated July 31, 2008)
   (6)  ARM/LPC214x (arch/arm/src/lpc214x/)
   (3)  ARM/STR71x (arch/arm/src/str71x/)
   (4)  pjrc-8052 / MCS51 (arch/pjrc-8051/)
+  (1)  SH-1 (arch/sh)
   (7)  z80/z8 (arch/z80/)
   (8)  z16 (arch/z16/)
 
@@ -467,6 +468,30 @@ o pjrc-8052 / MCS51 (arch/pjrc-8051/)
   Status:      Open
   Priority:    Low -- only because there as so many other issues with 8051
 
+
+o SH-1 (arch/sh)
+  ^^^^^^^^^^^^^^
+
+  Description:  There are instabilities that make the SH-1 port un-usable.  The
+                nature of these is not understood; the behavior is that certain SH-1
+                instructions stop working as advertised.  I have seen the following
+                examples:
+
+                  412b jmp @r1 - Set a return address in PR, i.e., it behaved like
+                       410b jsr @r1.  Normally 412b works correctly, but in the failure
+                       condition, it reliably set the PR.
+                  69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+.  This behavior
+                       does not correspond to any known SH-1 instruction
+
+                This could be a silicon problem, some pipeline issue that is not
+                handled properly by the gcc 3.4.5 toolchain (which has very limit
+                SH-1 support to begin with), or perhaps with the CMON debugger.  At
+                any rate, I have exhausted all of the energy that I am willing to put
+                into this cool old processor for the time being.
+  Status:       Open
+  Priority:     Low -- because the SH-1, SH7032, is very old and only of historical
+                interest.
+
 o z80/z8 (arch/z80)
  ^^^^^^^^^^^^^^^^^^