Oops. That should have read ". . . the biggest improvements may come
in matching the code generation to the processor versus using code
generation that uses the lowest common denominator strategy."
Leaving out the word "versus" resulted in a totally senseless
statement! Sorry for any confusion.
On 03/08/2012 09:35 AM, Michael Bloom wrote:
** With the ARM, gcc compilation options could have a significant
impact on CPU performance and "performance hits". Compiling with -O2
might help some at the cost of losing debuggability, but there are so
many different ARM processors that the biggest improvements may come
in matching the code generation to the processor using code generation
that uses the lowest common denominator strategy. The -mcpu= and
-mtune= options can help with this. Check the gcc man page for the
list of ARM processor types that can be specified.
Also, -mfloat-abi=softfp can help in some circumstances when you've
previously been using -mfloat-abi=soft despite having an FPU (it
generates FP instructions but retains the library call api used when
linking with libraries that contain floating point simulations , in
order to retain binary compatibility).
*
On*/Thu Mar 8 05:58:36 EST 2012 /*Quentin North (noisy)*<quentin at
quentin.org.uk>
<mailto:simh%40trailing-edge.com?Subject=Re%3A%20%5BSimh%5D%20EXT%20%3ARe%3A%20%20rasberry%20pi&In-Reply-To=%3CFE5D568B-52F0-48BC-B251-B0486C32719A%40quentin.org.uk%3E>/wrote://
/
I run simh on a sheevaplug with two concurrent HP2100 systems simulated with
network based interconnect kits between the two. With only a single Arm core
the performance takes a hit on CPU before memory becomes an issue.
Sent from my iPad
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
