🚀 go-pugleaf

In article <11401@bloom-beacon.MIT.EDU>, tada@athena.mit.edu (Michael Zehr) writes:
> 
[...]

> 
> Someone also mentioned being able to reuse components in different
> languages.  I agree that this is crucial in combining efficiency with
> productivity.  So far, my experience with mixed-language coding is
> that it is very easy on Vaxes (becuase of the forced procedure
> interface of the CALLS instruction) but extremely difficult on IBM
> mainframes (because there is no standard calling sequence).  Does
> anyone have any experience in mixed-language coding on newer RISC
> machines?  Do compiler witers stick to "standardized" calling
> mechanisms?
> 
> -michael j zehr

Silicon Graphics uses RISC processors from MIPS (first workstation to do so).
Fortran can call C and C can call Fortran.  (and C++, and Ada, and Pascal)
It's done all the time.  Our Graphics Library works that way.  Not only that,
but the Graphics Library uses a shared library mechanism which allows
executables to run on machines with different graphics hardware without
recompiling (again, first (and only?) workstation to do so).

thant@sgi.com "don't quote me, they're not paying me for that"

From tada@athena.mit.edu (Michael Zehr):
> There have been a couple of good comments about using software
> components, but so far most of them have been along the lines of
> "such-and-such a language does this."  Could you describe
> *how* the language provides both efficiency and quick building time?  
> 
> For example, one person mentioned Ada's "re-binding" of
> executables.  What does this do?  

    Briefly, Ada provides a number of excellent facilities for
    partitioning a problem into modular subsystems, in order to
    facilitate the construction of the subunits in an independent
    manner.  One such facility is known as "separate compilation",
    whereby first the interface to a procedure or function is described:

      procedure Handle_This_Task (With_Parameter : in out Parameter_Type)
         is separate;

    Now we can compile the code which contains this specification 
    without ever actually implementing the Handle_This_Task procedure.
    Eventually, before we bind everything into an executable, a procedure
    must actually be coded to satisfy this specification, but we can 
    defer it until the rest of the code has been written and debugged.
    Moreover, if we wish to change something in that procedure's code,
    we can change and recompile only that procedure, without having to
    recompile the entire system.

    Another mechanism is the "package".  One use of packages is to
    describe specifications (*compilable* specifications) for subsystems
    which collectively interact to form a larger system.  Once the
    high-level specifications have been compiled together, the information
    flows across the subsystem interfaces have been verified for completeness
    and consistency.  The project can then be "farmed out" to individual
    programmers, who will implement each subsystem independently of what
    everyone else is doing.  The package specification forms a contract
    between the implementor and the other project members; if everyone
    fulfulls their end of the deal, then the entire system is guaranteed
    to work as far as information flows are concerned.  The implementor
    constructs a package body, which is said to be "compiled against" the
    package specification, or "spec".  So everyone goes about their
    business, implementing and testing their individual subsystems, 
    (testing of subsystems can be accomplished by first developing them
    in temporary isolation from the system, and later compiling them 
    against the system specs) and finally when everyone is done, the 
    compiled units are *bound* together into an executable for integrated
    testing.  Now suppose that a problem is found in one subsystem.  That
    problem is corrected, and only that subsystem (and possibly only a
    small portion of that subsystem, if the subsystem has been internally
    partitioned as well) will require recompilation.  Once the affected
    area of the system is recompiled, then the system is bound once again
    into a new executable for further testing.  The technical mechanism by
    which this is accomplished is known as the "library" system; each program
    is a member of some program library or sublibrary, and when a program
    (or "program unit", or "unit") is compiled into a library, the library
    stores some intermediate form(s) of the program.  Upon recompilation,
    the library simply updates its intermediate form(s).  If there is an
    optimization flag turned on, then the library stores special information 
    which will be used by the optimizer during the binding phase.  Now when 
    binding occurs, the binder scans through the libraries for the desired
    program units, and binds them together into a piece of executable code,
    perhaps exploiting the knowledge accumulated during the compilation
    phase in order to optimize the executable code.  Although packages 
    present boundaries to the programmer, an optimizer can corrupt any and 
    all boundaries in pursuit of a more efficient executable, if global 
    optimization is desired.  Normally the work of optimization is not
    done until very near the end, during or after execution profiling. 

    The library system is also important in that it permits the reuse of
    code (a software component needs to be compiled into only one library,
    and many other users can then make use of it); it also facilitates
    the tracking of the impact of a modification, in that a change in the
    specification of a component which is used by other users will require
    the recompilation of the relevant areas of code which made use of the
    modified unit.  This enables the rapid identification of the impact of
    the modification, and allows the tracking of change as it spreads 
    throughout the system.  There is an automatic recompilation facility 
    which can be used to automatically recompile all dependent units if it is
    known that the change will not require changes to the dependent units;
    automatic recompilation will also identify (in the form of compilation
    errors) specific places in which the modified specification impacts the
    dependent units (e.g., a dependent unit's attempt to call a procedure
    which was just removed from the specification).

> Someone also mentioned being able to reuse components in different
> languages.  I agree that this is crucial in combining efficiency with
> productivity.  So far, my experience with mixed-language coding is
> that it is very easy on Vaxes (becuase of the forced procedure
> interface of the CALLS instruction) but extremely difficult on IBM
> mainframes (because there is no standard calling sequence).  Does
> anyone have any experience in mixed-language coding on newer RISC
> machines?  Do compiler witers stick to "standardized" calling
> mechanisms?

    Ada makes direct provision for interfacing to other languages; 
    the only implementation dependencies are whether or not the
    compiler you are using supports calls to that particular language.
    Typically, compilers support calls to at least several other 
    languages, and the means of use is via the standardized 
    interfacing mechanism defined by the Ada programming language.
    Special provision is also made for machine code insertions;
    as with interfacing to other languages, there is direct support 
    for machine code insertion in the Ada language, and the only
    question is whether the particular compiler you are using 
    provides the service.  Although the compilers are not required to
    provide machine code insertion either, many if not most of them do so. 

  
    Bill Wolfe, wtwolfe@hubcap.clemson.edu

In article <11401@bloom-beacon.MIT.EDU> tada@athena.mit.edu writes:
+---------------
|            ... So far, my experience with mixed-language coding is
| that it is very easy on Vaxes (becuase of the forced procedure
| interface of the CALLS instruction) but extremely difficult on IBM
| mainframes (because there is no standard calling sequence).  Does
| anyone have any experience in mixed-language coding on newer RISC
| machines?  Do compiler witers stick to "standardized" calling
| mechanisms?
+---------------

One of the things AMD tried very hard to do with the Am29000 RISC CPU
was to try to define a single subroutine calling sequence that *at least*
C, Ada, Pascal, FORTRAN, & COBOL could live with. This required some
tradeoffs, since each language requires slightly different environments
around a subroutine call (especially Pascal/Ada "displays").

The compromise reached was this: The C calling sequence is the base set,
and the most efficient. For the C linkage, "live" values in the "local"
registers (gr128-gr255 == lr0-lr127) are callee-saved (by opening a new
register-window context), whereas values in the "global" registers (gr95-127)
are callee-destroyable. Specific additional inter-module resources are
allocated in the global regs for other languages, but any "live" values
in these resources are *caller*-saved, though passed to the callee.

So, as a specific example, if a Pascal routine makes a call, it puts the
"display" pointer in a known global, which is used by a Pascal sub-routine
but (probably) destroyed by a C subroutine (which could care less about
displays). Compilers which are smart enough to do minimal inter-procedural
analysis can avoid saving/restoring these additional resources if the calls
from a given routine are all to compatible sub-routines, and emit the save/
restore code if not.

It seems to have worked. There was a lot of grumbling from the Ada vendors
(they wanted *lots* more "preserved" globals!), but reasonably efficient
mechanisms were worked out. [AMD has an app note available on the "Am29000
Standard Subroutine Calling Sequence", if anyone cares for more details.
Call your salescritter, not me...]

To date, there are 5 C compilers [soon 6], 2 Ada's, a Pascal, and [I think]
a FORTRAN and a COBOL, from various 3rd-party vendors, all of which use the
same calling sequence and which can interoperate [within the restrictions of
the environments... that is, it's easy to call C from Ada, but to go the other
way you have to go through a library routine to set up the Ada environment].
They all use the same COFF file format, too.

So, yes, the benefits obtained from things like the VAX "CALLS" can
be attained in the RISC world, but the discipline has to come from the
software, not the hardware. [Which is not surprising, considering the
general RISC philosophy.] And I think most of the current RISC chip
vendors are aware of this...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403

In article <5490@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

   Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
   Lines: 108

   From tada@athena.mit.edu (Michael Zehr):
     There have been a couple of good comments about using software
     components, but so far most of them have been along the lines of
     "such-and-such a language does this."  Could you describe *how*
     the language provides both efficiency and quick building time?
     For example, one person mentioned Ada's "re-binding" of
     executables.  What does this do?

	... many good descriptions of separate compilation ...

       Another mechanism is the "package".  One use of packages is to
       describe specifications (*compilable* specifications) for
       subsystems which collectively interact to form a larger system.
       Once the high-level specifications have been compiled together,
       the information flows across the subsystem interfaces have been
       verified for completeness and consistency.

this `checking for completeness and consistency' is actually nothing
more than a static type check.  since in a large application, the
constraints on the interface between packages is considerably more
complex than just having the communication merely be of the correct
type, this should not be characterized as a full verification.

	... more good comments are modular development ...

       The package specification forms a contract between the
       implementor and the other project members; if everyone fulfulls
       their end of the deal, then the entire system is guaranteed to
       work as far as information flows are concerned.

again, this checking is far from complete (as it must be at the
current state of the art).  satisfaction of the type constraints is a
BIG step along the way toward making things work smoothly, but there
are an enormous number of constraints in a real program that cannot
reasonably be expressed as type constraints.  some, such as the sum of
the squares of the first two arguments is greater than the square of
the third, could be effectively checked by assertions.  other aspects
of the interface cannot even theoretically be checked by a compiler
(such as the values returned by a function will be returned with 10
ms. of a call).

again, type checking is almost always a GOOD THING, but it is also
almost always not enough to verify that the communication between
parts of programs are correct.

	... more good comments about the benefits of libraries and
	separate compilation ...

   Someone also mentioned being able to reuse components in
   different languages.  I agree that this is crucial in combining
   efficiency with productivity.  So far, my experience with
   mixed-language coding is that it is very easy on Vaxes (becuase
   of the forced procedure interface of the CALLS instruction) but
   extremely difficult on IBM mainframes (because there is no
   standard calling sequence).  Does anyone have any experience in
   mixed-language coding on newer RISC machines?  Do compiler witers
   stick to "standardized" calling mechanisms?

	... good stuff about the ada party line ...


----------------------------------------------------------------

and now for the view from the rest of the world.

type checking is a good thing.  separate compilation is a good thing.
libraries and linkers that understand type checking are a good thing.

none of these are particular to ada.  some or all of these can be
found in ansii c, commercially available pascals, c++ and other
languages.  some of these solutions are partitioned differently from
the way specified by ada orthodoxy, often with the result of more
flexibility.  this is the case with make.

one place that most of these tools fall down at the current time is
with program generators and preprocessors.  the requirement that we
specify interfaces completely in terms of base language leads to very
serious awkwardness if when we try to replace the functionality of
yacc or make heavy use of precompilation as do the internals of the
gnu c compiler.

the failure of tools in the face of language extension is an issue
that has been long recognized in lisp circles.  only recently are
conventional languages being used (and shown insufficient to the task)
in such advanced applications.  a serious case in point is the x
toolkit as implemented in c.