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