On Wednesday, March 13, 2013 at 1:42 PM, Dave McGuire wrote:
On 03/13/2013 04:21 PM, Cory Smelosky wrote:
mkdir -p BIN
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions
-fgcse-after-reload -fpredictive-commoning -fipa-cp-clone
-fno-unsafe-loop-optimizations -fno-strict-overflow -flto
-fwhole-program -Wno-unused-result -I . -D_GNU_SOURCE
-DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so
sim_BuildROMs.c
-o BIN/BuildROMs
ld: fatal: auxiliary filter option (-f, --auxiliary) is only available
when building a shared object
First of all, Cory...have you tried using Sun's compiler? It kicks the snot out
of GCC for SPARC code generation. I did give you a copy.
I would suggest that this would be a good idea.
I have an old SparcStation which I fire up once every few years to test simh on a Big
Endian platform. It has a Linux disk and a Solaris disk (I don't recall the
version). I do not have a sun C compiler. The last time I fired it up (more than a
year ago) the basic testing worked out fine but I noticed that some things were so slow it
was practically unusable. I isolated some slow behavior down to an operation which
walked across a 64MB chunk of VAX memory one byte at a time. The 64MB array is stored in
a single malloc'ed area. This walk across the 64MB took some 20 seconds, while the
same operation on my Windows desktop takes far less than any time I could measure on my
watch. My theory was that it was spending all of its time in the alignment trap handler,
but I didn't have enough knowledge to dig into the details.
The test case is demonstrated by the following commands:
$ BIN/vax
MicroVAX 3900 simulator V4.0-0 Beta
sim> set cpu 64m
sim> save somefile
The save operation writes the current simulator state to a file.
- Mark