Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!esegue!Postmaster From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: loadable control store, an idea whose time has gone Message-ID: <9011032126.AA08955@esegue.segue.boston.ma.us> Date: 4 Nov 90 02:26:45 GMT References: <1536@ftc.framentec.fr> <1990Oct19.120218.9450@canterbury.ac.nz> <15497@hydra.gatech.EDU> <2176@lupine.NCD.COM> <42310@mips.mips.COM> <42488@mips.mips.COM> <2817@crdos1.c Sender: Postmaster@esegue.segue.boston.ma.us Organization: I.E.C.C., Cambridge MA 02238 Lines: 38 In-Reply-To: In article you write: >But this thread was about the usefulness of having multiple high level >instruction sets, each tailored to one particular purpose. There is no reason >for this not to work, and it results in impressive code size reductions. The Burroughs 1700/1800 series had a microcode interpreter for each language. It was extremely slow. Perhaps it's because the people writing the microcode didn't try hard enough to make it fast, but I suspect that the problem was more that microcode interpretation was still too slow. >Little can be done to avoid the problem with extra dispatch time to the >control store, except implementing the simplest high level instructions >as special, direct execution, cases; on the other hand we could have >very low level, microprogram like, instructions at the architecture >level (e.g. VLIW), but then so much of the CPU/ALU innards are exposed >that recompilation becomes necessary across the architecture >implementations, which is a no-no since the system/360 days. Funny you should mention that. The IBM System/38 and its sequel the AS/400 use an interesting scheme. Compilers (most commonly RPG III, but keep reading anyway) compile into a high-level macrocode object code. Among other things the macrocode has huge addresses implementing a single level store. At the time a program is loaded, the program loader translates it into the actual microcode for the processor upon which it is running, including binding addresses into the machine's actual address space, typically 32 bits. You can even put breakpoints into the macrocode and the translator makes it all work in the translated code, installing and removing breakpoints and translating the state at a break back into macrocode terms. Different processors have different microcode, but since object code portability is at the macrocode level, nobody cares. Clearly, the microcode has to be designed to support the macrocode, so there are fairly strong constraints on the design of the microengine, but it does permit a wide range of different performance implementations without the interpretation overhead that conventional microcoded machines have. Regards, John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!esegue!johnl