[Simh] Porting simh for IBM VM/CMS

[Dave G4UGM]

> -----Original Message-----
> From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com]
> Sent: 03 August 2015 20:36
> To: Dave G4UGM <dave.g4ugm at gmail.com>; rubhone at aol.com
> Cc: simh at trailing-edge.com
> Subject: RE: [Simh] Porting simh for IBM VM/CMS
> 
> On Saturday, August 1, 2015 at 11:29AM Dave G4UGM wrote:
> > On Saturday, August 1, 2015 at 10:32AM Fritz wrote:
> > >Perhaps this original code struck you as nasty because it is really a
> > >hidden OS dependency, is it not?  Or are character set arrangements not
> included in that realm?
> 
> > Well it’s a character set dependency and a really neat piece of optimization.
> > However its hiding something in a bit field, a trick which in High
> > Level languages has always caused me problems in the past.
> > I think it would be more portable to have the Alphabet as a string
> > “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then search through it for the
> wanted
> > character, but of course much slower…
> 
> That is a good suggestion, AND since code paths which use the SWMASK
> macro are not performance sensitive speed really isn't a concern.
> 
> The simh code at https://github.com/simh/simh has been changed to
> implement the SWMASK macro with code which does this as Dave
> suggested.
> 
> The simh source code now doesn't have a ASCII character set dependency,
> however, many/most of the systems that have simh simulators expect ASCII
> characters as input and output.  Mapping from host platform character set
> into the ASCII simulated character set will also be required as you move
> forward...
> 
> > >Thinking about related matters, do I need to be concerned that the
> > >IBM systems are big endian?  It appears that simh takes this into
> > >account with the sim_finit routine in sim_fio.c, but there could be other
> places with data coding assumptions not fitting the /370 architecture.
> >
> > It possible, but its probably easier to try and test, rather than to find.
> 
> The simh codebase works fine on big endian systems.
> 
> > >For the moment, I hacked the "attach" <dev>" code to avoid a rb+ file
> > >open attempt since the CMS implementation of the stdio package does
> not support simultaneous r/w file access.
> > >This will surely prove to be another big problem, but for now the
> > >attach is successful for an existing file.
> >
> > You didn’t say which IBM platform you were running this on, and which “C”
> compiler….
> 
> A C runtime environment which supports open mode "rb+" is definitely a
> requirement.
> 
> I have no familiarity with VM/CMS, but the name (and the issues Fritz
> previously mentioned) suggest to me that this is a legacy environment.

VM/CMS suggests to me the freely available VM/370R6 environment, which is definitely a legacy environment, and the only way I know how to run it is under the Hercules IBM Mainframe emulators.
There are two "C" compilers that will generate "C" code on this environment. One is a port of GCC 3.4 (I think, its been a while) but the code is really only enough to support the C90 environment. There is no C++ and it uses the VM native linker and loaded which also have restrictions. The other is called JCC and I haven't used it in ages, but from what I remember it only works as a cross compiler...

However there is a modern zVM environment which is broadly upwardly compatible with VM/370 R6. It has an IBM provided "C" compiler which  is compliant with modern standards, but it is still EBCDIC so the macro is broken. I am not sure how it supports "rb+" but the file system is record orientation so how you translate the "C" stream oriented paradigms can be "interesting"...


> Porting simh to run on legacy environments is generally out of scope with
> respect to the project goals.  The general simh goals are to provide ways of
> simulating legacy environments or systems on modern systems.
> 

That’s kind of why I was trying to figure out if he was using a modern VM or a legacy environemt....

> - Mark

Dave