190
-McGonagle: You have consultants and we have product management.
One is as bad as the other.
Wald: Before we relegate compilers/code generators to the past decade, would someone support the argument that isn't it better to translate those semantics once in the compiler than to force the microprogram interpreter to do it every time?
Deerfield: At the risk of talking too much .•. The two of you have said things which I really disagree with. I would like to make another brief comment here. First, I am not in favor of microprogramming. I think I've been through that for too many years.
Wald: You've put those childish things behind you?
Deerfield: I'd like to go on record that I have, although that's not quite true. There are some cases where I still feel it's the right way to go.
l'm not in favor of complicating the computer hardware, eithet. I'm not in favor of eliminating compilers. What I'm saying is that in the hardware, we ought to put the mechanisms which are common to all your compilers.
All the ones which you no longer even talk about. When I say I for example, handle the algebra, I simply mean ..• every one of your compilers has
a routine which it goes through which does such things as locating the center of your parenthesis. I think these methods should be put in the hardware. In this manner, you still have the syntax and you still have all the variability and you can still write all your compiler programs and vary them. I think the hardware ought to take the burden. The other thing I want to say is the cost of hardware today, now that we're going to LSI, the gate cost is so low I that we're really not talking ... The cost is now interconnection, rather than the number of gates on a chip.
The cost of gates has gone so low that to not do these things, I think I is to miss the boat. So, again, when I say I'm against microprogramming, its for the reason that with the high speed scratch pads and task memories that we have, that I can write you a macroprogram which is just about as fast as your micro. A macro subroutine, if it competes with my micro-subroutines, is probably not worth translating from my machine language.
into my micro-language, and I think, we're getting too many levels of language here.
Floor: It seems to me what you're saying is that the difference between microprogramming and macroprogramming is basically a matter of memory speed and, perhaps, (turn around time) .
191
-I Ii"J I come to the conclusion a little earlier that there were some things that a programmer did that you had to escape to machine language to perform.
Are those part of the problem the programmer is trying to solve, or are they artifacts of the machines that we can get rid of?
Deerfield' Are they problems that the user is trying to solve. He is neither the artifact designer who throws in gimmicks, features, bells and whistles, nor is he the programmer ... Dave made the comment that 'he's never seen a machine which did list structuring within the machine. That's not quite true. We've recently built a multiprocessor that does some very fancy list searching within the hardware, which is structured after lists which are really part of the software problem. One of the interesting things was some-thing into your computer for your customer. I think your compiler ought to be able to use it. •• I've designed lots of bells and whistles into my
-is built without a single GOTO. Secondly, I think the problem -is that industry does not meet more often like this, where we can sit down and hash these things out. Everybody is doing everything secretly and every-one is trying to every-one up everyevery-one else, since they know better. I think the biggest problem is there is no free and open exchange. This floating point
problem where everybody makes crazy as sumptions. Floating point is more expensive than fixed point. Everyone knows all the answers. No-body talks about it. When we have conferences, people take out their slides, talk and go away, instead of putting everything on the table and finding out what is the problem. Engineers very rarely talk to software people and software people rarely talk to engineers, except in these rare cases. What can you expect? •• As far as getting to microprogramming, the software people look at it as an extension .•• Who is it who should design the software system for the computer? The engineer or the soft-ware man? This is where that problem resides •.• The engineer who builds the computer doesn't know how the software person wants to use it. He may want to program a sine routine. If there are ten programmers, they might want to program the sine ten different ways. Ten different users could have these ten different routines microprogrammed the way they want to. Just like one guy at IBM took the EULER language, took the ROS memory and built a list processor. He made the 360 look like a list machine.
McGonagle: He made it look like a 5500.
Nimensky: Microprogramming is certainly more flexible. It allows you to build a hard machine to use whatever language you want. That is, why not let the compiler writer design the instruction set he needs. If he only needs six instructions, why bother with the other 125 that AADC has if they are not needed.
Wald: How about the data declarations? Do you think there should be a translation process in mapping the memory or should we interpret the data declaration each time we pick up an operand?
Nimensky: That depends upon what the problem is. Any type of list proc-essing, LIST, EULER, all these, you can mix data up in any way ... You never know what it is. They have to be self-identifying. Either it has to be self-identifying by, some pointer or some bit size or whatever. Again, in a microprogram would
b'e
lovely if we could microprogram the word length, the address fields and all these things. So we can structure the machine.In other words, give us a piece of hardware that programs the hardware and you can build the instruction set, you can build the addres sing scheme