schow@bnr-public.uucp (Stanley Chow) (04/27/89)
Since this discussion of complex instructions is venturing outside of architectural issues and getting into language/OS issues, I have cross posted to what I think are appropiate groups. Hopefully, we can get some other viewpoints on this issue. Please limit followups to appropiate group(s). In article <25384@amdcad.AMD.COM> prem@crackle.amd.com (Prem Sobel) writes: >Many years ago, there was a machine called the Interdata Model 70 which >had instructions for atomically adding or removing items from circular >double ended queues. The data structure was defined reasonable effeciently >and the machine was microcoded. > >Yet no one, no compiler seriously used these instructions. The reason was, >amazingly, that individual instructions were faster!!! I never looked at >the microcode, so I cannot comment why that was. Strangely enough, we have a proprietary machine that have micro-coded instructions for much the same functions. The queueing instructions happen to be at the top of the usage list. Even more amazing, micro-coding of frequently used instruction sequences essentially doubled performance. Since I wrote much of the micro-code, (and did much of analysis to begin with), I can state that the main reasons are: - reduced program bandwidth - better pipelining of program and data access - better parallelism for using the hardware units. All this is done with a peephole optimizer! And *all* the instructions fitted into 4K by 40 bits of micro-code! You think the VAX procedure calling instructions are big? We have special instructions for swapping processes in and out! The code for swapping process is something like: SaveRegisters(); ; one instruction. ; old process is implicit RestoreRegisters(new_process); ; another instruction These instructions play with the hardware registers, firmware registers, help the scheduler do software stuff, calculate the CPU time spent in the current process, save/restore the runtime stacks and some other things that I cannot remember off hand. The end result is that process swapping happens at data memory bandwidth. We looked at the options, and concluded that even with absolutely no program store wait-states, it is impossible for any software (compiled or hand-tuned) to evan come close to this performance. Note that this is on a machine designed for micro-coding in the early 70's so the comparisons may not be valid for current machines. Considering that it uses only MSI TTL on 4-layer boards, we get very good through-put. [We have already come out with a 68K based replacement and are working on more fun stuff, more about that next decade.] A word of caution for people that want to look into micro-coding: get control of your operating system and compiler before you try it. There is no point in micro-coding instructions for your application unless you can make the OS and the compiler like it. (I managed to introduce new syntax into the language and changed whole chunks of the OS to support some of the fancy micro-code). Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 Disclaimer: Since I am only talking about an old system, and all the information has already been published in one form or another, I don't think my employer minds we talking about it. That does not mean I represent anyone. -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
schow@bnr-public.uucp (Stanley Chow) (05/08/89)
Since this is moving from architecture to language, I have set Follow-up: to comp.lang.misc. In article <1277@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <504@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >> In article <426@bnr-fos.UUCP>, schow@bnr-public (Stanley Chow) writes: >> >it is not necessary for all programmers to know enough to use >> >the specail instructions. Some guru can set it up and everyone can >> >then use the pre-built modules. Depending on how you set everything >> >up, the compiler does not have to be smart at all. > >I agree it is not necessary for ALL programmers to know how to really >use the computer, any more than it is necessary for the house painter >to be an artist. But the artist cannot set up the modules for a >house painter to produce a work of art. > This is probably a major difference in opinion between groups. You are an artist and feel constrained by the languages that are designed for painting houses. Much of the programming in this world is done by house painters as opposed to artists. In the case of our project, all "artists" who wants/needs to are turned into guru's and set up utilities for themselves and others to use. The system is by no means frozen. I can understand your pleas for flexibility. Forturnately, I have quite a bit of it. I am allowed to change (or at least influence) everything from hardware, firware, language, compiler, operating system through to any application code. If someone sees a new use for some instructions, we change the utilities or compiler as needed. New hardware that will be usefull? We will just throw it into the next revision. Having said that, I must point out that we are (very?) unusual. Most projects are not big enough to support this style of working. if you have to rely on a commercial compiler; chances are the compiler was not optimized for your needs. This means the compiler writer had to trade-off many different demands. Unforturnately (from your point of view), portability is high priority, good debuger is important, good object code from protable source is compulsory. Since most people don't care about flexibility to take advantage of different architecutes, you don't get that from most commercial compilers. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.