* Performance on PPC8xx using string and multiple load instructions?
@ 2002-05-09 17:23 Conn Clark
0 siblings, 0 replies; only message in thread
From: Conn Clark @ 2002-05-09 17:23 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Does anyone know how using the -mstring and -mmultiple GCC
code optimization switches affect performance on the PPC8xx ? The
book I have on PPC assembly says the use of the string and
load-multiple instrutions may be signifigantly slower than the
multiple instruction equivalent on some processors. It does not tell
me which processors or why. I think it might be due to ther fact
that multiple instructions can be paired in multi instruction
pipelined chips. Since the 8xx has only a sigle pipeline I was
wondering if this was the case.
In the kernel source they use the -mmultiple and -mstring
switches in the architecture dependant code. This may be done to
reduce codeIf these are
instructions signifigantly slower on some processors is this a good
idea to have them as default optimizations for all processors?
If anybody ever benchmarked code with these instructions
on an 8xx processor or other processor I would like to see the
results.
Thanks in advance
Conn
--
*****************************************************************
If you live at home long enough, your parents will move out.
*****************************************************************
Conn Clark
Engineering Stooge clark@esteem.com
Electronic Systems Technology Inc. www.esteem.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2002-05-09 17:23 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-09 17:23 Performance on PPC8xx using string and multiple load instructions? Conn Clark
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).