[RTEMS Project] #2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()

[RTEMS trac]

#2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()
--------------------------+---------------------
 Reporter:  nick.withers  |       Owner:
     Type:  defect        |      Status:  new
 Priority:  normal        |   Milestone:  4.11.1
Component:  General       |     Version:  4.11
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+---------------------

Comment (by nick.withers):

 https://sourceware.org/ml/libc-alpha/2008-04/msg00036.html and
 https://llvm.org/bugs/show_bug.cgi?id=23680 have some interesting
 discussion about {{{mftb}}} et al., including a quote from the PPC ISA
 2.07 doco which says mfspr 268/269 should be preferred and that "It is
 believed that the mfspr instruction can be used to read the Time Base on
 most processors that comply with versions of the architecture that precede
 Version 2.01. Processors for which mfspr cannot be used to read the Time
 Base include the following.
   - 601
   - POWER3".

 This and e.g., the MPC860 definitely having 'em would seem to contradict
 part of the comment against {{{CPU_Get_timebase_low}}}. Also, I don't
 understand the "we run in supervisory mode so that should work on all
 CPUs" bit... From my reading it seems clear SPR 268 / 269 should be
 readable in user mode too.

 Also, psim (GDB 7.9) now seems to handle {{{mftb}}} and {{{mfspr}}} fine
 (GDB disass  shows {{{mftb}}} in the disassembly for both, but they're the
 requested instructions - opcodes {31, 371} and {31, 339} - underneath), so
 the "PSIM currently lacks support for reading SPRs 268/269" comment seems
 past its use-by date. ![1]

 Regarding the "Alternate Time Base" currently used if {{{defined(ppc8540)
 || defined(__PPC_CPU_E6500__)}}},
 http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf
 says: "The EIS defines an alternate time base APU, which is implemented on
 the e500v2. It is intended for measuring time in implementation-defined
 intervals. It differs from the PowerPC-defined time base in that it is not
 writable, it counts at a different, typically higher, frequency". I'd like
 to unify {{{_CPU_Counter_read()}}}, {{{CPU_Get_timebase_low}}} and
 {{{PPC_Get_timebase_register()}}} so we're consistent with how we grab the
 time base... Should I get rid of alternate time base accesses in
 {{{_CPU_Counter_read()}}}? I believe that's the only place they're used
 (through grepping for "526").

 On to the CFLAGS...

 1 Seems to work. GDB no longer reports it as an "powerpc:e500" but
 "powerpc:common", but I guess the former just means that the binary's SPE-
 with-shared-registers-enabled or something and the latter doesn't indicate
 the compilation wasn't correctly targeted. {{{ppc8540}}} *is* defined,
 where it wasn't before.

 I tried 2 with {{{CPU_CFLAGS = -mcpu=8540 -meabi -msdata=sysv -mspe
 -mabi=spe -mfloat-gprs=single -fno-common}}} (that right?) but the board
 resets at some point soon after bsp_start(). GDB won't talk to it (as per
 above). I also tried twiddling {{{PPC_HAS_FPU}}} on and
 {{{PPC_HAS_DOUBLE}}} off without success.

 I suppose 2 would be significantly better for users with single-precision
 floating point applications?

 ![1] The sim/2376 ticket mentioned is now
 https://sourceware.org/bugzilla/show_bug.cgi?id=9481 . I'll shoot 'em off
 an email momentarily to let 'em know it's no longer an issue

--
Ticket URL: <http://devel.rtems.org/ticket/2369#comment:10>
RTEMS Project <http://www.rtems.org/>
RTEMS Project