Xref: utzoo comp.misc:2445 comp.arch:4907 Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!sri-spam!ames!pasteur!ucbvax!hplabs!nsc!stevew From: stevew@nsc.nsc.com (Steve Wilson) Newsgroups: comp.misc,comp.arch Subject: Re: Japanese 32-bit micro can be a 68020 or 80386 Message-ID: <5078@nsc.nsc.com> Date: 20 May 88 01:41:30 GMT References: <2006@sugar.UUCP> <53583@sun.uucp> Reply-To: stevew@nsc.UUCP (Steve Wilson) Organization: National Semiconductor, Sunnyvale Lines: 31 >I'm not sure that the "buckets of microcode" or, if you will, the "use the >microcode as a fast machine language and write a big interpreter in this >machine language" approach is necessarily the only way to get those languages >to run efficiently, or even necessarily the best way. > >> Imagine a version of the microprogrammable chip in which the operating >> system could context switch among trusted sets of microprograms. Weird. > >Weird, maybe, but did not the Burroughs 1700 series do this a long time ago? Yes! The 1700/1800/1900 series machines switched interpreters as a function of which language the machine was emulating for a given program. Even most of the OS(called an MCP for you Burrougs fans) was mostly interpreted except for the interrupt handling routines. Note that it was also fairly SLOW! The base hardware ran at something like 6 MIPS and the instructions being executed were fairly simple. I think some time ago I saw a Datamation estimate at 200Kips performance. Another limitation of the Burroughs architecture was that Memory management was also done with software! This is probably about the only machine in computer science history that got slower as you added more memory! The OS had to periodically scan the memory segments to build a map of what was available. More memory meant a longer scan time. In summary, the B1700's were neat machines, but probably are inherently limited when top-end performance is considered desirable [Standard disclaimer goes here!] Steve Wilson, National Semiconductor