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
phipps@garth.UUCP (Clay Phipps) (12/22/88)
In article <473@ihf1.UUCP> bobd@ihf1.UUCP (Bob Dietrich) writes: >In article <2086@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >>Wulf attested to the high value of the [CMU linkage declaration for BLISS] >>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". >> >>...if only the standards committees for languages like FORTRAN, Pascal, >>C, &c. would translate something like this into ...those languages... > >...language standard committees have their own "turf"; >their charter usually precludes them from addressing areas >other than the language at hand. My suggestion to incorporate linkage declarations doesn't violate any turf any more than defining the "register" declaration for C does. If the committee charter limits its task to cleaning up, but not extending, the definition of the language, there isn't much I can do. >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. For probably any machine architecture, some combination of linker designers, compiler writers, and OS gurus design and implement the support provided by the OS, linker, and compiler for passing data around on a routine call (or other context change). As many of us are aware, individual choices are often made for various reasons by compiler writers that result in making their compiler incompatible with other compilers *for the same combination of hardware, OS, and linker*. Their alternative may be to impose a performance burden on one or more compilers for the sake of guaranteeing compatibility. After the machine begins shipments, there may even be a comfortable feeling that whatever incompatibilities exist will not be a problem in practice. Then in comes some marketeer with a customer that will hand over big bucks if only their big application, e.g., written primarily in Pascal, relying on FORTRAN math libraries, and accessing a data base server written in C, can be ported to our[*] machine. Another fine mess ... My particular concern was being able to describe *existing* linkage conventions, i.e., those already available in some compiler *for the same combination of hardware, OS, and linker*, when attempting to use routines written in different languages that call each other. Thus, the linker designers retain their freedom to determine linker and environment characteristics. My intent was not that all compilers be required to support all possible linkage mechanisms on all possible systems. A standards committee *would* need to devise a framework that covers linkage conventions used by members of its committee. It seems far better to me, that the standards committees lead the way than, as I understand recently occurred for Extended Pascal, for the committee to try (and fail) to reach a consensus among members who independently implemented a popular feature ("include files"), leaving it unstandardized for not just 1, but 2, standardization cycles. >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... My idea was to describe linkage that is already implemented, not to create language features as a substitute for absent OS features. The problems of arbitrary protocols, which was, perhaps, the reason for mentioning "fork", could be handled by a mechanism to name a transmitter routine, in the sense of Icon (or was SL5 first to have the feature ?). Let some OS guru write a transmitter routine to do the messy work. A transmitter might also be the best approach to allowing non-C calls to C routines expecting "varargs" parameters. The ambitious idea about manipulating environments was Wulf's, not mine. I incorporated them in the original posting because I considered his evaluation of his own (or own group's) features to be relevant, especially in terms of how effectively they resolved the problem in question. [*] The marketing situation described herein is hypothetical; any relation to actual marketing situations is purely coincidental. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800