Possible PUTR bug?

[Chuck Guzis]

On 5/11/19 2:00 PM, Fred Cisin via cctalk wrote:

> Although I enjoyed DeSmet C, I used Microsoft C for all subsequent high
> level language progams that I wrote.  For example, I wrote the screen
> capture TSR of "XenoFont" in MASM, and the printing program in Microsoft
> C; I wrote "Sales tax Genie" (TSR) in MASM, but then later renamed the
> .COM file to .EXE to use it as the "stub" program of a Microsoft C
> Windoze program, to have a single file that could load the TSR in DOS,
> AND be able to run as a Windoze program.  I never got around to redoing
> the TSR formats to be able to ALSO load them as device drivers (lets you
> get them into lower memory!); I intended to eventually create a single
> executable file format that could be loaded by CONFIG.SYS, CMD.COM, AND
> Windows.

My first FILES-11 RX01 read-conversion tool was written in PL/M and ran
on an MDS800.

My second FILES-11 RX01 reading/conversion utility was written largely
in FORTRAN.  System was an 8080 S100 box with a WD1771 controller.

C on an 8080/85 system seems like a horrible waste of hardware, owing to
the need for procedure-local variables.  Stack-based addressing isn't
pretty.  Basically to load a 16-bit stack-based integer into BC you have
to do something like this:

   LXI  H,offset
   DAD  SP
   MOV  C,M
   INX  H
   MOV  B,M

Add to that, that really good "C" compilers for the x80/x86 took some
time to mature.  My first C on an 8086 was Lattice; compiled on a
floppy-based system.  But then Microsoft MASM 1.0 was terrible in its
own right as well--the list of errata was quite long.  I remember
mumbling to myself "that's not what I wrote!".

--Chuck