Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ritcv.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!princeton!rocksvax!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: net.arch
Subject: Re: flexible-instruction-set machines (longish)
Message-ID: <8799@ritcv.UUCP>
Date: Fri, 21-Jun-85 21:30:12 EDT
Article-I.D.: ritcv.8799
Posted: Fri Jun 21 21:30:12 1985
Date-Received: Mon, 24-Jun-85 02:53:09 EDT
References: <1452@ecsvax.UUCP> <290009@acf4.UUCP> <5694@utzoo.UUCP>
Reply-To: mjl@ritcv.UUCP (Michael Lutz)
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 77
Keywords: B1700, User microprogramming

In article <5694@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>Actually, my impression was that most everyone had been discouraged by
>the B1700's flaws.  The concept was fine, but performance was not, and
>there was also the nasty problem that with different microcode for each
>language, it becomes very difficult to mix languages (e.g. to call Fortran
>number-crunching routines from a program written in something else).
>Burroughs also did a lousy job on software and marketing, as I understand
>it, from the viewpoint of researchers and non-Cobol production shops.

Ok, the straight poop from an old poop who actually used the B1700
(microcode & all) in graduate school:

1. Performance was not spectacular in the absolute sense, but was quite
   good given the market Burroughs staked out for the machine.
   Remember:  it was designed to go head-to-head with the IBM System 3,
   which was essentially an RPG machine used by small companies and
   service bureaus.  For roughly the same money, the B1700 provided a
   multitasking, virtual memory, multilanguage, multiarchitecture
   system.  It is hardly the engineers' fault that Burroughs chose to
   squirrel away most of the neat stuff (99.9999999% of the Burroughs
   sales force had *no* idea what it was they were selling).
   [Digression: our image processing group used to run their
   reconstruction algorithms on the machine because it had virtual
   memory and the CDC6400 didn't have enough real memory to hold their
   matrices].

2. Performance for any one language was sub-optimal (easily demonstrated:
   even if the architecture were perfect, the implementation could always
   be improved by tossing the microcode & doing everything in hardware).
   However, performance across *all* languages & architectures was better
   than other systems in its price range.

3. It was an ideal machine for trying out new architectural ideas.  Microcode
   was relatively easy to write (in a high level assembly language).
   The internal registers all had special properties appropriate for
   different phases of the instruction cycle.  The impression one got
   was that the information you needed was where you wanted it when you
   wanted it (sounds like Unix, eh? :-).  Memory was bit addressable,
   and ALU operations could easily be tailored for any bit width.  Some
   of the emulators exploited this: one instruction set based opcode
   length on static frequency statistics; another determined the
   address length from the number of distinct identifiers.

4. In general, the software (micro assembler, compilers, utilities)
   were modern if not futuristic for the early '70s.  The operating
   system and other systems programs were written in SDL, an ALGOL &
   PL/I hybrid with data structures and no gotos -- of course, it had
   its own specialized architecture.  The main problem with MCP (the
   operating system) was that it was single threaded (i.e., it executed
   in its own dedicated context, rather than duplicating the context
   for each process like Unix).  If one process blocked on disk I/O,
   the operating system blocked for all intents and purposes.  It would
   try to run other processes, but if they made a system request, they
   blocked even if the request required no I/O.  Arguably a flaw, but
   MCP provided services (like virtual memory) which were unusual even
   for large systems, with as little as 48Kbytes of real memory!

5. The biggest problem, as Henry noted, was the inability to create a
   program using routines written in different languages.  I know our
   group did some preliminary research on this issue, but we dropped it
   when other more exciting projects came along.

All in all, I liked the machine.  It was diametrically opposed to
current RISC ideas, but it was a clean implementation of its
philosophy, and one worth looking at when comparing architectural
concepts.

Anyone else on the net from SUNY/Buffalo want to support or refute
this?  Are you out there Bill Hopkins?

P.S. I also worked on the Microdata 1600 -- puke! blecch!  It was an
ugly microarchitecture, impossible to use, and slow as mud.  Other than
that, it was perfect.
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA