On 03/13/2013 04:50 PM, Mark Pizzolato - Info Comm wrote:
On Wednesday, March 13, 2013 at 1:48 PM, Dave McGuire wrote:
On 03/13/2013 04:46 PM, Mark Pizzolato - Info Comm wrote:
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.
In case it isn't obvious, using this makefile with a different compiler (called
suncc for instance) is done by:
$ make GCC=suncc vax
Let me know how things work out....
You'll also have to change any GCC-specific options ("-f<xxx") in the
Makefile.
I don't think gcc specific options are used if the compiler isn't gcc. That is why I'd like to know 'how things work out'....
I seem to recall that they were, the last time I did it, but it has
been awhile since I did that build.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 13 Mar 2013, at 16:49, "Dave McGuire" <mcguire at neurotica.com> wrote:
On 03/13/2013 04:45 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.
Unfortunately I missed backing that up in the OS version testing it slipped my mind. :(
You mean I went through all that trouble installing and configuring
Solaris for you on that machine and you reloaded it? Fucker.
In my defense I needed to learn how to install Solaris from scratch. ;)
I'll put the compiler up for download shortly. I'm flying out for
work tomorrow at oh-God-thirty AM so it will have to be in a couple of
days. Ping me.
Okay. Will do. Thanks.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Wednesday, March 13, 2013 at 1:48 PM, Dave McGuire wrote:
On 03/13/2013 04:46 PM, Mark Pizzolato - Info Comm wrote:
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.
In case it isn't obvious, using this makefile with a different compiler (called
suncc for instance) is done by:
$ make GCC=suncc vax
Let me know how things work out....
You'll also have to change any GCC-specific options ("-f<xxx") in the
Makefile.
I don't think gcc specific options are used if the compiler isn't gcc. That is why I'd like to know 'how things work out'....
- Mark
On 03/13/2013 04:45 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.
Unfortunately I missed backing that up in the OS version testing it slipped my mind. :(
You mean I went through all that trouble installing and configuring
Solaris for you on that machine and you reloaded it? Fucker.
I'll put the compiler up for download shortly. I'm flying out for
work tomorrow at oh-God-thirty AM so it will have to be in a couple of
days. Ping me.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 03/13/2013 04:46 PM, Mark Pizzolato - Info Comm wrote:
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.
In case it isn't obvious, using this makefile with a different compiler (called suncc for instance) is done by:
$ make GCC=suncc vax
Let me know how things work out....
You'll also have to change any GCC-specific options ("-f<xxx") in the
Makefile.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
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.
In case it isn't obvious, using this makefile with a different compiler (called suncc for instance) is done by:
$ make GCC=suncc vax
Let me know how things work out....
- Mark
On 13 Mar 2013, at 16:41, "Dave McGuire" <mcguire at neurotica.com> 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.
Unfortunately I missed backing that up in the OS version testing it slipped my mind. :(
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
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.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 03/13/2013 04:18 PM, Gregg Levine wrote:
That's what I thought. Incidentally Cory you can remove the gremlin
from your mailserver now. That was his idea all alone, I had nothing
to do with it.
If both you Cory, and you Brian get this to work, I shall be amazed.
If there are still problems, it is still Dave's fault.
It *always* seems to be my fault these days!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 13 Mar 2013, at 16:18, "Gregg Levine" <gregg.drwho8 at gmail.com> wrote:
On Wed, Mar 13, 2013 at 3:10 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 13 Mar 2013, at 15:04, "Mark Pizzolato - Info Comm" <Mark at infocomm.com>
wrote:
On Wednesday, March 13, 2013 at 11:51 AM, Cory Smelosky wrote:
Speaking of SIMH on Solaris and similar...is SIMH capable of SET CPU IDLE in
zones on SPARC? It looks like 3.9-0 can't.
Well, I think I answered this yesterday on this list. I'll restate what I
wrote here:
Thank you. I think the answer got lost when my mail server was bouncing all
emails. ;)
Idling for any simulator requires that the host system's clock tick be <=
the size of the simulated system's clock tick. VAX systems have a clock
tick of 10ms. Idling for simulated VAX systems works best if the host clock
tick is 1ms.
Windows systems have a user mode programmatically settable clock tick size
(a facility useful for some media playback capabilities). On Windows
systems simh will set the host's clock tick to 1ms while a simulator is
running.
We haven't seen programmatically settable host clock tick sizes on other
platforms. In general, other platforms have a tick size which can be
changed in some system specific way (which might require building a kernel
with a desired tick size) or not changeable at all. This issue comes up
often enough that adding how to make these system specific adjustments would
be a useful addition to the simh FAQ. Any feedback on this subject will be
welcome.
Ahhh.
"Solaris timing uses a real-time clock that can generate interrupts at a
resolution bound by the processor speed. For scheduling purposes, it fires
every 10 milliseconds. As in Linux, this is a clock "tick." Note that 2.6
Linux uses a 1000-tick/second clock, as opposed to the 100-tick/second clock
used by Solaris and by previous versions of Linux. User-level programs on
Solaris can program the real time clock to fire at nanosecond granularity,
rounded up by processor time--much finer than the clock tick granularity of
ten or one milliseconds. However, the program interface to use the
high-resolution timers is not visible in the DDI/DKI. See clock_settime(3rt)
for user-level details andusr/src/uts/common/os/cyclic.c for details on
high-resolution timing in Solaris.
Also note that in Solaris, you can change the value of hz or clock
ticks/second by setting hires_tick to 1 and hires_hz to the desired time in
the /etc/system file. The default is 1000 ticks per second. Here's an
example:
set hires_tick=1
set hires_hz=10000 <~--- 10000 ticks per second"
Looks like Solaris can set it in user mode, too.
Recent simh code will display what it has determined to be the host's clock
size if simh believes the host's clock tick is too small to support idling
when you attempt to enable idling.
Recent simh code can always display host system's tick size with the
'EXAMINE TIMER OS_SLEEP_MIN_MS' command.
The latest simh code is available from
https://github.com/simh/simh/archive/master.zip.
Gregg Levine wrote:
Idle on some items that are not Linux or FreeBSD or NetBSD may not
work because of how they interpret the timer. Same goes for trying to
get the idle function to work on Windows.
I haven't heard from anyone who's had issues getting idling to work on
Windows. If you know of such a case, I would be interested to explore what
may be happening in this case.
Thanks.
- Mark Pizzolato
Hello!
That's what I thought. Incidentally Cory you can remove the gremlin
from your mailserver now. That was his idea all alone, I had nothing
to do with it.
Cool. ;) I'd love a gremlin free mail server. :)
If both you Cory, and you Brian get this to work, I shall be amazed.
If there are still problems, it is still Dave's fault.
Well, i'm persistent so I will most likely get it to work. ;)
Also! The SCSI controllers should get mailed out to you in the next few days. I apologise for the delay kept getting sidetracked. I threw in a third as a result of the wait. ;)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
