Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!sol.ctr.columbia.edu!cica!iuvax!rutgers!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay) Newsgroups: comp.arch Subject: Re: Historical architectural advances?? Message-ID: <10800@pt.cs.cmu.edu> Date: 18 Oct 90 18:29:02 GMT References: <1990Oct4.001346.4139@Stardent.COM> <8052@scolex.sco.COM> <2926@sequent.cs.qmw.ac.uk> <1990Oct11.164904.12550@zoo.toronto.edu> Organization: Carnegie-Mellon University, CS/RI Lines: 23 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Note that the Burroughs concept was not bad -- they achieved phenomenal >code densities. They had a separate microprogram for each language, so >to run multiple language in multiprogramming you had to be able to >switch microcode (and instruction set) at every context switch. I believe that the Cobol compiler achieved the most dramatic code density - an order of magnitude at times. Given this apparently big win, why did the idea die off? I suspect it's because they slimmed the user's code sizes by increasing the system's code size. The micromemory has to be faster than main memory, hence more costly: perhaps not all users got a net win. That may not be the reason. Somewhat later, Xerox invested effort in tuning an instruction set for maximum density. This was partly a bet that memory cost mattered more than speed, and partly a bet that code size would be a significant fraction of memory size. They pretty much lost their bet, and are now using SPARC. -- Don D.C.Lindsay