Conference azur::mcc

    ADA is discussed in a previous note. I will summarize but please check
    since my memory isn't as good as it used to be. ADA requires a rich
    run time environment/library and would require extensive integration
    work to be sure that DECmcc components which run in that environment
    interface will with other DECmcc components which run in the DECmcc
    environment. While theoretically it could be done, we have a small
    handful of customers that have expressed an interest.
    
    No real analysis is currently planned to supporting ADA. Yes, there
    may be something that says ADA in the library, but it probably got
    pulled in with something else that has some obscure dependency on
    it. There is no explicit plan to support ADA. If someone who is more
    knowledgeable can do some experimentation and reduce the effort to
    a no-brainer we would obviously follow through with it to please a
    customer but if the requirement is put on the DECmcc group, we are
    not likely to do it justice because we are all C hackers with a
    sprinkling of Pascal and Macro types. I doubt that we have the
    right expertise to tackle this.
    
    wally

    Yes,
    
    It is _possible_ to write AMs in Ada.
    
    There are a few of problems with doing this:
    
    1 There are no Ada bindings for the MCC system routines or data types.
      Developing this is several months of effort, and it really needs to
      be done by someone close to the MCC group, in order to track
      MCC development. The Toolkit design framework seems, from a quick
      review, to be similarly interfaceable to Ada as a package.
    
    2 It's necessary to create an 'envelope' that munges the parameter
      passing to comply with Ada's requirements, but this is easy.
      I have a Macro file with some Macros in it.
    
    3 Using any of Ada's tasking will almost certainly break MCC's threads.
      This is the only real restriction with Ada's run-time support
      aside from the language-independent items mentioned in the SRM.
    
    4 There will probably be some differences between VMs and the call
      mechanism between MCC and Dec Ada on Ultrix (Once the mcc_call interfacing
      is sorted out, Ada AM's should be just as readily portable between
      platforms than C ones, possibly even more so.
    
    Having said this, I have written a very small and useless AM
    to test the interfaces between MCC and Ada. I'm happy to
    provide a copy of this and comments on the efforts involved
    with Ada under MCC. My AM just registers Widgets, for display
    in the Iconic map. It works on VMS MCC V1.1, but has not been
    rigorously tested. I wrote a package defining Ada types and
    importing MCC system routines as I required.
    
    Yes, I use the *_ADA_*.EXE file in the library. It seems to work.
    I have a .CLD file defining additional options for the /LANGUAGE=x
    option available with the MCC/TOOLKIT/SPEC command. It produces
    a set of Ada constants in an Ada package.
    
    I will clean up the code some time in the next week,
    and post a note for any interested parties.
    
    Regards
    David Moss
    

  Hi,

  I work at the Customer support center supporing Ada on VMS... I've
  been working with a customer trying to use DecMCC with Ada.  I
  thought it may be worthwhile to note some of our "discoveries".

  I know little to nothing about MCC, so please excuse the ignorance
  in that area.

  1) Currently (as noted in .2) an "intermediary" is needed between
     MCC and Ada, at least when MCC calls Ada.  MCC passes most parameters
     by value, Ada doesn't.  So you need an interface routine between them,
     Macro or C will work, or any language that will let you pass/accept
     parameters by value.

     My understanding is that DEC Ada on Ultrix will let you specify
     passing mechanisms when "importing" a subroutine.  If/when this is
     the case with DEC Ada on VMS, this interface will no longer be
     necessary.

     When Ada calls MCC routines, this intermediary routine is not
     necessary because Ada allows you to specify passing mechanisms
     when "importing" external routines.

  2) If using object libraries, there is a "restriction" with Ada.
     Ada has what is known as "elaboration code", this elaboration
     code is put in a separate module.  The problem occurs because
     there is no reference to this elaboration code module in the
     "actual" code, so it does not get pulled into the linked
     shareable image.

     (The example documentation for creating the shareable image for
     MCC uses object libraries for the C code.)

     If you're using object libraries, you will need to explicitly
     include this module (/include option), or just link to the object 
     file(s) instead of putting it in an object library.

     See TURRIS::ADA notefiles note #2341 for more info.

  3) When calling MCC routines, be aware that Ada uses COPY-IN/COPY-BACK
     semantics alot when passing parameters.  This means a temporary
     location is created for the parameter, the actual parameter value
     is "copied into" this temporary (if an input parameter) before calling
     the routine, and "copied out" from the temporary back to the actual 
     parameter (if an output parameter) when leaving the called routine.
     It is the address of this temporary variable that is passed to the
     routine as the actual parameter.

     In our case, it caused problems with the tables used by MCC.
     The table is described as an unsigned_longword passed by reference,
     but was actually a variable-length structure much longer than
     four bytes.  Because only 4 bytes of information was copied to
     the temporary location, the rest of the "table" was garbage to
     the MCC routine, so the routine failed.

     To get around this... such structures should be set up to be
     an address passed by value rather than a longword (or whatever)
     passed by reference when describing the interface in Ada.


  I hope this helps someone else along the way.

    Janet.

I don't know much about ADA, but I found problems in trying to use the
VMS debugger on some modules we have written in VAX SCAN language.  ADA
users might anticipate the same difficulties.  (Although if the multi-
tasking portions of ADA are off-limits anyway, maybe the debugger extensions
we couldn't use would not matter.)  The DEBUG people are aware of the
problem, and may fix it in the future.  And a work-around exists, if
you can get the DECmcc folks to give you a specially linked MCC_MAIN image.
For more info, check my notes in the VAX DEBUG notes conference in the
Nov-Dec-1991 timeframe.

-Dave

    For anybody who wants a copy of my useless Ada AM, copy
    
    	STURT::DKA300:[MOSS]WIDGET.SAV
    
    It is complete, with MMS and COM files to do the work of building.
    As Janet discusses, there is an 'envelope' between the MCC code
    and the Ada code to adjust parameter passing.
    
    Because of project commitments, I can't offer any support or spend
    any more time in development, but I'd appreciate a mail
    message if you do take a copy.
    
    David
    
    (You may even have a use for the widget icons for some other AM :-)