Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!amdcad!rpw3 From: rpw3@amdcad.AMD.COM (Rob Warnock) Newsgroups: comp.sw.components Subject: Re: using components Message-ID: <25643@amdcad.AMD.COM> Date: 16 May 89 04:21:13 GMT References: <11401@bloom-beacon.MIT.EDU> Reply-To: rpw3@amdcad.UUCP (Rob Warnock) Organization: [Consultant] San Mateo, CA Lines: 59 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