Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[gwinn@ma.ultranet.com (Joe Gwinn)]

In article <1998Apr10.073110.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote:

> In article <gwinn-0904982253200001@d183.dial-5.cmb.ma.ultra.net>,
gwinn@ma.ultranet.com (Joe Gwinn) writes:
> 
> > detail.  It sounds like you are calling Ada from C; this is difficult to
> > impossible with Ada83, and better with Ada95, but is often tricky.  Ada83
> > really expected to be on top, to be the main(), and it was often easier to
> > call C from an Ada main than to call Ada from a C main.  
> 
> Those limitations regarding which language was used for the main program
> may be true for some particular Ada83 implementation with which you are
> familiar, but they are not a characteristic of the Ada83 language itself.
> One problem I have heard discussed here is "elaboration", and DEC Ada for
> VMS has always done that via the LIB$INITIALIZE mechanism of the operating
> system, without requiring the main program be written in Ada. (There was
> a bug 10 years ago when sharable images (DLLs) were used, but bugs are bugs.)
> Since LIB$INITIALIZE is an "obvious" capability of the operating system,
> presumably GNAT for VMS either does the same obvious thing with LIB$INITIALIZE
> or does something different which also works, but at any rate does not ignore
> the issue.

Even under VAX/VMS in the 1980s, it wasn't so easy to call Ada from C.  I
know because we did just that.  There was a way to declare an Ada function
as being called from non-Ada; this worked and we used it, but you lost
much of the Ada environment.  

Actually, we were implementing an object-oriented communications 
system able to handle the full bandwidth of a large intelligence radar in
Ada83 on VAX 8600s, and we used these non-Ada Ada functions as the OO
methods, using a special assembly-coded invoker to call them by address
(vice name).  To get Ada83 and VMS to run that fast on the hardware of the
day was quite the trick, requiring special kernel calls plus a
shared-memory message passing infrastructure.  DEC Ada83 didn't handle
shared memory at all well, so we did an elaborate fan-dance so she never
saw memory she didn't completely own - her eyes were covered whenever we
needed to violate the closely-held assumptions of her upbringing. Sort of
like when your mother covered your eyes so you wouldn't see something on
the TV, because she didn't want to deal with the nightmares.

Ada95 should allow one to do without such hacks, but it still isn't
totally smooth, but the multiple-language problem isn't restricted to Ada,
and never was.



> > C may well not be setting the stack and registers up to Ada's liking.  Or
> > vica versa. 
> 
> This also should be a non-problem if the operating system (like VMS) mandates
> a calling standard.  On less organized operating systems you may survive
> by buying all your compilers from the same source.  Perhaps the main
> advantage of Ada95 is that it forces compiler developers to do the right
> thing, rather than trusting them :-).

This was one clear advantage of VAX/VMS in its day, but few other vendors
did any such thing.  Under VMS, there was one common subroutine calling
convention, so calling one language from another was much easier than
normal.  

That said, we used to call all manner of languages one from another,
sometimes directly, and sometimes by means of little assembly-coded
wrappers ("bindings" in modern jargon), on all manner of computers.  Ugly,
but effective, so one didn't choose platforms just for the ability to call
one language from another.


Joe Gwinn