hes@ecsvax.UUCP (Henry Schaffer) (06/11/85)
I have just heard a presentation by IBM on large systems directions. It was predicted that an increasing amount of operating system functions would be embodied in microcode. This seems to be the opposite of RISC - with a vengance. They find that system functions are significantly sped up by this approach, which does seem to be a good point. (I'm sure that they also find that using microcode also gives them a competitive advantage with regards to the PCM's.) Also it was pointed out that this makes MIPS even less meaningful, since some of these new microcoded instructions are comparable to an entire program, and yet just get counted as one instruction. --henry schaffer n c state univ
johnl@ima.UUCP (06/11/85)
>/* Written 7:01 pm Jun 10, 1985 by hes@ecsvax in ima:net.arch */ >I have just heard a presentation by IBM on large systems directions. >It was predicted that an increasing amount of operating system >functions would be embodied in microcode. This seems to be the >opposite of RISC - with a vengance. Maybe not. By the time you've moved enough of your code into microcode, you can think of your computer as a RISC (the microengine) which occasionally runs a 370 emulation program for backward compatibilty. If IBM doesn't watch out, they're going to have such an investment in microcode that when they come out with a new model it'll be as important to have microinstruction set compatibility as 370 instruction set compatibility. Then we can expect them to microcode the microcode, leading to fascinating generations of nano-, pico-, femto-, and attocode. John Levine, ima!johnl
gvcormack@watdaisy.UUCP (Gordon V. Cormack) (06/12/85)
> I have just heard a presentation by IBM on large systems directions. > It was predicted that an increasing amount of operating system > functions would be embodied in microcode. This seems to be the > opposite of RISC - with a vengance. > They find that system functions are significantly sped up by this > approach, which does seem to be a good point. (I'm sure that they > also find that using microcode also gives them a competitive > advantage with regards to the PCM's.) Also it was pointed out > that this makes MIPS even less meaningful, since some of these > new microcoded instructions are comparable to an entire program, > and yet just get counted as one instruction. > --henry schaffer n c state univ This is largely a marketing ploy. It was felt that competitors, such as Amdahl, could not respond quickly because their CPUs were not microcoded. It turns out that almost all of the improvement comes because the algorithms have been cleaned up, not because of embedding them in microcode. Amdahl simulates them in software using the following technique: the first time such an instruction is encountered, a trap is taken and the instruction is simulated. The opcode is then permanently replaced by a branch entry into the simulation routine. Amdahl claims similar performance to the IBM micro-coded instructions. Another note on large IBM instructions. Once upon a time (on a 370/168 as I recall) I observed that the PL/I compiler generated object code to move a string that set up registers appropriately for the use of the MVCL (long move) instruction. But instead of the MVCL, was a software routine. I assumed that this was done for backwards compatibility with the 360 (which didn't have MVCL) and so I replaced the software routine with a single MVCL instruction. The overall running time of the program was 20% greater! -- Gordon V. Cormack CS Department, University of Waterloo gvcormack@watdaisy.uucp gvcormack%watdaisy@waterloo.csnet
herbie@watdcsu.UUCP (Herb Chong [DCS]) (06/12/85)
In article <1452@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: >I have just heard a presentation by IBM on large systems directions. >It was predicted that an increasing amount of operating system >functions would be embodied in microcode. ... deleted material ... >Also it was pointed out >that this makes MIPS even less meaningful, since some of these >new microcoded instructions are comparable to an entire program, >and yet just get counted as one instruction. along with the IBM announcements of the Sierra processors came a little something which wasn't quite so dramatic. for certain processors, it is possible to get an RPQ Request Price Quotation) for instructions to do square roots, natural logarithms and exponentials, and the common trig and inverse trig functions, implemented in microcode. compared to the standard fortran library (VS/FORTRAN), these instructions are supposed to be about 4 times faster. many SVC and DIAG calls on IBM systems are already wholely implemented in microcode. IBM watchers predict that eventually, over 40% of the MVS operating system will be completely in microcode. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu
jer@peora.UUCP (J. Eric Roskos) (06/13/85)
You're right, I think (i.e., I'll take sides temporarily in this one).
The problem with CISC machines has tended to be that the instructions were
not developed in cooperation with the compiler writers. Thus you have (in
the classic example) the IBM EDIT instruction, which was supposed to be good
for COBOL, but unfortunately doesn't work in a way that is usable by COBOL
compilers.
For a starting point, most compilers incorporate run-time-libraries [however
you define that term] which perform functions not supported by the host
machine. An easy example of this is floating point arithmetic. Machines
without floating point instructions invoke run-time libraries; those that
have the instructions use them instead, with a performance improvement (if
the instructions are correctly implemented, of course). In the case of the
greatest floating point performance improvement, this is done by having
special hardware (e.g., floating point coprocessors) to perform the
operations, but how it's implemented is not really the issue here; the
issue is whether the "complex" instruction "Floating Divide", for example,
is "better" than a sequence of "reduced" instructions that do the same thing.
One of the problems with arguing for RISC or CISC is that they are just
high-level manifestations of underlying design approaches. It's my
opinion, personally, that a machine with writable control store which can
be dynamically loaded tends to give the advantages of both machines;
because you can microprogram routines that are executed often enough to
gain a performance improvement, while having the compact object code and
reduction in the number of primary memory instruction fetches (and just
simpler macroinstruction-level object code) which you get from the CISC
machines.
A reasonable approach to producing CISC machines, then, would be to have the
compiler writers design the instruction set; and to have the instruction set
be changeable for different languages. This could be extended by having the
instruction set be further changeable by the individual user, or automatically
by a program that analyzes instruction usage and moves frequently-used
instructions into microcode (vertical migration).
(These are not new ideas, of course; a lot of research is currently going
on in these areas, but is not as well-known as the RISC research, apparently.)
--
Full-Name: J. Eric Roskos
UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642
"Gnyx gb gur fhayvtug, pnyyre..."fwb@siemens.UUCP (06/14/85)
> ... > > A reasonable approach to producing CISC machines, then, would be to have the > compiler writers design the instruction set; and to have the instruction set > be changeable for different languages. > > ... > > Full-Name: J. Eric Roskos > UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Didn't Burroughs do something like this with one of its computers? I think it was the B1700. ------------------------------------------------------ Frederic W. Brehm princeton!siemens!fwb Siemens Research and Technology Laboratories ------------------------------------------------------
tihor@acf4.UUCP (Stephen Tihor) (06/16/85)
A reasonable approach to producing CISC machines ... to have the instruction set be changeable for different languages. (These are not new ideas, of course; a lot of research is currently going on in these areas, but is not as well-known as the RISC research, apparently.) It is good to hear that someone has not forgotten one or Burroughs few good ideas. Who is working on flexible instruction set computers now-a-days?
mwm@ucbvax.ARPA (Mike (I'll be mellow when I'm dead) Meyer) (06/16/85)
In article <1062@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >A reasonable approach to producing CISC machines, then, would be to have the >compiler writers design the instruction set; and to have the instruction set >be changeable for different languages. Burroughs will be glad to sell you a machine that implements that idea. Just goes to show (once again) that quality and market share are unrelated. >This could be extended by having the >instruction set be further changeable by the individual user, or automatically >by a program that analyzes instruction usage and moves frequently-used >instructions into microcode (vertical migration). Like the BBN C/70 box? Once again, ... <mike -- After 5 years, a quote worthy of Netnews (and it works as disclaimer!): "Truth is variable."
jer@peora.UUCP (J. Eric Roskos) (06/17/85)
> Didn't Burroughs do something like this with one of its computers? > I think it was the B1700. I think you are right! I have never worked with the B1700, but know people who have, and who felt that it was a really good machine. NCR also has done this for many years. In fact, if you want to see unusual, non-von-neumann machines, look at some of NCR's machines! Particularly things like the 399 accounting machine, which, when I last programmed one in 1980, was much more like a general-purpose computer than an accounting machine. On the other hand they tend to be slow ... but very different. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gnyx gb gur fhayvtug, pnyyre..."
iwm@icdoc.UUCP (Ian Moor) (06/19/85)
In article <33500001@siemens.UUCP> fwb@siemens.UUCP writes: > .... different instruction sets for different compilers/languages >Didn't Burroughs do something like this with one of its computers? >I think it was the B1700. > Yes that was it. I don't know if you could run different sets concurrently. We have just bought an Orion from High Level Hardware (Oxford UK) which lets different processes use different instruction sets (part of the process context is which area of microcode store to use) and runs BSD 4.1 on an instruction set optimised for C. It fits into a desk and comes with microprogramming tools running under Unix, looks real fun, and is likely to outsell most other workstations over here. -- Ian W Moor The squire on the hippopotamus is equal Department of Computing to the sons of the other two squires. 180 Queensgate London SW7 Uk.
freeman@spar.UUCP (Jay Freeman) (06/20/85)
In article <1062@peora.UUCP> jer@peora.UUCP writes: >A reasonable approach to producing CISC machines, then, would be to have the >compiler writers design the instruction set; and to have the instruction set >be changeable for different languages. This could be extended by having the >instruction set be further changeable by the individual user, or automatically >by a program that analyzes instruction usage and moves frequently-used >instructions into microcode (vertical migration). The issue seems to be the tradeoff between the following two approaches to implementing the functional equivalent of a complicated instruction set: (A) Do a CISC with loadable microcode, and put the complicated stuff therein. (B) Do a RISC and put the messy things in a ("loadable", of course) runtime library in main memory. Lower-level issues in the tradeoff would include (1) virtues of using CPU real-estate for microcode and interpreter (CISC) vs. registers (RISC); (2) speed and efficiency of paging and cache-management (since the RISC will access its runtime library more often than the CISC); (3) Possible slower operation of the CISC because of bottlenecking by stuff to support the microcode interpretation; (4) who's ahead in the race between memory speeds and processor clock rate -- are the systems bound by fetches or by processing time? A fine point, is that most of the CISCs' prospective vices do not go away if we should decide to minimize use of the microcode store -- we can't turn the empty store into more registers at runtime, nor can we speed up the clock. Thus if we consider a range of implementations: (1) RISC with runtime library (2) CISC with very little microcode and lots of runtime library too . . . (N) CISC with mucho microcode there is a prospective discontinuity in throughput between (1) and (2), whose possible existence and nature will probably complicate comparison of the various architectures. -- Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)
josh@polaris.UUCP (Josh Knight) (06/21/85)
> > Didn't Burroughs do something like this with one of its computers? > > I think it was the B1700. > > I think you are right! I have never worked with the B1700, but know people > who have, and who felt that it was a really good machine. > > NCR also has done this for many years. ... > -- > Full-Name: J. Eric Roskos Then there was the "EMMY" processor used for reseach at Stanford by a group lead by Prof. M.J. Flynn. Several PhD thesis were done using various versions of it, and (at least) Fortran and Pascal "machines" were implemented for it. There were also emulators of "standard" architectures, notably the PDP-11 (that particular implementation was complete enough to run a Version 6 Mini Unix), as well as an obscure Danish computer, the RC4000. There was also a relatively complete IBM 360 emulation. A modified version of "EMMY" was used by ICL as the micro-engine for one of their processors. BTW the RC4000 may have been emulated on as many architectures as any other computer. I know of a C implementation that ran on a VAX (mine), PDP-11 and DG Nova assembly language versions, the above mentioned "EMMY" version and I think they simulated the beast on something before they built it. Josh Knight, IBM T.J. Watson Research josh at YKTVMH on BITNET, josh.yktvmh.ibm-sj on CSnet, ...!philabs!polaris!josh
doug@terak.UUCP (Doug Pardee) (06/22/85)
> A reasonable approach to producing CISC machines ... to have the > instruction set be changeable for different languages. If the machine is going to do multi-programming, it's going to need bank-switched micro-instruction memory or the like. -- Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug ^^^^^--- soon to be CalComp