carmi@ipla01.hac.com (Aviram Carmi) (03/19/91)
The following are the responses that I got about my query on calling C from Ada. Thanks to all those who replied. Since getting an Ada compiler for our system was too expensive and most of the code will have to be written for the hardware in C, we decided to abandon the Ada simulation in favor of C. ----------- From: emery@d74sun.mitre.org (David Emery) I'd refer you to my paper in Tri-Ada 90 (last December) on my prototype implementation of the POSIX Ada binding. In many respects, that paper is a tutorial of techniques I've used to interface Ada to C. However, most stuff in this area is very compiler-specific, so "your mileage may vary." In a nutshell, you have to carefully define Ada analogs to the C typedefs (using records mostly), and pass scalars (int, in C parlance) by value and other things via the 'ADDRESS attribute. You'll have to implement macro expansions by hand, usually via a procedure with PRAGMA INLINE applied. dave emery emery@aries.mitre.org ----------- From: lewin@rocket.sanders.com (Stu Lewin) Avi, I did this for suntools (sunview?) bindings a bit ago, and found that you can use constants and in-line subprograms for what you need. Mostly it's just a question of providing the types and pragma INTERFACE to the all the library routines. However, I ended up having to have one C file I wrote which did nothing other than expand a few macros to get some routines that I could then pragma INTERFACE to. If you need more specifics I suppose I could send you one or two of the interface files and if you have access to a Sun you could look at the mapping between them. Dave Emery did a paper for TRI-Ada this year about bindings that summed up lots of the experiences that people have had at various times while trying to do this (his particular experience was with the POSIX bindings I believe). You could also try looking at some of the old ada-x messages, as this is the most common topic of discussion on that list. It's all pretty much the same process again and again (I've done bindings for X, SunCore, sunview, the SPARC audio device, and a few other random "standard" interfaces). Once you learn the tricks, they're all the same. Stu Lewin Lockheed Sanders, Inc. Ada Projects Leader PO Box 868, MER24-1583C Signal Processing Center of Technology Nashua, NH 03061-0868 (usenet) ...!uunet!rocket!lewin 603/885-0179 (Voice) (internet) lewin@rocket.sanders.com 603/885-0631 (FAX) ----------- From: Ralph Reid III <rreid@ecst.csuchico.edu> The C compilers I am familiar with pass parameters on the system stack. I do not remember what order the variables and/or pointers are placed onto the stack, but perhaps some simple (VERY simple) experiments can be performed on your system to determine this order. Once the order is known, the library functions you are working with might be tried with clearly defined test data. Good luck. -- Ralph. SAAC member. ARS: N6BNO Compuserve: 72250.3521@compuserve.com email: rreid@cscihp.ecst.csuchico.edu ----------- From: John Russell <uunet!canrem!john.russell@hacgate.scg.hac.com> Hi Avi, The experience I have is with TeleSoft technology on IBM platforms (System/370 VM and MVS, AIX/RT, and RISC System/6000). I guess I should disclaim any representation of IBM -- I'm on the net just as myself. First and most importantly, for all the record types that you have to map from C to Ada, use representation clauses. Even for simple records with things like 2 integers or 4 floats. Recent TeleSoft compilers reorder record components, which make representation clauses important for records you pass as arguments to C routines or do unchecked conversions on. For some scalar types, you may want to use length clauses. Optimizations may store an Ada boolean as 1 bit, while C booleans are typically 8 or 16 bits, for example. When mapping C defined constants to Ada, it's tempting to make a group of them an enumeration type. Before doing so, consider whether you'll be hampered by the restricted semantics: for example, you can't add 2 enumeration literals, while in C you often need to add numbers to form bit masks. Most C macros are created for efficiency: they'll do things like modifying one element in an array, changing a bit within a record component, or following down a chain of pointers. You can generally decode what a macro is doing, and create an equivalent Ada subprogram. If you use pragma Inline for these subprograms you should be able to keep the same sort of efficiency in Ada. (But you might also want to look at an assembler listing to see if the inline expansion is as efficient as the original C.) I'll be interested to see your summary. This topic is a particular interest of mine. Ciao, John -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host -- Avi Carmi EMail: carmi@ipla01.hac.com Phone: (818) 702-3179