Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site tikal.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!tikal!warren
From: warren@tikal.UUCP (Warren Seltzer)
Newsgroups: net.arch
Subject: Re: flexible-instruction-set machines
Message-ID: <171@tikal.UUCP>
Date: Tue, 25-Jun-85 16:02:34 EDT
Article-I.D.: tikal.171
Posted: Tue Jun 25 16:02:34 1985
Date-Received: Thu, 27-Jun-85 04:40:00 EDT
References: <1452@ecsvax.UUCP> <290009@acf4.UUCP> <5694@utzoo.UUCP> <8799@ritcv.UUCP>
Reply-To: warren@tikal.UUCP (Warren Seltzer)
Organization: Teltone Corp., Kirkland, WA
Lines: 57
Keywords: B1700, User microprogramming
Summary: B1700 worked very well.
Organizatio: Teltone Corporation, Kirkland, WA

Interpret this line with the natural language currently in your cortex ;-)

As a user of the B1700, in a harsh commercial environment, I would like to
add that the software was at least three levels above all the competition
available at the time.  When the B1700 came out, the IBM competor machine
was not even able to print and compute and the same time !  I was told that
the IBM salesmen claimed that spooling  "Didn't make the printer any faster".

The thing was great, it would run three Cobol programs at the same time.
(I admit it publicly, I've programmed Cobol ... ).  Several years later, the
Z80 CP/M system came out, and with twice the memory, couldn't walk and chew
gum at the same time - I was sorely disappointed.

The great weakness of the B1700 was its miserable reliability.  The static
charges from the printer would bring down the CPU for days.  The disk drives
crashed heads, the tape drives would skip out of alignment weekly, but they
would stream !   The MCP software would write one block after another without
stopping, if things went just right.  We became close friends with the
repair crew, but not with our management.

The Cobol compiler supported RECURSION !!  You could write these miserable
imitation subroutines that Cobol had (Performs) and it would correctly
recurse !

When it ran, it was great.  Burroughs could have built a version that 
supported the architecture of its Medium and Large series of machines, but
the B1700 eventually died out.

  WHY RISC SUCCEEDS -- AND VARIABLE MICROCODE DOESN'T

The success of risc is based as much on physics as on software.  The
cost of variable microcode depends on the cost of FAST RAM.  Its faster
to simply give the fast ram to the user, and make it available as a set
of sliding register windows (a la Patterson), than to force another
level of interpretation.

  RISC ~ CISC

The machine that the B1700 used to INTERPRET all that variable microcode
was very simple.  The registers were used in an innovative way.  Move
something to the X register, move something else to the Y register.  Now,
to get the sum, read the "X+Y" register.  To get the product, read the
"X*Y" register, and so on.  Parallel execution !   If the Burroughs B1700
series were alive today, Burroughs (or is it Burroughs-Univac ?)
could build a RISC, sliding register windows and all, and have it
interpret that old Cobol microcode.   But since they control the
compiler, they could change the code generated for those old Cobol
programs, even generate RISC instructions, if they want to.  There are
THREE levels of control:  1) The code the Cobol compiler generates, 2) the
microcode that interprets the generated code, and 3) the hardware that
interprets the microcode (2).  

As electronics migrates through VLSI to giga-chips, it may come back.
The thing is still viable, all they need to do is write new microcode for C,
and burn all that Cobol stuff !

	teltone:warren