[Simh] Simh Digest, Vol 45, Issue 15

Peter Lund firefly at vax64.dk
Thu Aug 30 22:20:54 EDT 2007


Hi Bob.  Let me start by saying that I very much appreciate your
simulator (and your release of the VLSI VAX microcode, from which I
learned a lot).

On Thu, 2007-08-30 at 21:49 -0400, Bob Supnik wrote:

> 2. Distributed source management
> 
> Well, no.  SimH is not a democracy.

This is mostly like a misunderstanding or miscommunication!

Of course SimH isn't.  Nobody suggested it was.  The Linux kernel is
certainly not a democracy either...

>   The sources are not open for 
> changes from a community.  Instead, each major subsection has a lead 
> designer/implementer/editor, and his/her decisions are final.

...but they do have "lieutenants" or subsystem maintainers, just like
SIMH.  They work better together -- and people with ideas can work on
them while tracking the mainline kernel and without disturbing the
lieutenants until their ideas are ready.  Or until it is clear that it
wasn't such a great idea after all.

Distributed source code control is fantastic for that.

>   For 
> the control package, and many of the simulators, that's me.  The HP, 
> Interdata, and DG simulators have their own leads, as does Ethernet 
> and some other subsections.

Ok, here's one for you, then:

I changed the makefile + added a helper script so the ka655x.bin file
(the VAX firmware) gets translated into a C array (which gets loaded
into the rom array in rom_reset() in vax_sysdev.c).

That way there are no paths to worry about and the VAX emulator becomes
a single stand-alone file.

I can send the patch as is but I'm pretty sure you won't like what I've
done to the makefile ;)

> As I've repeatedly stated, I want to see development focused on the 
> simulators themselves, and not on the control package.  Too many 
> ideas for the core have proven to be non-portable.  SimH runs on 
> Windows, Linux, all major flavors of Unix, MacOS, and VMS.  Any 
> additions to the core have to run on them as well.  And any changes 
> to existing code need to be proven on all of them.

Would you accept a working check for the readline package?

scp.c checks for HAVE_READLINE but nothing ever defines it.  I tried
defining it and it seems to work.

> If you want to write a new simulator, or add a peripheral to an 
> existing simulator, you can more or less do as you please.  

I hope to write code for a VAX graphics peripheral.  Can't remember
which one but it is one that is reasonably simple and has (old) X
drivers.

> If you 
> want to modify someone else's code, you'll have to persuade them that 
> it's a good idea.

Of course.  Nobody said or thought otherwise.

But it is sometimes easier to show something is a good idea if one gets
to try it out for sometime WITHOUT disturbing the mainline code and
WITHOUT the subsystem maintainer having to agree at first.

> 3. C99, INT64, and other cleanup
> 
> SimH is nearly 15 years old.  It started when PC's were 66Mhz 
> 486's.  The code reflects a concern for performance and conservation 
> of resources.  I'd like to keep it that way.  The vast majority of 
> PC's in the world are still 32b, and that will continue to be true 
> for some time.  And some SimH host systems will always be 32b.

Yes.  But gcc and GNU make is something simh relies on everywhere.
Gcc has supported uint<width>_t for a long time -- it even works with
gcc 2.95.5, which is just about the oldest version still in use.

I like small and old computers too -- my flat is full of them.

Removing the USE_INT64/USE_ADDR64 defines from the compiler command line
and the makefile doesn't make simh run slower.  Neither does undoing the
conflation of address size and maximum file size.

> The _c99 flag was put in the make file to cope with a major bug in 
> gcc 3.3/3.4.  If you are absolutely sure that no one is using those 
> versions of gcc anymore, world wide, then it can come out.

I wasn't even thinking about that (you mean -std=c99?).  It's just that
C99 implementations are so widespread that we might as well take
advantage of them.


> 4. Documentation files
> 
> PDF format is universally readable.

Not with less, not with grep, not in a text editor, and they don't work
well with diff and patch ;)

>   The alternative would be Word 
> (the actual document source format).

What if somebody else made rst work?
With both PDF and HTML output?

-Peter




More information about the Simh mailing list