Subject: simh help?

From: Brian Hechinger <[email-masked]>
Date: Wed May 28 01:24:25 2003

where do i get simh help?  i'm trying to install VMS on a simh instance, and
it doesn't seem to want to play nice.  where do i get help for simh?  the
documentation is slim, and there seems to be no mailing list.

help?

-brian
-- 
"I'd say don't quit your day job, but you're pretty lousy at that too."  -Bender

---

From: Hans Pufal <[email-masked]>
Date: Wed May 28 01:24:44 2003

> documentation is slim, and there seems to be no mailing list.

Sorry, can't help with the VMS quetions but this link should take you to 
a SIMH mailing list - see you there.

http://mailman.trailing-edge.com/mailman/listinfo/simh

   -- hbp

---

From: "Damien Cymbal" <[email-masked]>
Date: Wed May 28 01:25:44 2003

I've had pretty good success in the comp.os.vms newsgroup with simh
questions in the past.  There seems to be a pretty active VMS-on-simh
community frequenting there.

----- Original Message ----- 
From: "Brian Hechinger" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 27, 2003 2:11 PM
Subject: simh help?

> "I'd say don't quit your day job, but you're pretty lousy at that
oo."  -Bender

---

From: Kevin Handy <[email-masked]>
Date: Wed May 28 01:27:29 2003

>documentation is slim, and there seems to be no mailing list.
Depends on what problem you are having, what version of simh you are using,
and what OS you are running it on.  I can run VMS in simh under Linux 
without
any problems.  Haven't used it under Windows though.

---

From: Kevin Handy <[email-masked]>
Date: Wed May 28 16:29:50 2003

Brian Hechinger wrote:

>On Wed, May 28, 2003 at 02:49:27PM -0600, Kevin Handy wrote:
>  
>
>>Does simh crash, or does it just do wacky things? More details would
>>be useful.
>>    
>>
>
>it stops responding.  if i don't clear out my nvram file, it fails on memory
>check the next time i boot the cpu.
>
Odd. If you can still Control/E to the prompt, try 'N' for several 
instructions
to see if it is stuck in VMS's idle loop (cycles through a very small number
of instructions).  If it is, it might not be seeing any interrupts.

If Control/E doesn't work, then things are really hosed.

>
>i need to delete the nvram file and restart, then it works.  for a while
>anyway, and then eventually stops responding.
>  
>
I haven't been using a NVR file, and it seems to work ok.
Try commenting it out in your configuration file, and see what happens.

>>It's probably mostly done with some version of GCC, but I believe that
>>it is often compiled using Microsoft Visual C.
>>    
>>
>
>it's been added to my LONG list of things to clean up for building with
>non-gcc.  MIPSpro being very anal complains a LOT about the source code.
>
Sometimes that's a good thing.  It may actually be pointing right at
the problem, but hiding it under a mass of additional messages.

>i'd love to, but i'm not even sure how to.  ;(
>
I've done it using the 'N' command (next instruction),  trying to trace out
bad instructions, and using gdb. It's very tedius when you are looking for
one instruction out of a million executed that are wrong.

---

From: Brian Hechinger <[email-masked]>
Date: Wed May 28 16:30:11 2003

> any problems.  Haven't used it under Windows though.

i run it on NetBSD without any trouble.

v2.1.0-4 on IRIX 6.5.16f.

build with MIPSpro 7.4

with -apo it was fast as balls, but was EXTREMELY unstable.

without -apo it's much clower (no surprise there) and it is not completely
stable, but only mostly stable.

i am curious if anyone else has tried to build it with non-gcc on something.

-brian

---

From: Kevin Handy <[email-masked]>
Date: Wed May 28 16:30:32 2003

If you can discover where the problem is, then I'm sure Bob would like
to know about it and would probably be happy to receive any fixes.

The hard part is determining what is going wrong, and without access to
the specific compilers, that is rather hard.

---

From: Brian Hechinger <[email-masked]>
Date: Wed May 28 16:30:53 2003

> the specific compilers, that is rather hard.

one i get the Challenge running i would be more than happy to give out
accounts to help the non-gcc cause.

-brian

---

From: Brian Hechinger <[email-masked]>
Date: Thu May 29 08:52:48 2003

> of instructions).  If it is, it might not be seeing any interrupts.

oops, forgot to mention that part.  if i Ctrl/E from within the running
simulator, it crashes sim and takes the controlling xterm/rxvt with it.

i should try doing this telnetting in from a remote machine i think.

> If Control/E doesn't work, then things are really hosed.

it works, just not well. ;)

> Sometimes that's a good thing.  It may actually be pointing right at

IMHO that's *always* a good thing.  it has really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things.  the most common assumption is that a
void pointer and an int pointer is the same size.  which just happens to be
true in 32-bit land, but totally hoses those of us who live in 64-bit land.

hell, even the code that autoconf generates for tests makes that assumption.

> the problem, but hiding it under a mass of additional messages.

how do i build just the VAX portion?  'make vax' does nothing, and 'make VAX'
says everything is up to date.  that's one ugly makefile, so it's kinda hard
to interpret for someone who hasn't messed with makefiles in years.

> one instruction out of a million executed that are wrong.

first i need to get it to not crash completely. ;)

-brian

---

From: Ethan Dicks <[email-masked]>
Date: Thu May 29 08:53:11 2003

--- Brian Hechinger <[email-masked]> wrote:
> it has really opened my eyes to the fact that your average opensource
> coder has been so coddled by the whole gcc/x86 platform that they have
> really started to make stupid mistakes and even stupider assumptions
> about things.

They used to say the same thing about BSD/VAX coders...

> the most common assumption is that a void pointer and an int pointer is
> the same size.  which just happens to be true in 32-bit land...

The charge in 1983 was "char * and an int are the same size..."

> ... but totally hoses those of us who live in 64-bit land.

The hosed parties 20 years ago tended to be 16-bit users/admins.

> hell, even the code that autoconf generates for tests makes that

I realize that Linux on x86 is a hugely popular platform for Open Source
work, but there's plenty of UltraSPARC machines out there... surely
you don't need an Alpha to shatter these assumptions
 
-ethan
(whose Alpha is running VMS, not UNIX; because it can)

---

From: Patrick Finnegan <[email-masked]>
Date: Thu May 29 08:53:32 2003

> simulator, it crashes sim and takes the controlling xterm/rxvt with it.

If the xterm/rxvt seems 'hosed' but is still running, try running "reset",
which should reset the terminal to 'sane' characteristics.  I'm guessing
the problem is that the keyboard gets set to 'noecho' or 'raw' mode or
something.

> i should try doing this telnetting in from a remote machine i think.

Or, if possible, try it from a virtual/serial console - without a
windowing system in the way.

> void pointer and an int pointer is the same size.  which just happens to be

Do you mean void * and int (not a pointer)?  All pointers should be the
same size... (Sorry, I'm being pedantic.)

> to interpret for someone who hasn't messed with makefiles in years.

First, you need a "BIN" subdir, and then "make BIN/vax".  I think I
remember reading this in a readme somewhere...  I usually end up just
being lazy and running a "make all".  Anyways, who knows when I'll want to
play with an IBM 1401 sim :).

Pat
--
Purdue University ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www.itap.purdue.edu/rcs/

---

From: Brian Hechinger <[email-masked]>
Date: Sat May 31 18:01:01 2003

> the problem is that the keyboard gets set to 'noecho' or 'raw' mode or

no, the xterm/rxvt crashes along with simh.  i need to start a new xterm.

> windowing system in the way.

that's not a bad idea, maybe i'll drag a vt into work next week and do that.

> same size... (Sorry, I'm being pedantic.)

no, you are right to be pedantic.  i was wrong, you corrected me.  i would have
done the same to you. ;)

> play with an IBM 1401 sim :).

brian@marvin$ gmake BIN/vax
gmake: *** No rule to make target `BIN/vax'.  Stop.

i wouldn't mind making everything all the time, but it takes a while, and i'm
impatient. ;)

-brian

---

From: Brian Hechinger <[email-masked]>
Date: Sat May 31 18:01:29 2003

> They used to say the same thing about BSD/VAX coders...

all those unix people are evil!!!   *ducking!*

> The charge in 1983 was "char * and an int are the same size..."

equally as evil. ;)

> The hosed parties 20 years ago tended to be 16-bit users/admins.

i wasn't lucky enough to get to deal with 16-bit machines on a regular basis.

i do now, but not then. ;)

> you don't need an Alpha to shatter these assumptions

i wonder how many people build things 64-bit though?  it's very easy to build
and run 32-bit software on sparc64 and MIPS64.  i do, but i'm one of those
weirdos. ;)

> (whose Alpha is running VMS, not UNIX; because it can)

all my alphas run VMS.  my octane only runs IRIX because no-one has ported
VMS to it yet. ;)

-brian

---

From: Kevin Handy <[email-masked]>
Date: Sat May 31 18:03:43 2003

>simulator, it crashes sim and takes the controlling xterm/rxvt with it.
I don't know why it would take the xterm with it. Odd that.

[Sounds of grasping at straws]

Memory corruption might be occurring somewhere.
Wonder if one of the memory monitors, like ElectricFence, would
yield useful information. Don't know whats available on your system.

>hell, even the code that autoconf generates for tests makes that assumption.
That assumption started in the first versions of Unix on the PDP11, and
still occurrs in new code. It's part of what was once called the
"all the worlds a VAX" mentality.

Make sure you have all warnings turned on when you compile (look for
the CC definition), under gcc the option would be '-Wall'. Maybe it will
point at something obvious.

>to interpret for someone who hasn't messed with makefiles in years.
'make BIN/vax' should work (case is important here). All the binaries
are created in the BIN subdirectory.

The makefile should actually be fairly simple (as I wrote the original
version). Skip past the top of the makefile (which figures out your OS
and if network deviced should be configured) and the major part of
it is just lists of files for each emulator.

Something like it became necessary when the emulators started
sharing code for devices, and manually typing the compile
line was getting too complicated.

>first i need to get it to not crash completely. ;)
That's always a good start. ;=)

---

From: Ethan Dicks <[email-masked]>
Date: Sat May 31 18:04:05 2003

> > The charge in 1983 was "char * and an int are the same size..."

Some historical commentary on the "all the world's a VAX" syndrome:

  http://mail-index.netbsd.org/amiga-dev/1994/07/13/0007.html
  http://www.cs.bgu.ac.il/~omri/Humor/ten-commandments.html (cf #10)
  http://www.cnam.fr/Jargon/jargon.html?1910 (exhaustive!)

I remember pulling down lots of programs from comp.sources.unix
and comp.sources.games, both for building in their native environment
and for porting to VMS/AmigaDOS/whatever-was-in-front-of-me-at-the-
moment.  There were some things that I never did get working (but I
did get Pinfocom, Larn and Ultra-Larn working on non-UNIXy boxen).

-ethan

---

From: [email-masked] (Sean 'Captain Napalm' Conner)
Date: Sat May 31 18:11:48 2003

> true in 32-bit land, but totally hoses those of us who live in 64-bit land.

  A void * and an int, or an int *?  Generally speaking, one can cast any
type of pointer into a void *, and cast a void * back to any other type of
pointer (without casts!  At least in ANSI C; I think in C++ you need a
cast).  But if you mean casting a pointer (of any kind) into an int (or
unsigned long, or whatever) then yes, I can see where that would definitely
lead to problems.

  -spc (The only time my code failed on a 64-bit system, there was a bug
	in the Standard C library of that system that I triggered ... )

---

From: [email-masked] (Sean 'Captain Napalm' Conner)
Date: Sat May 31 18:12:33 2003

> same size... (Sorry, I'm being pedantic.)

  No, they don't have to be the same size; I think I recall that char * on
certain PDPs were slightly larger than say, an int * (because pointers only
pointed to word boundaries, yet you could pack several characters per word
so extra storage was needed to store the offset into a word for a char *). 
And don't forget the whole mess with near and far pointers in the DOS world
(technically those were extentions but ... ).

  Given the following declaration:

	void *vp1;
	void *vp2;
	char *cp1;
	char *cp2;
	int  *ip;

  The following should hold true:

	vp1 = cp1;
	cp2 = vp1;
	assert(cp1 == cp2);	/* should be fine */

  While the following may or may not work:

	vp1 = cp1;
	ip  = vp1;
	vp2 = ip;
	cp2 = vp2;
	assert(cp1 == cp2)	/* may or may not hold */

  -spc (Don't have the C Standard handy ... )

---

From: [email-masked] (Sean 'Captain Napalm' Conner)
Date: Sat May 31 18:13:17 2003

> point at something obvious.

  Also try:

	gcc -Wall -ansi -pedantic

  Be prepared for *lots* of warnings.  

  -spc (I mean, lots)

---

From: Kevin Handy <[email-masked]>
Date: Sat May 31 18:19:23 2003

>  A void * and an int, or an int *?  Generally speaking, one can cast any
Usually a <mumble>* to an int, because on many systems an int and a
pointer are the same size (all the world's a vax).  :-P A lot of older code
swaps pointers into/outof int's.

---

From: Kevin Handy <[email-masked]>
Date: Sat May 31 18:26:16 2003

>  Be prepared for *lots* of warnings.  
For large values of lots, or small values of infinity!

Actually, most of the '-Wall' messages in simh were fixed some time
ago, but many more may have crept back in.

---

From: Brian Hechinger <[email-masked]>
Date: Sat May 31 18:26:39 2003

> ago, but many more may have crept back in.

i don't have gcc installed on the octane, so i can't try gcc wall, but MIPSpro
complains a LOT about the source code.  i can send you a copy of the output if
you are interested.

-brian

---

From: Alexander Schreiber <[email-masked]>
Date: Mon Jun 2 07:57:36 2003

>   Be prepared for *lots* of warnings.  

That isn't all - you can turn it up some more. One of my small C
projects has a list of gcc-options explicitly built for maximum anal
retentive mode of the gcc:

-ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Waggregate-return -Wmissing-declarations -Wnested-externs -Winline 
-Werror -W

This make gcc complain about practically everything looking even
remotely funny - only way to get more complaints would probably be to
use a real lint.

It can be annoying as hell, but I really find it helpful during 
development.

Regards,
       Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

---

From: Tarsi <[email-masked]>
Date: Mon Jun 2 07:57:42 2003

Anyone have information on the IBM 5324?  I just picked up one and can find 
nothing, nada, zip, zero, zilch on it.  It's got the terminal, keybrd, and 
box.  I have yet to open it up, but will soon.

Thanks for any links or info you can provide.

Tarsi

---

From: Brian Hechinger <[email-masked]>
Date: Fri Jun 6 14:28:05 2003

>   Be prepared for *lots* of warnings.  

i use MIPSpro and DEC C all the time.  i'm *used* to lots of warnings. :)

-brian
-- 
"You know, evil comes in many forms, be it a man-eating cow or Joseph Stalin.
But you can't let the package hide the pudding. Evil is just plain bad! You
don't cotton to it! You gotta smack it on the nose with the rolled up newspaper
of goodness! Bad dog! Bad dog!"		-- The Tick