[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::languages

Title:	Languages
Notice:	Speaking In Tongues
Moderator:	TLE::TOKLAS::FELDMAN

Created:	Sat Jan 25 1986
Last Modified:	Wed May 21 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	394
Total number of notes:	2683

75.0. "?Can your language do this?" by SYBIL::FRANTZ () Fri Dec 06 1985 16:59

   Hello DEC-Language-World,

   We're working on a yet-to-be-announced product and have a question
   directed to all the "compiled" languages on VMS. 
                              
   I won't bore everybody with the gory details of the problem. What
   I'd like to do is check to see if a contemplated solution will work
   for all compiled languages that might call this product. If it
   won't, maybe I'll come back and bore you.
   
   The question is: 

        Does your VMS languages allow references to "external tables"
        in a parameter list? Even more restrictive, this external
        table would be defined only in an .OBJ file in an .OLB
        (namely, STARLET). 
        
        Specifically, we're considering something suggested by the
        following: 
   
	   	EXTERNAL INTEGER PRODUCT$ABC
   		...
	   	CALL PRODUCT$QQSV( %REF PRODUCT$ABC, other_parameters...)
   
        Routine PRODUCT$QQSV is in a shareable image and PRODUCT$ABC is
        a magic module that must be linked with the user's image.
        (PRODUCT$ABC is the means of getting at certain information in
        the user's image -- the user's image may be only executable,
        not sharable, so we can't use find_image_symbol.) 
   
   I know you can do it in FORTRAN, BASIC, COBOL, PASCAL, PL/I, C, and
   BLISS, thereby covering our most popular languages (not to mention
   our most unpopular one). I also know you can't do it in LISP and
   APL, but that's okay, too (interpretive systems have special
   problems). 
   
   I don't need a "yes" from anybody, just a "no" in case your language
   can't do this sort of thing.

   Thanks for your help.

   Dan Frantz
   Project Leader of Aforementioned Unannounced Product

T.R	Title	User	Date	Lines
75.1		SPEEDY::BRETT	`Fri Dec 06 1985 19:49`	50
	Yes and No. I presume what you are trying to REALLY do is put the value of a global symbol in the parameter list. What you describe in .0 is a hack to do this in (FORTRAN?, or some made up language?) What you are really asking for then is... external PRODUCT$ABC pushl other-args pushab G^PRODUCT$ABC calls #n, ROUTINE Yes, you can get this affect in VAX Ada, but not at all using the mechanism you describe. Using your proposed mechanism a copy of the 32 bits starting at PRODUCT$ABC would be moved to a stack temporary, and the address of this stack temporary passed in the parameter list - not at all the affect you want. The way you would do it is... with SYSTEM; package MUMBLE is type UNKNOWN is limited private; PRODUCT_ABC : UNKNOWN; pragma IMPORT_OBJECT(PRODUCT_ABC, external=>"PRODUCT$ABC"); procedure ROUTINE(TABLE : SYSTEM.ADDRESS, ...); pragma INTERFACE(PRODUCT_ABC, ROUTINE); pragma IMPORT_PROCEDURE(ROUTINE, mechanism=>(VALUE,...)); private type UNKNOWN is SYSTEM.UNSIGNED_BYTE; -- Who cares! end; with MUMBLE, SYSTEM; procedure ... is begin ROUTINE( PRODUCT_ABC'address, ... ); end; As you can see, Ada is explicitly designed to make hacks like the one you describe difficult, and to force you to state EXACTLY what you intend in such cases. /Bevin VAX Ada
75.2		DSSDEV::FRANTZ	`Sat Dec 07 1985 11:59`	14
	Bevin, Thanks for the reply on ADA; that's quick service. Yes, what we really want is the address of the global symbol in the parameter list. I think the semi-syntax I suggested is a combination of how it's actually done in FORTRAN and BASIC. (Please, you FORTRAN and BASIC users, don't beat me up if I got it wrong.) All I really need to know is if it's possible, hackishly or not in our old fashioned and new fashioned languages. I guess I'm not surprised ADA lets you state exactly what it is you want. Dan
75.3		DSSDEV::FRANTZ	`Sat Dec 07 1985 23:34`	9
	In response to a kindly worded mail message, I'd like to make a comment to head off anybody who thinks we might be slighting the interpreted languages. We're doing this as part of an effort not to slight them. Currently LISP and APL have trouble calling an announced product, FMS, because of a similar architectural problem. What we're trying to do is avoid the same problem for a new product. The interpreted languages would not have exactly the same functionality as the compiled languages, but they would be able to use 99% of the important part of the product (which they can't do now with FMS).