[RTEMS Project] #2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()
RTEMS trac
trac at rtems.org
Wed Jul 15 05:54:57 UTC 2015
#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
More information about the bugs
mailing list