Ada to C/C++ Conversion to Re-deploy Existing Ada Software

Overview
Ada-C/C++ Changer is a component of AppCOE, a robust porting and abstraction solution platform based on the Eclipse framework and GNU tools. Ada-C/C++ Changer reads the source code directly from your Ada source directories and then compiles them to generate equivalent C/C++ code that is fully readable and maintainable. If your Ada application requires any additional ‘C’ function calls, they can be easily added to the generated C/C++ output and compiled using either the supplied GNU compiler or another compiler to generate the application executable for your target.

Optionally, the resultant C/C++ code can be integrated with the OS Abstractor platform to obtain real-time performance, portability and stability across a multitude of OS platforms, thereby greatly minimizing any needed re-hosting effort. Integration with OS Abstractor allows the converted C/C++ code to utilize OS Abstractor’s scheduler primitives and enable your converted code to run on a wide variety of target OS platforms.

OS Interfaces offered by MapuSoft:

• OS Abstractor® Interface
• Linux/POSIX Interface
• micro-ITRON Interface
• Nucleus® Interface
• pSOS® Interface
• ThreadX® Interface
• VxWorks® Interface
• Windows® Interface
• µC/OS™ Interface
• FreeRTOS™ Interface

If your Ada application makes OS system calls, then it can use the OS Interfaces provided by Mapusoft, even if you move to a different OS platform, in order to make the re-hosting effort much easier.

Noteworthy Features:

• Supports conversion of Ada 83, Ada 95 & a subset of Ada 2005 source code to ANSI C/C++ output
• Preserves Ada comments, files structures and variable names for easier code maintenance
• Keeps “static” trees as symbolic expressions rather than evaluating them to literal values
• Provides user configurable options to control the format and style of the C/C++ output
• Provides GNAT compiler compatibility

Frequently Asked Questions about Ada-C/C++ Changer

Q: Could you please explain about Ada-C/C++ Changer Tool Tuning?

A: Every time that we use the tool to complete a project, we make adaptations to it based on the language constructs used in the source system and the desired target output (including desired coding standards, architecture, language, target language features, etc.). This adaptability is actually one of the features of the tool—it is quickly and efficiently customized to a particular customer’s desired output, rather than being a “one size fits all” tool that probably disappoints most customers.

When the code in scope is run through the tool the first time, the tool identifies the language features for which there is adaptation required. These are displayed in some indices of the initial documentation it generates. This is one of the reasons for an initial onsite visit of a couple days—we can run the code through, make some minor initial adaptations, and generate code that is transformed with 95% or greater automation. We would also gather some information from you about the desired target architecture, and use that information to select which rules are used, and make changes to existing transformation rules as needed.

Typically, the next steps on the project are to decide upon desired target outputs and tune the toolset to address any parse errors remaining or other transformation rules to the target language. Since the tool uses rules applied to a model of the original source system, we can adjust and adapt the rules being used and rapidly regenerate the system (even many dozens of times, fairly rapidly) to iteratively regenerate the target until it meets the project requirements.

Q: Which programs or projects Mapusoft has worked on for the DoD in the past?

A: The engine powering Mapusoft's Ada-C/C++ Changer 2.0 Engine has been used on DoD project since the early 2000s. These projects include:

• - The Navy Multi-band Terminal (NMT), a SATCOM terminal, which the tools transformed from Ada to C++
• - The Advanced Field Artillery Tactical Data System, a 5.1 million line Army system written in Ada, which the tools transformed from Ada to Java
• - The COBRA DANE Radar Calibration System (SCRS), part of the Ballistic Missile Early Warning System (BMEWS), transformed from 380,000 lines of Ada to C++
• - The US Army Variable Message Format Test Tool (VTT), transformed from Ada to C++
• - The P-3C Orion aircraft Acoustic Signal Processor System (ASP), transformed from Ada to C++
• - The Joint Mission Planning System (JMPS), a multi-branch system used by the Army, Navy, and Air Force, transformed from Ada to C#
• - The Weapons Control System (WCS), a weapons launch system for the Naval Undersea Warfare Center (NUWC), transformed from Ada to C++

Q: What specifications or requirements does our Ada code need to meet to be used by Ada-C/C++ Changer?

A: It must be self-contained and compilable by an Ada 95 or Ada 83 compiler. If you use third-party libraries which are not part of the Ada standard library, you will need to at least include the Ada source code for the package specs for such a library. If you want a translation of the third-party libraries as well, you will need to include the Ada source code for the package bodies of the library as well.

Q: Our Ada Software is far from modular. We would have a difficult time converting code pieces of the project for trial testing. How do you suggest we go evualuating Ada-C/C++ Changer to make sure it meets our needs? For example, if we just grabbed 5 random .adb files, would ADA-C/C++ Changer handle the conversion and just tell us what was undefined? Or would it fail completely?

A: AdaChanger is like a compiler. It requires the "specs" for any package that is "with"ed. It requires the bodies for any generic that is instantiated. It can work on a piece of a program, but that piece must at least include all of the package "spec"s referenced by "with" clauses, directly or indirectly. If you want to "build" an executable, then you will need a self-contained test program, including both specs and bodies for all code. If you simply want to compile the generated C code and/or do a manual review of the generated C code as part of your evaluation, you can get by with just the package specs.

Q: During our transition from Ada to C++, we will likely have developers working in Ada. How does Ada-C/C++ Changer handle development versions? For example, we take a snapshot of our Ada code today for conversion. While we are converting our Ada code and testing our new C++ code, our developers will be making improvements to the Ada. During the conversion, the developers make changes comparable to 3000 SLOC dispersed throughout the Ada project. Will the tool process just the 3000 SLOC changes when we go to make our final snapshot or will we need to convert the entire 150,000 SLOC again, resulting in the need for a license with more SLOC conversions?

A: The license is based on the maximum number of lines of code in the code base. There is no extra charge to re-translate the same lines again, nor to translate modified lines. If there are additional lines of code, then the total in the code base must remain below the license level.

Q: We have both a unclassified repository and a classified repository. The delta of our repositories is about 10,000 SLOCS. If we know the files which are different, can Ada-C/C++ Changer tool convert just those files without requiring a license that would re-count the other 100k lines that are the same?

A: You would only need to convert the package bodies in the shared code once. The package specs would be needed for both translations.

Q: Can I evaluate Ada-C/C++ Changer?
A: Yes, you can download an evaluation here: www.mapusoft.com/downloads

Q: What is the difference between Ada-C/C++ Changer and an Ada to C language syntax converter?
A: Ada-C/C++ Changer is not an Ada to C language syntax converter, which is very inefficient. Ada-C/C++ Changer technology is actually an Ada compiler along with a few command line switches that are used to perform Ada to C conversion. Since the conversion is performed via a compiler engine, the resultant code is optimized and guaranteed to execute. ‘C’ compiler can then be used on the resultant C code, which provides double optimization, therefore, the performance of the resultant C code is not compromised but optimized.

Q: What does the Ada-C/C++ changer tool consist of?
A: This tool uses the same Ada 95 font end that is used by Green Hills, Aonix, Analog Devices and Raytheon for their validated Ada 95 compilers. The C-generating “emitter” is used on daily basis both in-house and at customer sites, compiling millions of lines of Ada 95 code.

Q: What are the components of Ada-C/C++ Changer?
A: There are six components of Ada-C/C++ Changer:

• AdaCgen - Ada compiler which automatically compiles all user-registered Ada source and generates interim optimized C files, then the compiler will go through the optimized C files and convert them to readable/maintainable C source.
• AdaBgen - Ada builder/linker generates final executables by first automatically compiling required files (using AdaCgen) and then linking all the compiled modules to generate the executables
• Adareg - helper utility that will allow users to register all the Ada source for conversion
• Lister - helper utility that will generate cross-reference listings
• Adaopts - helper utility to set the Ada compiler/linker configuration options
• RTL - ‘C’ run-time modules that provides I/O, tasking, exception handling, and memory management modules which are normally required by Ada language for the ‘C’ converted code base

Q: How do you migrate the Ada tasking model to C/C++?
A: If the original code uses Ada tasking, the translated code makes calls on the routines that implement the Ada tasking model. As mentioned above, these are in turn implemented by a layered Ada run-time system that can be hosted on top of most modern RTOS’s.

Q: How does Ada-C/C++ Changer handle run-time errors?
A: Ada language, by default, automatically handles various run-time errors that are not handled by the application. It is recommended that the Ada code be first inspected manually or using Ada Inspector tool to ensure there is enough error handling code in place before performing the ‘C’ conversion. More information can be found here: http://www.mapusoft.com/ada-cc-changer

Q: How is my application’s safety certification maintained or re-asserted after converting to C?
A: Probably the best analogy is recompiling the system with a new compiler. Clearly you would have to rerun all your tests, but presuming you translate any Ada unit tests/drivers as well, you should be able to achieve the same level of MC/DC coverage achieved before the translation. Fault analysis, etc. should be identical. All of the comments in the code are preserved, and the code component names remain essentially the same, meaning that documentation should not need to be altered in any significant way. Given the ability to translate the tests/drivers, achieving adequate MC/DC coverage should not need redoing. Ada-C/C++ Changer is very mature. The Ada 95 front end used to drive the translation has been in active use for over 10 years, in many safety-critical systems, because of its use as part of the Aonix and Green Hills compilers.

Q: Conversion tools like AdaMagic only cover 70% - 80%. Do you have any data about the percentage of your coverage of Ada-C/C++ Changer?
A: We convert 100% of the Ada source into C, with no human intervention required whatsoever. Our tool is based on a fully validated Ada compiler, which handles the full Ada 95 language. It produces efficient and readable C that exactly matches the semantics of the original Ada program. Other tools with which the customer may be familiar operate more at the “syntax” level rather than the “semantics” level, and as such generally only handle a subset of the language, and even then often only produce an approximate equivalence to the Ada semantics in the generated C program. Because of the deep semantic analysis performed by our Ada-C/C++ Changer technology, we can precisely reproduce the Ada semantics in C, while still producing C code that is both readable and efficient.

Q: Apart from the I/O packages for each instantiation, what is the rate of lines of code increase when converting Ada->C? Also, are there any options in Ada-C/C++ Changer to reduce this increase?
A: It varies from 1.5 to 1 to 3 to 1, depending on the complexity of the Ada source code. Heavy use of string concatenation and dynamic aggregates produces more C code, since C doesn’t really have any equivalent to these.

Q: While evaluating Ada-C/C++ Changer, C code generated is around 5 times more than ADA code. Why is this?
A: The amount of C code will depend on the complexity of the Ada constructs being used in the Ada source code.

Q: A lot of types were not converted and carried over to the ‘C’ files. There were no errors issued by the compiler. Why?
A: All of these types should be carried over into the generated code, unless there was a compilation error. Note that many of these may have ended up in the “.h” file rather than the “.c” file. Be sure to check both.

Q: The interface of functions with Ada String parameters is changed and we had trouble understanding the body of the operation Procedure Printf(Msg: String) was converted to extern void Printf(const Character * const Msg, int32 const * Msg__dope). Explain.
A: In Ada, every unconstrained array also carries information on its array bounds. This is traditionally called the array “dope.” So when an array is passed, we also need to pass information on the low and high bound of the array, which is represented as a 2-word array of integers in the generated C code. Note that you can gain some control over this by using pragma Export or pragma Convention in the original Ada code. For example, by specifying the Convention is “C”, it will only pass the address of the first element of the array, and presume the called routine has some other way of knowing the high bound (e.g. a null terminator or a separate parameter).

Q: We don’t understand some of the ADA custom type conversions Type Reset_Data_Type is (One, Two, Three, Four) was converted to Const Integer Reset_data_type_enum_integer_table[4]={3,6,11,15};Const Character Test_data_type_enum_image_table[11]= {“ONETWOTHREEFOUR”}
A: Ada provides ‘Image’ and ‘Value’ functions for every enumeration type, and so the compiler needs to build up a table of information that allows an internal enumeration value to be turned into a string, and vice-versa. The enum_integer_table and the enum_image_table are used for that purpose. If you want to suppress the generation of such a table, you can use Ada’s “Discard_Names” pragma. Having done that, then Ada code that uses ‘Image or ‘Value will no longer work as expected, and instead will use numeric literals for input and output.

Q: The .h and .c files were created, but all it contained were the comments. No errors were reported in the command console. Why were these files not converted?
A: This normally means there was some compile-time error, or it might be that the file produces no code. This might happen for a generic package or generic subprogram, which produce code only when instantiated. We would need a test case to be sure either way.

Q: Why are .h and .c files created for each Ada file? I expected the Foo.1.ada file to be converted to Foo.h and the Foo.2.ada to be converted as Foo.c. Instead, I get a pair of .h and .c files for the Foo.1.ada and Foo.2.ada files.
A: A single Ada source file can have any kind of code within it, though some compilers are more restrictive than that and use specific naming conventions (such as Rational’s .1.ada and .2.ada, or AdaCore’s .ads and .adb). Ada-C/C++ Changer is designed to handle any organization of code within source files. Furthermore, even though a source file might contain only a package spec, it might still have code that needs to be executed when the package is “elaborated.” This code will be placed in the “.c” file for the package spec. Similarly, even though a file might contain only a package body, it might have “subunits” or “inlined” subprograms that need access to its local declarations, and so those are placed in a “.h” file for the body.

Q: I have several warnings about installation when executing my batch file. Is it a problem?
A: See joined files “batch.txt + batch.bat”. We will need to provide you with a “SITE/config” file and a “rtl/src/system.spc” that matches your current compiler’s configuration. We ship by default with a configuration that matches a typical 32-bit Intel x 86 compilers. You are using 64-bit integers, so that will require a different package System and a SITE/config file that supports 64-bit integers.

Q: What I expect from you is a syntax translator. In this particular case, what prevents you from translating it as a C “long long” type?
A: It will be the job of the C compiler that I will choose independently from Ada-C/C++ Changer, to verify if the long long is implemented on my HW platform. The location where I translate may not be the location where I compile.

Q: Is the code generated from Ada-C/C++ Changer compiler portable and real-time?
A: Ada-C/C++ Changer is very portable because the Ada-C/C++ Changer RTS relies mostly on the standard C run-time. However, it isn’t truly “real time” because it uses C “setjmp/longjmp” to accomplish multi-threading, which is not very flexible. By adapting the Ada-C/C++ Changer RTS to use the OS Abstractor APIs, we can use “true” multithreading, and still be very portable to multiple OS and RTOS, thanks to the many targets on which MapuSoft’s OS Abstractor runs.

Q: The result of your ADA check seems to be a condition to accept translation. In particular, you find an “error” because 1 line of _comment _is more than 210 characters long. This case is not in the supplied trace. Please translate!
A: The Ada standard identifies 200 characters as the line length that an implementation must support (see Ada RM 2.2(15)). We can alter this if you choose to order the product, but for evaluation purposes you may want to break the long line into two lines no more than 200 characters each.

Q: I am an eval customer. Does your management library control the limitation of the number of lines to translate, but performs cross files checks (for “with” dependencies)?
A: Because the translation to C is done at the “semantic” level rather than at the simple “syntax” level, we need to be able to “compile” the source that we are going to translate. So that means that we require the source code for all “with”ed package specs be made available to the translator

.

Q: In SITE directory, the content of rts_path is wrong. The path is false! Is it a problem?
A: Yes, this needs to be edited, as explained in the Ada_Magic_Install.txt file, so that it refers to the “rtl” subdirectory of the installation directory.

Q: I have manually modified the rts_path file, but ADA.LIB generated file is still wrong. The tool behavior does not change. So, in my Files_C directory, the content of ADA.LIB is wrong. The (same) path is false! Is it a problem?
A: Yes, this is copied from the rts_path file. So you will need to delete the ADA.LIB and rerun after fixing the rts_path file.

Q: Is OS Abstractor & Ada-C/C++ Changer an independently Safety Certified Product? (Approved agencies include, but not limited to, DoD safety boards, National Security Agency, or Federal Aviation Administration)?
A: They are not independently certified. It has been in use with various applications that require certifications. We will assist our customers with the certification process of the application combined/integrated with MapuSoft code if necessary.

Q: Does Ada-C/C++ Changer accept Ada83 code or is conversion to Ada95 required?
A: Ada-C/C++ Changer accepts Ada83 code as is and does not require the code to be converted to Ada95

Q: Have any customers moved from Rational APEX with MapuSoft tools?
A: We generally don't know what compilers the customers were using. The key thing is that you will need to have full access to all of the Ada source code, including that supplied by the compiler vendor, unless it is part of the "standard" Ada library.

Q: Are there any Ada-C/C++ Changer options specifically available for Ada code developed under Rational APEX?
A: Not really. The "config" file may need to be adjusted to match the target computer, for example if the target has a 64-bit address, or uses a big-endian (as opposed to a little-endian) word representation, etc.

Q: Does the Ada-Changer handle the Ada elaboration aspect correctly?
A: Yes. Think of Ada-C/C++ Changer just like a validated Ada95 compiler. It handles the full language, and generated C/C++ code that does precisely what the Ada program did.

Q: I understand Ada-C/C++ Changer includes a C/C++ debugger. Does it also include an Ada source level debugger?
A: Limited Ada source level debugging is supported and it is roughly similar to what is supported by "yacc," where we can associate the Ada source code and the Ada line numbers with particular locations in the C/C++ source code, using "#line" directives. However, this can be confusing, because the programmer still has to live with the fact that in Ada upper/lower case doesn't matter in Ada debugging, while in "gdb" it does matter, and with the fact that Ada has overloading, but in the generated code we append unique numeric indices to names, such as "Ada::Text_io::Put_line__2" for what in Ada was "Ada.Text_IO.Put_Line." Because of this, we generally recommend that developers debug at the C/C++ source code level. The names are usually easy to connect back to the Ada source code level, and they are displayed in the C/C++ source code with the correct upper/lower case

Q: Do you have support for 64 bit when using Ada changer?
A: Ada-C/C++ Changer does support 64-bit target environment when you do code generation. It is just a question of updating the "config" file. We use it ourselves on a daily basis on a 64-bit Intel target ("X64").

Q: Does Ada-C/C++ Changer automatically convert Ada generics to C/C++ templates?
A: Automatic conversion is not supported. However, manual conversion is possible by engineers with strong C++ background and if they are able to read Ada generics. If required, MapuSoft could provide a consultant who can do this either remotely or at customer site for extra charges.

Q: How is MapuSoft’s Ada-C/C++ Changer compare to simpler tools like Ada2CC?
A: Ada-C/C++ Changer includes a front-end Ada compiler and provides 100% automated conversion of Ada code to C/C++ there by eliminating the risk associated with the transition. In addition, it is integrated with Cross-OS development platform to support wide range of OS platforms and tools. Ada2CC only does a syntax-level conversion from Ada to C/C++ and there is no guarantee that the result will compile, much less do the same thing if you do get it to compile. Because of this, great amount of manual porting and testing work is eliminated.

Q: Why cant I see any active code in the translated files? All I can see is the comments after the conversion.
A: Translation/Conversion could have failed due to the lack of 64-bit integers in the package “System” and in the “config” file that we ship by default.

Q:When trying to run the Ada-C/C++ Changer on some Ada code that uses #IF/#END IF the # is flagged as an illegal character. Is there a way to get the Changer to recognize the preprocessor directives?

A: Preprocessor directives are not a standard part of the Ada language. Some Ada vendors support them, but they don't all support them the same way.
In some cases you can use the standard C preprocessor with the Ada sources, using the "-E" flag to gcc, for example, to have it process only the preprocessor directives and produce an expanded version of the source. You will have to temporarily rename your Ada source to end in ".c" if you want "gcc -E" to expand the C preprocessor directives, then you can redirect the output, delete any remaining lines starting with "#", and rename it back to end in ".ad?".
Alternatively, you might be able to use the original Ada compiler you used to develop the Ada code, and give it a flag requesting an expansion of any preprocessor directives.

Q: Are Ada enums directly translated to C enums or defines?

A: Ada enums are translated to C enums


Q:. How are the tick operators handled and translated on enums, such as ('first, 'last, 'count, 'range, 'succ, 'image) i.e. does 'succ and 'pred become ++ and -- does 'image become an sprintf

A: 'First, 'Last, etc. are translated to references to the appropriate C enumeration literals. 'Succ and 'Pred do not become "++" and "--" but rather "+1" and "-1". 'Image becomes a call on a run-time routine rts_enumeration_image which we provide. This relies on a table of enumeration-literal images which is generated by the translator and included in the C source code.


Q: How are Ada rep-specs translated directly to C-field specs? (i.e. Ada LSB is nominally C-language MSB)

A:: Appropriate C bit-field specifications are include in the C struct definitions. There is a "config" file which can be used to tailor the translator to unusual characteristics of the target C compiler, though the default "config" file works in most cases.


Q: Is the boundary for this translation integer only (32bit). Is there any provision for 16bit

A: The translator can generate appropriate C pragmas and bit-field specifications to control packing down to the bit level.


Q: How are fixed and scaled integer/floats handled (i.e. Ada delta).

A:Ada fixed-point types are translated to C integer types, with run-time routines used for special operations such as fixed-fixed multiply and divide where the built-in C operators don't do the right thing.


Q: If we have this mapped to a variable-member in a record/rep-spec can we simply assign to it
or do we have to do additional mathematics to get the delta of the LSB's to be correct.

A: The generated C has exactly the same semantics as the original Ada source code. You don't have to do any manual fixups.

Q: How are Ada packed arrays handled? Are they converted to strings? and if so, do you add 1 extra byte for the null?

A: Packed arrays are referenced as byte-arrays in C, with appropriate shifting and masking to handle cases where the elements are less than 8-bits/element. We don't generally add an extra byte. Ada strings are converted to C char-arrays, and C string literals end up with an extra null byte.


Q: How are Ada arrays with enumerated indices handled? (i.e. Ada allows array indices to start with non-zero, even non-numeric values) How is this mapped to C which must always starts at zero?

A:Enumerated indices are not generally a special case, as enumeration values may be used as indices in C. However, if the Ada enumeration type has an enumeration rep clause which leaves holes in the enumeration sequence, then a table is used to translate the Ada enumeration values to a contiguous sequence of values starting at zero, as needed for indexing. In the general case, the low bound of an Ada array is subtracted out to produce a zero-based array for C indexing.


Q: Is there a concern while using of computations with 'pred, 'last, 'first and expressions using them giving the correct answer

A: A table is used to ensure that 'pred, 'last, etc. produce the right answer, even for enumerations with holes in the representation.


Q: Ada isn't case sensitive and there may be some variables of correct name which have incorrect case. How is this handled with case sensitive C? Does the capitalization of the declaration take precedence?

A: Ada C/C++ Changer has several different options. The default is to canonicalize the spelling so the first letter is capitalized and the others are lower case in the generated C source code. Ada C/C++ Changer can also use the spelling from the declaration in all cases. It can all use all lower case in the generated C.


Q: . How are Ada rep-spec 'use at or 'size clauses translated? (iow. how does a record (or variable) get mapped to an address with correct size).

A: Appropriate padding or packing is specified to ensure the generated C struct matches the specified 'size. For "use at" (i.e. for X'Address use ...) a pointer is used in the C code, with the pointer initialized to the specified address.


Q: How are Ada Classes translated/implemented in C++

A: They become "struct"s in the generated C++, with separate tables of function pointers used to implement Ada's dispatching operations.

Q: . How are "for" loops and "while" loops handled in Ada C/C++ Changer? Will this implement jump statements?.

A: Both "for" loops and "while" loops in Ada become while loops in C. We don't use "jump" statements in the generated C unless the original Ada had a "goto."

Q: How are task priorities handled?

A: When a task is created, a run-time routine is called, with the specified task priority as a parameter. If you are using the OS Abstractor, these priorities are passed through to the underlying RTOS. If you are not using the OS abstractor, the priorities are used by a simple task switcher implemented using setjmp/longjmp.

Q: How is preemption handled in Ada C/C++ Changer ?

A:If you are using the OS Abstractor, then all task scheduling is handled by the underlying RTOS. If you are using the setjmp/longjmp task switcher, preemption is handled through C signal handling.

Q: How are task delays, waits, scheduling handled?

A: Again, the answer depends on whether you are using OS Abstractor. If using OS abstractor, all of these things are translated into corresponding operations of the underlying RTOS. If using the setjmp/longjmp task switcher, delays are implemented using "alarms," waits and scheduling are implemented using priority queues.

Q: With the OS Abstractor we were informed that an OS dependent library call is made for tasks.

A: The OS Abstractor provides a standard interface that resembles Posix threads. Internally it turns calls on its interfaces into calls on the underlying RTOS.

Q: How is the Ada bit representation for record types converted?

A: There is a fairly direct translation, with Ada records becoming C/C++ structs, and Ada components becoming C fields, with C/C++ bitfield specifications generated as appropriate.

Q:) How is hardware/memory addressing converted – an Ada “use at” statement?

A: The C struct is referenced through a pointer, which is initialized to the specified address.


Q: How are Ada exceptions converted?

A: If you are generating C++ rather than C, Ada exceptions are translated into C++ exceptions.


Q: How are calls to Ada library packages converted (wind32, calendar, text_io)

A: When generating C++, each Ada package becomes a separate C++ namespace. For bindings like Win32, the generated C/C++ code has direct calls on the corresponding C interface, using export "C" {}.


Q: How is memory allocation/deallocation converted?

A: The standard C library malloc and free routines are called. If using OS Abstractor, these are generally converted into calls on the RTOS malloc/free calls.


Q: How are AdHow are Ada generic packages converted?

A: Instances of Ada generic packages are expanded at compile-time into non-generic code C/C++. Generic packages themselves do not translate into anything in the C/C++ code. We can provide assistance in a semi-manual procedure for generating C++ templates from Ada generics, but this is not a fully automated process.

Q: How are Ada record types converted? What do they look like if they have bit representations?

A:Ada C/C++ Changer use C/C++ bit field specifications as necessary to provide an identical "struct" representation as described in above answers.

Q: For the Ada compiler, what target hardware is supported?

A: As far as the target support it basically depends on the C/C++ compiler that would be used by the customers. Ada-C/C++ Changer has Ada compiling front-end and uses a C/C++ compiler back-end. Many of our customers use GNU compiler which basically support a wide variety of target platforms.

Q: Can Ada-C/C++ Changer tool be used outside of AppCOE IDE?

A: Yes. There is no need for everyone to use AppCOE to do Ada to C/C++ conversion, if you wish, the tool can be used outside of the AppCOE with our standalone tools for Ada compile/conversion. Even if you choose to use the AppCOE tool initially, you can always extract the full source code along with required projects and such via code generation.
MapuSoft’s product line is focused on providing developers a way to move their code to different platforms. In addition to our Ada convertor, we also offer the Cross-OS Development Platform. This tool can be integrated with Ada-C/C++ Changer to easily port your code from various operating system platforms without you having to do the porting work.

Q: Why an automated conversion tool should first compile the Ada code?

For any automated conversion method you will require that the Ada source code be compilable by the tool. Unless you can compile Ada source code, there is really no way to know what it is doing. For example, in Ada, something as simple as "F(X)" can mean about five different things, such as calling a function called F, indexing into an array called F, converting to the type called F, calling a function called F which returns a pointer to an array, and then indexing into that, or selecting the "X"th dimension of a multi-dimensional array F. So unless you can compile the code, there is no way to properly translate "F(X)" into C or C++, because without compiling, the tool won't know what is the exact meaning of "F" nor the exact meaning of "X," both of which can affect what is the proper translation for "F(X)". Therefore, our tool first compiles the code before it will start the translation so that you know the outputted code will compile and run.
Assuming that Ada libraries are available in source code format, Ada-C/C++ Changer can be easily configured to support various Ada compiler code generation formats. We also provide GNAT compatibility to assist in moving from GNAT compiler. Our tool supports variety of host platforms and also handles various re-hosting scenarios.

Q: How does Ada-C/C++ Changer compare to Ada2cc?

The following paragraph has appeared on the Ada2cc product description for many years:

“How ‘good’ is the translation?

We estimate that the current version of the translator converts 90-95% of the code without hand modification. However 5% is still a lot and we are constantly making improvements. Most of the changes required are of the following nature:

Promoting nested functions.
Adding non-default constructors.
Adjusting template parameters.
Inserting system specific function calls to support real-time functions."

This exact same set of "changes required" has been true for many years, while they have claimed for many years they are "constantly making improvements," but apparently they aren't really doing so.

In addition, these are very basic limitations, so this looks like a very simple-minded syntax-based translation tool, with no real semantic information used, and no guarantee that it preserves Ada semantics at all.

Q: What is the purpose of Label___dope appearing in my converted code?  And more generally anything “dope”?

In Ada, the bounds of an array (the 'First and 'Last) are generally passed as a separate argument.  This argument is traditionally called the array "dope" or array "dope vector" (e.g. see https://en.wikipedia.org/wiki/Dope_vector).
Q: What is “rts_ss_mark” and “rts_ss_release” functions appearing in my converted code?  I’m not sure I’m following what’s going on there…

Ada uses a "secondary stack" to hold locally declared objects and temporaries whose size is not known at compile time.  This secondary stack is managed using a "mark/release" discipline (for background, see "mark-and-release" in http://www.flounder.com/memory_allocation.htm).  "rts_ss_mark" does a "mark" on the secondary stack, "rts_ss_release" releases everything on the secondary stack back to the specified mark.  In the above example, a "mark" is saved into pointer_1 at the beginning of a series of operations, and then a "release" is performed at appropriate points to recover the storage that had been allocated on the secondary stack, by operations such as "rts_ss_char_concat" which concatenates two strings into a temporary result on the secondary stack.