ACM SIGAda Ada Letters

Mahani, Negin; Mokri, Parnian; Sedghi, Mahshid; Navabi, Zainalabedin

doi: 10.1145/1620593.1620595pmid: N/A

Recent research on system level design has produced a new level of abstraction for description of hardware that is referred to as Transaction Level Modeling, or TLM. TLM separates hardware into computation and communication units and describes each at a very abstract level. Another important property of electronic circuits, which is also modeled well in TLM, is concurrency of tasks and operations. Inherent concurrency of Ada, makes this language a good candidate for design and description of modern electronic systems. This paper* describes how to use. Ada as a system description language like SystemC, and will use Ada compilers (such as Gnat) to evaluate systems described using Ada. We refer to the adaptation of Ada for system level description as SystemAda. This paper reviews Ada programming language requirements for modeling behavior of a digital system at transaction level, and considers possible approaches for extending Ada to meet these requirements.

Levine, Gertrude

doi: 10.1145/1620593.1620596pmid: N/A

This paper examines degradations of service in terms of constructs of the Ada programming language that are effective for their control and deployment. Several studies of the software lifecycle have focused on taxonomies of defects or errors. Categories of service degradations, however, have only recently been identified. A classification scheme for service degradations clarifies their relationship to defects and errors and their role in the prevention of failure. With the growth of hard real-time systems, wireless networks, and multimedia applications, a comprehensive understanding of service degradations and their usage has become ever more important.

Rosen, J.-P.

doi: 10.1145/1620593.1620597pmid: N/A

Barnes, John

doi: 10.1145/1620593.1620599pmid: N/A

Gem #51 is the eleventh chapter of John Barnes' new booklet: Safe and Secure Software: An Introduction to Ada 2005.

Briot, Emmanuel

doi: 10.1145/1620593.1620600pmid: N/A

Ada Gem #52 -- Programming languages are, at least in the mind of most programmers, divided into two categories: scripting languages and others. The dividing line is not always obvious, and generally has to do with the size of the application, whether the language is interpreted or compiled, and whether doing operations such as manipulating external processes is easy. It's safe to say, though, that Ada is almost never classified as a scripting language. This Gem demonstrates a few of the packages that are part of the GNAT distribution and that provide helpful scripting features to accomplish tasks that would often be thought to be in the domain of languages specialized for scripting. Portability is of course a major advantage of choosing Ada!

Briot, Emmanuel

doi: 10.1145/1620593.1620601pmid: N/A

In Gem #52, we saw various facilities that GNAT provides to make Ada a scripting language (sort of). We discussed GNAT.Command_Line, GNATCOLL.Mmap, GNAT.Regpat and GNAT.AWK. This Gem continues the discussion of scripting capabilities, and focuses on interaction with external processes.

Ochem, Quentin

doi: 10.1145/1620593.1620602pmid: N/A

Interfacing Ada and Java is a very tricky problem. As opposed to C, C++, or Fortran, the two languages execute on two different environments, Java on the JVM and Ada directly on the underlying OS. For this reason, it is not possible to directly bind Java functions to natively compiled Ada through a pragma Import. Two solutions are offered to the developer: either compiling the code directly to Java bytecode, using GNAT for the JVM, or using the Java Native Interface (JNI), allowing communication between the native and JVM environments. In this Gem we will take a look at the latter. Using this JNI layer manually is very error-prone and tedious. Fortunately, AdaCore provides a set of tools for automating the interface generation, through GNAT-AJIS. This Gem is the first of a series showing how this toolset can be used to create a mixed Ada /Java application.

Ochem, Quentin

doi: 10.1145/1620593.1620603pmid: N/A

In a previous Gem we introduced ada2java, which maps an Ada specification to a Java specification, to support calls from Java to Ada. Even though ada2java doesn't support creating Ada bindings of Java specs, it's still possible to use it to support calls from Ada to Java. In this Gem we'll look at a first possibility of doing this, using callbacks (in Ada terms, access-to-subprogram calls).

Ochem, Quentin

doi: 10.1145/1620593.1620604pmid: N/A

In the preceding Ada/Java interfacing Gem, we saw how to create calls from Ada to Java using ada2java and callbacks. We're now going to go one step further, and discuss a cross-language dispatching mechanism that supports extension of an Ada tagged type in Java, allowing the possibility of making dispatching calls equally well from either side.

Ochem, Quentin

doi: 10.1145/1620593.1620605pmid: N/A

Ada and Java are two languages that rely heavily on exceptions. A large part of the Ada data model is based on the fact that data is checked at run time, and will raise various kinds of exceptions such as Constraint_Error when constraints are violated. Similarly, there are many cases where Java performs checks that can raise exceptions, among the most common being checks on casts and null dereferences. It is therefore extremely important to support exceptions that are properly propagated from one language to the other and even potentially caught/handled, without having to worry about the language of origin.