[Simh] Way out idea for simh

Larry Stewart l.simh at stewart.org
Wed Apr 20 18:00:57 EDT 2016


You step away from the computer for a day and your inbox is full!

We want to transfer files back and forth between guest file systems and host file systems, preferably while the guest is running.

The mechanism should be as generic as possible, rather than be wildly different for each environment.  (It probably can’t be identical always, because some guest environments have unusual encodings, or unusual file semantics, and so forth.)

The mechanism should require minimum code for the guest environment, since each one is different, and most of us are not skilled at more than one or two environments.

I think unless you shutdown the guest, add files to its filesystem, and restart, it is going to be hard to avoid writing at least some guest code.  How minimal can it be?

Let’s try a thought experiment, of implementing the simh commands 

hosttoguest <hostfilespec> <guestfilespec>
and 
guesttohost <guestfilespec> <hostfilespec>

Taking hosttoguest first.

simh itself could obviously read from a host file, in a generic way.
Only a guest program can really deal with <guestfilespec> and write to the guest file system while it is live, so I think there has to be a guest program, called, say
magictoguest <guestfilespec> which reads from some magic data path and writes to the guest filesystem.

When you type “hosttoguest” at the simh prompt, simh opens the host file, and somehow (by stuffing a command into the console?) activates the magictoguest utility.

The magic datapath is up for discussion for the most generic possible solution, but it could be anything.  simh is a simulator and controls the horizontal and the vertical, so
the magic datapath could be previously illegal instructions that have new powers, or magic I/O addresses, or even just an attention grabbing <sequence> of memory references.  For historical reasons, I would recommend Up, Up, Down, Down, Left, Right, Left, Right, B, A, Start.  simh would notice the sequence, and that would identify the memory location(s) in use for data transfer.

The magic datapath could be minimal and would be simulator specific, co-written with the magictoguest utility program.


guesttohost, similarly, is broken into a generic part in simh for writing host files, and a minimal utility on the guest for reading guest files, connected by pretty much any magic datapath.

This is a considerably more minimal idea than a filesystem, but when you want to transfer a bunch of files, you can write a script.

The SIMH and System Verilog simulators for the SiCortex ICE9 (sort of a MIPS) had some magic extra instructions to provide communications (putchar, getchar, test PASS and test FAIL) for programs running in simulation, and fancier functions (zeroing memory regions) intended to greatly speed up otherwise boring parts of simulations.

If you don’t want to initiate transfers from the simh side, then the guest utility can pass the host filespec up to simh with only slightly more complexity.


magictoguest.c
===============

#include <fcntl.h>
#include <unistd.h>

int mailbox;

#define EOFBIT 0x100
#define DATAAVAILABLE 0x400

int magiceof()
{
 return (mailbox & EOFBIT);
}

char magicgetchar()
{
 char c;
 while ((mailbox & DATAAVAILABLE) == 0);
 c = mailbox;
 mailbox &= ~DATAAVAILABLE;
 return(c);
}

int main(int argc, char *argv[])
{
 int fd;
 if (argc != 2) return(1);
 fd = creat(argv[1], 0666);

 mailbox = 'H';
 mailbox = 'e';
 mailbox = 'l';
 mailbox = 'l';
 mailbox = 'o';
 mailbox = ' ';
 mailbox = 'W';
 mailbox = 'o';
 mailbox = 'r';
 mailbox = 'l';
 mailbox = 'd';
 /* that sequence of writes to <anywhere> wakes up simh and identifies the mailbox */

 while(!magiceof()) {
   char c;
   magicgetchar();
   write(fd, &c, 1);
 }

 close(fd);
 return(0);
}




More information about the Simh mailing list