old processor architectures [was Re: The Strange Birth and Long Life of Unix - IEEE Spectrum]

[Scott Allen]

On 7 December 2011 16:47, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:
> | From: Scott Allen <mlxxxp-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
> | The head technical guy was used to working on IBM System/360 class
> | machines, but we were developing products based on the 8080 CPU. The
> | 8080 based product was also suitable as a development machine. Rather
> | than create a development environment using 8080 code, he wrote a
> | System/360 instruction set emulator for the 8080 and then proceeded to
> | write an editor, 360 assembler, job control language, etc. in 360
> | assembly code. So we had an emulated System/360 running on an 8080
> | microcomputer.

> Emulating would have created an enormous hit.  If you were willing to
> pay that, might as well get something worthwhile for the cost --
> UCSD's pcode comes to mind.

I think that was probably the idea; that if we wanted to move our
development environment and some applications to another processor,
all it would require would be to write a Sys/360 emulator for it (it
never happened though).

Emulating did create a bit of a hit.
For instance:
If you wanted to see the machine code generated by the assembler, you
had to send the output to a line printer. The assembler was so slow
that the high speed Printronix P300 printer often paused due to lack
of input (at 9600 baud serial).

The actual product applications that used the emulator weren't that
time critical, though, so it wasn't much of a problem there.

> | Some parts of the 8080 product applications ran native 8080 code,
> | which was created using an 8080 cross assembler written in Sys/360
> | assembly code. So we had an 8080 system emulating a Sys/360 which ran
> | a cross assembler to generate 8080 code.
>
> That takes the cake: writing all that systems software, for no
> leaverage.  Wow.

Well, the same development environment was used to assemble or
cross-assemble for processors other than the 8080; the aforementioned
emulated Sys/360,
the National Semiconductor SC/MP
<http://en.wikipedia.org/wiki/National_Semiconductor_SC/MP>
the Fairchild F8
<http://en.wikipedia.org/wiki/Fairchild_F8>
the Intel 3000 bit-slice system
<http://www.cpu-world.com/CPUs/3002/index.html>
among others.
So having a different development environment environment just for the
8080 didn't make sense.

> One example where it kind of made sense: I understand that the IBM
> 5100 had an 8080, emulating a /360, so that it could run APL\360.
> This made a great implementation of a powerful language available
> without a mainframe.  It did not take over the world.

And, coincidentally (or perhaps not?), one of the first products that
we used this emulator for was an "intelligent" 8 inch floppy drive for
the IBM 5100, which natively only had tape support. The drive was
interfaced to the 5100 through a serial port.

>From what I find from a web search, the 5100 wasn't 8080 based. It
used a proprietary processor.

> | My experience was similar to Peter's: I preferred working with 8080
> | assembler over Sys/360 assembler.
>
> I imagine it is partly a matter of what you deeply understand.

And probably why the head engineer wrote the 360 emulator.

> The 8080 was quite workable for humans.  But it hit annoying walls
> quickly.  Like lack of address space, no indexing, almost no 16-bit
> support, let alone 32-bit support, no memory protection, no invalid
> opcodes.

Indexing was one of the big features that the Z80 added.

It also added invalid opcodes :-)

-- 
Scott
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists