Bob: I was unaware that at the @ prompt I had to type in 'boot'<enter>.
Doing this has solved the problem I originally described.
On 18/04/2012 02:00, [email protected] wrote:
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Apr 2012 12:48:53 -0400
From: Bob Supnik<[email protected]>
To: [email protected]
Subject: Re: [Simh] Unable to boot
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Please capture the actual session from your terminal, including all SimH
commands from the moment you started the simulator, and include the
transcript with your reply to the mailing list. If you are using a
command file, include that too.
On 4/16/2012 12:00 PM, [email protected] wrote:
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Apr 2012 12:54:57 +1000
From: Paul Richards<[email protected]>
To: [email protected]
Subject: [Simh] Unable to boot
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Whenever I try to boot the PDP-11 SimH bombs out with a mesage: "HALT
instruction, PC:000002 (HALT)".
I am following exactly the instructions in the 'Sample Software
Packages' PDF document and have tried, for example, to install/boot UNIX
V7 using both of th examples given in the PDF.
Any assistance appreciated.
------------------------------
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
End of Simh Digest, Vol 101, Issue 18
*************************************
------------------------------
Message: 2
Date: Mon, 16 Apr 2012 22:18:20 -0500
From: "Craig A. Berry"<[email protected]>
To: [email protected]
Subject: [Simh] XCode and LTO
Message-ID:<[email protected]>
Content-Type: text/plain; CHARSET=US-ASCII
I've been running the vax simulator from 3.8-1 off and on for a couple of years and
thought I would take a current snapshot for a spin to see if the performance differs, so
I grabbed a GitHub snapshot with the precise but unpronounceable name
"markpizz-simh-v3.8-2-rc2-190-geb60957.zip". Building it on Mac OS X Lion
proved to be more fun than I intended to have.
I have the latest version of XCode (4.3.2) on my Macbook Pro, so that includes
GCC, right? Wrong. Not anymore. What it includes is a gcc-alike front end to
llvm, which identifies itself as:
% llvm-gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
Problem is, llvm-gcc, while claiming to be gcc, does not support the options
-flto -fwhole-program. It accepts (actually ignores) those options on the
command line but then you get dozens of undefined symbols at link time.
The makefile script currently in SIMH assumes all compilers identifying themselves as gcc
support the LTO options unless they are in the version list explicitly excluded with
LTO_EXCLUDE_VERSIONS. I tried adding LLVM to that list, but the makefile code stops
listening after it gets to the numeric part of the version string and doesn't see the
"LLVM" in the last line of the compiler output above.
So at the very least, the ability to hard-code a list of compilers that don't
support the LTO options needs a bit of work. But I'm not sure that's the whole
story, because true blue GCC doesn't necessarily support that option either.
How do I know?
A reasonable person would have simply hacked the makefile script to hard-wire
NO_LTO to 1, and that's what I did eventually. That works, for some definition
of works, but there are performance implications that I'll get to shortly. Not
being entirely reasonable, I decided that if it wanted gcc, I'd give it gcc.
So I downloaded the massive GCC 4.7.0 source distribution and built it from
source with default options. The llvm-gcc did just fine bootstrapping a build
of the GCC package, and a few hours later I had a working gcc.
So then I had another whack at compiling SIMH, and it told me that the -flto option was
not supported. Ouch. The one option I was in need of was not a default option. So
desperation led me (at long last) to read a few passages from the family-friendly manual,
whereupon I discovered that configuring with "./configure --enable-lto" and
rebuilding GCC got me (after another hour or three of compiling) a compiler that reports
itself as:
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.3.0
Configured with: ./configure --enable-lto
Thread model: posix
gcc version 4.7.0 (GCC)
This turned out to be what SIMH was expecting and it built without a hitch. But it
occurred to me that what SIMH was expecting was not what I was expecting, was not what a
default build of GCC from the authoritative sources provides, and was not what the Apple
gizmo provided as part of XCode that impersonates gcc provides. So perhaps a better
method of detecting LTO capability is needed, perhaps scanning the version output above
for "--enable-lto".
But to sprinkle some good news over my complaint, I was finally able to fire up
my image of OpenVMS VAX v7.3 and compare performance between 3.8-1 (built with
a real gcc from a previous version of XCode, probably gcc 4.0), llvm-gcc 4.2.1,
and actual gcc from GCC 4.7.0. I used a DCL procedure I found on the interwebs
ages ago called CALCULATE_VUPS.COM. Before the benchmark police show up, I
should say it was just for fun, it was a Sunday afternoon, and no actual
benchmarks were harmed by doing a bit of casual looping in DCL. Here's what I
got, averaging five runs:
VUPS SIMH version, Compiler
_____ ___________________________
14.0 v3.8-1, gcc (4.0?)
18.5 v3.8-2-rc2-190, llvm-gcc 4.2.1
22.5 v3.8-2-rc2-190, gcc v4.7.0
So v3.8.2 is shaping up to be 61% faster than v3.8.1 at hopping around in DCL.
Perhaps more surprising is that SIMH built with gcc v4.7.0 is 22% faster than
the exact same SIMH built with llvm-gcc v4.2.1. Someone is doing something
right and in this case it doesn't appear to be Apple or llvm.
Cheers,
________________________________________
Craig A. Berry
mailto:[email protected]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
------------------------------
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
End of Simh Digest, Vol 101, Issue 19
*************************************
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
