Date: Tue, 23 Sep 1997 11:06:55 -0600 (MDT)
From: Roger Ivie <IVIE AT cc DOT usu DOT edu>
Subject: Re: ClosedDos???
To: OPENDOS AT delorie DOT com
Message-id: <01INZ9LBYEF6BF3ME2@cc.usu.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Precedence: bulk

Arkanoid wrote:
> > Date: Tue, 23 Sep 1997 09:29:31 -0600 (MDT)
> > From: Roger Ivie <IVIE AT cc DOT usu DOT edu>
> > Subject: Re: ClosedDos???
> > To: OPENDOS AT delorie DOT com
> >
> > It has been some time since I have looked at the code generated for the more
> > recent device drivers I've been doing in C. The Alpha/VMS guys have done a lot
> > of work to make C an excellent language to use for writing VMS device drivers.
> > The only drivers I still do in Macro-32 are ones that either execute on the
> > VAX, are ported from the VAX (i.e., have executed on the VAX), or deal with
> > portions of the kernel that are not yet C-friendly (such as the terminal
> > class/port driver interface).
> 
> Hmm.. but look at VMS versions: more C - higher hadrware requirements.
> V4 used 2Mb RAM,V6 uses 16!

V1 was 512K. VAX/VMS does not use C in the kernel, even at V7.1; you cannot
blame C for the increase in VAX/VMS memory requirements. Alpha needs more
memory even for assembly language; you cannot blame C for the fact that
Alphas require more memory.

I run V7.1 on a VAXstation 4000/60 which has only the 8MB installed on the
motherboard. V6 does not _require_ 16MB to run. I did, however, have to 
bring my VAX 8250 above 4MB to run V5.5, so I doubt V7.1 will run in 4MB.

My personal gripe about the advance of C into the VMS kernel is about
interrupt latency rather than memory requirements.

I have a device which I can use to measure interrupt latency. It's a large
counter which generates an interrupt when it overflows. The device driver
starts the counter going; when the interrupt happens, it reads the counter
(which keeps counting after the interrupt) and reports the value read to
the user program. The value read by the interrupt service routine tells
how long it took the machine to see the interrupt and execute the interrupt
service routine.

In Alpha/VMS V1.5 interrupt latencies were typically 10 to 20 microseconds,
no matter what the machine was doing. Interrupt latencies for the same
machine running OSF/1 were awful; there were a number of things you can do
that turn interrupts off for a couple of milliseconds (most of the easy
ones involve X; moving a window around on the screen, popping a window
so that it has to be repainted, etc.). While VMS is not as snappy to the
user (it takes longer to start a process, longer to create X windows), 
where the rubber meets the road it had excellent performance.

When Alpha/VMS 2.3FT1 came out I ran my tests again. 2.3FT1 is the first
version that supported C in the kernel. A lot of the device drivers had
been redone in C and large parts of the kernel were in C. I found that
2.3FT1's interrupt latency looked a lot like OSF/1's.

V1.5: Macro-32 kernel and drivers, terrific interrupt latency.
V2.3: C kernel and drivers, Unix-like interrupt latency.

Coincidence?

I have not yet measured the interrupt latency of V7.1 and V2.3FT1 was a
field-test version, so the latency of the system as shipped may have
been quite different from what measured.

> > C doesn't fit everywhere[, but w]ere I writing MS-DOS device drivers, 
> > I would certainly look at doing them in C.
> 
> I'd better think on low-level language like C-- or PL/M-86
> BTW is there such thing as PL/M-386?

I believe there is a PL/M-386, but I can also guess how many vendors
support it (hint: even Intel doesn't support PL/M anymore).

Roger Ivie
ivie AT cc DOT usu DOT edu