phipps@garth.UUCP (Clay Phipps) (12/02/88)
In article <311@csun1.UUCP> weyrich@csun1.UUCP (Orville Weyrich) writes: > >...a neglected aspect of programming >language development and language standardization: >defining standard and useful interfaces *between* languages, >so that for example new code in modern languages >can be smoothly integrated into old programs written in old languages >without the need for massive rewrites. >... >It *must* be easier, faster, and more cost-effective >to define linkage between say FORTRAN and Ada than it is >to redefine FORTRAN to have most of the features of Ada... There was an interesting source-level mechanism reported from Carnegie-Mellon U.: William A. Wulf: "The Problem Of The Definition Of Subroutine Calling Conventions", _SIGPLan Notices_, 1972 December, p. 3..8. It was intended to allow definition of machine-level information on routine invocation mechanisms from BLISS source code: LinkDecl ::= "linkage" Id "=" LinkType "(" ParmSpecs ")" LinkType ::= "BLISS" | "FORTRAN" | "interrupt" | ... ParmSpecs::= ParmSpec | ParmSpec "," ParmSpec ParmSpec ::= Id | "stack" | "register" "=" RegId RegId ::= /* the paper provide only for a "number" */ They gave the example: begin own X; linkage BrX = BLISS (register = 2, X, stack); routine BrX R (A, B, C) = begin ... end; ... R (3, 4, 5); ... end; in which A will be found in register 2, B will be found in the global variable "X", C will be found on top of the stack. I don't know whether it became a conventional part of BLISS. Wulf attested to the high value of the scheme, but regretted the lack of a more complete solution. He concluded that he assumed that "the solution lies in getting an adequate characterization of ... the (rather vague) notion of `environment' explicitly into the language, together with primitive operators for its manipulation". Now if only the standards committees for languages like FORTRAN, Pascal, C, &c. would translate something like this into idioms that fit those languages. I can dream, can't I ? As an alternative, each could define a "transmitter" feature (a concept that originated in SL5, I believe). One drawback is that you might need to write some of the transmitters in assembler :-). The widespread postings to language news-groups were to get everyone's attention; follow-ups might best be limited to "comp.lang.misc". -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps
campbell@redsox.UUCP (Larry Campbell) (12/04/88)
In article <2086@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: }There was an interesting source-level mechanism reported }from Carnegie-Mellon U.: } } William A. Wulf: } "The Problem Of The Definition Of Subroutine Calling Conventions", } _SIGPLan Notices_, 1972 December, p. 3..8. } }It was intended to allow definition of machine-level information }on routine invocation mechanisms from BLISS source code: ... description of syntax omitted ... }I don't know whether it became a conventional part of BLISS. It did become part of the BLISS in use at DEC. On the VAX there are only two styles of subroutine call, but on the PDP-10 there were literally dozens, plus system calls implemented by illegal opcode traps. The BLISS compiler on the PDP-10, BLISS-36, had built-in subroutine linkages for the system calls and the more common subroutine calls. You could also, of course, define your own linkages for interfacing with funky old code. BLISS is an interesting language that has received less attention than I think it deserves. Unfortunately, only CMU and DEC ever did much with BLISS, as far as I know. If you read any BLISS literature you should be aware that DEC has added *lots* of enhancements to the language. The first BLISS compiler, BLISS-10, was originally designed for the PDP-10 and had lots of PDP-10-isms wired into it. CMU also did a PDP-11 version that was quite different. DEC essentially merged the two, added a powerful macro preprocessor, a condition handling facility, and other features, producing what is, in my opinion, a very nice language for implementing machine-dependent code (device drivers, operating system kernels, etc.) -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
henry@utzoo.uucp (Henry Spencer) (12/06/88)
In article <2086@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: > [BLISS linkage control] >Now if only the standards committees for languages like FORTRAN, >Pascal, C, &c. would translate something like this into >idioms that fit those languages. I can dream, can't I ? More like a nightmare. Standards committees are not in the business of doing this sort of thing without prior experience in real implementations. When they do, the result is usually a dreadful botch. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bobd@ihf1.UUCP (Bob Dietrich) (12/14/88)
In article <2086@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >Wulf attested to the high value of the scheme, >but regretted the lack of a more complete solution. >He concluded that he assumed that "the solution lies in getting >an adequate characterization of ... the (rather vague) notion >of `environment' explicitly into the language, together with >primitive operators for its manipulation". > >Now if only the standards committees for languages like FORTRAN, >Pascal, C, &c. would translate something like this into >idioms that fit those languages. I can dream, can't I ? A couple of things I might point out. The first is that language standard committees have their own "turf"; their charter usually precludes them from addressing areas other than the language at hand. This has it's good and bad points. I don't want a language committee dictating what characteristics the linker (if there is one) and the rest of the environment must take on, although it might define certain minimal requirements. If you've ever considered implementing something like fork() on a non-operating system like DOS, you wouldn't like to be forced in that direction by a language standard either. The second point is that there is at least one international committee (one of the ISO Working Groups in the range WG10..WG12) that is working on these isssues. I'm too lazy to look up which one it is. There may also be an American committee, but I'm not sure. > >The widespread postings to language news-groups were to get everyone's >attention; follow-ups might best be limited to "comp.lang.misc". They have been. > >Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps usenet: uunet!littlei!intelhf!ihf1!bobd Bob Dietrich or tektronix!ogccse!omepd!ihf1!bobd Intel Corp., Hillsboro, Oregon or tektronix!psu-cs!omepd!ihf1!bobd (503) 696-2092