lS2
-Panel 1: Software Commonality partiCipated in the iniital development of JOVIAL. He developed compilers for special purpose languages and COBOL. He created a dialect of PL-l and QUICKTRAN time sharing system, Jacobi System's MINITS Time Sharing System.
At the UCLA Computer Science Department, he is working on the ARPA Network Project. Multiprocessing architecture and operating system design study and the Meta 5 Compiler Computer System. His present interest is memory architecture and storage allocation algorithms for multiprocessing systems.
I went to school at New York University. From there I went to NASA's Electronic Research Center where I participated in the development of CLASP. For the past six months, I've been with Logicon. problems concerning compatibility. SPL has a compatibility problem with CLASP. We spent many, many man months of effort trying to get CLASP and SPL so that we'd only have one language for spaceborne computers. I think that (attempt) has basically failed. As we said this morning, we have
153
-FORTRAN which is probably the most universally used language in the world assignment, hopefully, without the retraining cycle.
Bersoff: Let me ask this: Is there a ••• I'd like to get an admission that
-consistent with the other isn't meaningful. I think the real problem presently thinking of it, the upward compatibility, re-useability of the software is more of one compiler •.. say it's the newest one ..• in some Meta Compiler, does this not remove the compatibility problem? Shouldn't it be easy to build a subset translater that would be able to handle your
using the programming language so that there wouldn't be this variation
Bersoff: Somebodyelse building a compiler might have a different syntax language and a different code generating language.
Nimensky: That's fine.
-example. PL-l is rather a large language. It's syntax can be modified. has never been clearly specified. Various compiler writers have written different things. In one case, people have chosen it to mean the result programs from one language system to another language system?"
Bersoff: Maybe there's a way to get around compatibility by asking: Is there a need to program AADC in a high level language, given that its instruction set is so rich, or, on the other side, why can't the AADC handle high level language statements?
Floor: To start off with a personal opinion, if tbe machine is going to be
-Bersoff: If you have an algorithm library you can program all your tasks in assembly language separately, and have the Synthesizer put it together.
You don't, necessarily, need the compiler as part of the synthesizer.
an avionics computer without knowing something about the engineering systems •••
at least you cannot do it economically.
-~-Cerf: Nobody's going to argue about that; the point is. what language do you it (with resorting to assemb~y language programming).
Bersoff: I guess we'd all agree to that. Now let's assume that SPL. CLASP. and
-Engelbach: I can do both. The reason I say I can do both is because I have a
Engelbach: SPL has five implementation subsets, and the smallest implementation subset is CLASP. If we want to have a language argument we can get down and all writing different compilers to run on different machines, presumably with flexible rear ends that can feed out to any computer, and yet, we're
-Engelbach: The problems I face on a management level on compatibility have been
languages, you can't write the monitor without breaking into assembly language.
161
-O'Brien: That's true in many cases.
problem within the Company (Burroughs) of stopping people from writing in ---peripherals, the interface between the machine and the peripherals. The
peripherals are all different. You need different disk packs to get certain control software.
Cerf: There's no problem. You can generate the bit patterns. That should not be a problem at all.
McGonagle: You can generate bit patterns. I'm generating micro-logic control to a printer with no electronic interface .•. and a disk pack control. It can AADC configurations? I would assume you're asking about the multiprocessor, in particular.
163
-Nimensky: I think SPL has all the potentials. For parallel processing, it has job to recognize parallelism?
O'Brien: Right now, the existing CMS-2 will not, but we're in the process of processor ••. the Matrix-Parallel Processor •.. then there is the multiprocessor portion, which might take a long program, segment it, and operate on the two
Bersoff: That's what SPL has wi~-h-the_ir "parallel" and "Join" operations.
McGonagle: We had a problem with it, in ~hat we found ~~st programmers tended not to use it. The difficulty is not in using the parallel path, but in creating the monito."' functions which adequately describe the relationships between parallel prucessors. Apparently, there's very little research being done anywhere in the country on parallel process structure.
languages and extract from them their parallel paths. That has only been current sequential languages he describe.s data structures and he describes computations. You get a little bit on control over how things get executed dependent and must be done sequentially. Taldng that information .•. the infor-mation about all the space that's needed by each task and so on, it's possible
-Cerf: Second, you need to have considerable more control over the scheduling of ---t-asks if we're going to write programs which are suitable for a multiprocessor
configuration. I don t necessarily advocate a whole control sublanguage, although that happens to be my opinion at the moment. So, I think that's missing. And, finally, I think we need to be able to write something like an operating system in the language, whatever it is, because if we want to have re-structurable computers, things that degrade nicely and understand what's going on about them, we re going to need to write some sort of operating system for building the operational systems, the compilers, the intelligence, the people who built these compilers. For instance, Logicon has built a CLASP
-Floor (Capt. R. Dunning): I don't think I quite agree with you in the Navy.
1&1-circumvent the problem Ed and I have been buried up to our eyeballs in, trouble with your program maintenance. Provided this is reduced, however, using the Meta Compiler technique ••. may I hear some comment on that.
Engelbach: Well, you derive using a production tool, it's just like automating and producing hardware ••• uniformity of products. I didn't say standardi-zation. Uniformity across products and from product to product, which is
Cerf: What's the advantage of that over the conventional bootstrapping tech----n-ique of moving it through a higher level language?
Engelbach: You're actually moving the tool that constructs the compilers, as well as the compiler itself. You're not bootstrapping the compiler, you're bootstrapping the Meta Compiler.
168
-Shirley: You made a point which I think is very important to all of us, which was that the chances the compiler comes out somewhat different in this sit-uation has been proved; In other words, it is not as likely to come up different as it has in the past ••• Eventhough you're using the same tools, it's not clear if you're going to really be right ••• that you're still not going to get a different compiler at that point.
Engelbach: Let me put it this way, if you had a code generator for a given machine, and one section of the Government, me, I will have a" code generator for the 6600 Scope 3.2. If the Navy had been able to reconcile itself to using the Meta tool, then I would be very surprised if they just didn't take my code generator and use it rather than duplicating the code generator.
It exists. Just plain use it ••• ln that sense, not only would we have uni-formity, it would be identical ••• The uniformity of the tool not only helps us in this case, but if they use the tool and build a code generator for the ANIUYK 7 or the AADC, and if I should pick up the hardware, either of those machines, I would of course pick up their code generator because, of course, I'm not going to do it. The uniformity I gain is, if we're both using the same tool, the front ends are going to be the same. The syntax analyzers are going to be the same. The semantics that you brought up earlier are going to have a high probability of being more similar because
I now can constrain not only the interpretation of the semantics of SPL or CMS-2' into a binary form for a particular piece of hardwareJ but I also
have a framework in which to perform that transla~ion process. That frame-work would be the code generator language of the SPLIT tool ••• if you build a code generator for the 6600, when you are building a code generator for a machine of a very similar nature, the 6400, the 6000 Series, the similar-ity not only in the syntax, the front end, but the semantics, the part the code generator produces, will be ••• let's say, there would be a higher probability of their being similar. The interpretations would be made (in) the same (manner), enhancing, in the long run, the problem of portability.
Bersoff: I think we all agree that we should have compatibility. I think we ought to go back and do it. Thank you,
-~-THIS PAGE IIrENTIONALLY IUT BLANK
170
-Panel *2
Subj ect : Computer/Compiler Standardization Chairman: Dr. Bruce Wald
Naval Research Laboratory Panelists: Mr. Alan Deerfield
Raytheon Corporation Mr. Vi Henderson Logicon Corporation Mr.
J.
David McGonagle Burroughs Corporation Mr. Robert SamtmannNaval Air Development Center