Migration of DACS Source to SCORE
with the Ada 83 Switch By David Mosley
In spite of every effort to define Ada 95 to be upward compatible with Ada 83, compiling Ada 83 source with an Ada 95 compiler may require some source changes. There are a few issues where Ada 95 differs syntactically from Ada 83. And there are issues which arise when any source is migrated from one system to another.
SCORE Ada 95 implementation contains a compiler option, the Ada 83 switch, which reverts the compiler to using Ada 83 syntax. In this mode, it checks for illegal Ada 83 constructs (which should not occur in valid Ada 83 source), and makes an adjustment in the reserved words.
To compile a source file using Ada 83 syntax, use a command of this form:
ada -ada83 [options] source-file
Here are the three major language compatibility issues and how they should be addressed.
1. New Reserved Words
The following new reserved words exist in Ada 95:
abstract, aliased, protected, requeue, tagged, until
When compiled with an Ada 95 compiler, any occurrence of these identifiers must be renamed. However, if the source is compiled with the Ada 83 option, the new reserved words lose their special status and will be treated as normal Ada 83 identifiers. When these identifiers are removed from the set of reserved words, nearly all of the new Ada 95 features (e.g., tagged types) are disabled.
2. Character has 256 Positions
In Ada 95, the subtype Character has 256 positions; where in Ada 83 it has 128 positions.
This change makes arrays with character index; case statements with a character choice and no others choice; and uses of Character’Last likely to become illegal or incorrect. The solutions may involve defining a subtype of Character with the range from Ada 83, introducing an others choice, or replacing Character’Last with Ascii.Del.
3. Unconstrained Generic Actual Subtypes
A new syntax for a generic formal private type is introduced to indicate that the actual subtype is allowed to be indefinite. The syntax in Ada 83 still exists, but requires the actual subtype to be definite.
In Ada 95, the Ada 83 syntax:
generic
type Element_Type is private;
package Stack is ...
requires Element _Type to be matched by an actual subtype such as Integer, a constrained array, or a record type with default discriminants (all definite types). An actual parameter of an indefinite type, such as an unconstrained array, would be illegal.
The Ada 95 syntax which allows either definite or indefinite actual parameters (i.e., the Ada 83 syntax) is shown below:
generic
type Element_Type(<>) is private;
package Stack is ...
The following issues all arise from semantic differences between the two systems (which include implementation-defined characteristics). Listed below are the more common differences. See the DACS to SCORE Migration Guide for complete details.
4. Objects of Mutable Record Types
SCORE avoids implicit heap usage under all circumstances. One effect of this is that certain objects can no longer be declared of mutable discriminant record types because the representation of such objects require too much memory.
Example
type Var_String( Length : Natural := 0 ) is
record
Value : String( 1 .. Length );
end record;
Obj : Var_String;
End example
SCORE will report an error message stating that the object exceeds the capacity for such objects. No single approach will suit all situations but a simple change will often be to introduce a subtype of the discriminant type with constant bounds and use it as the type of the discriminant (this allows the SCORE compiler to reduce its worst-case size calculation and avoid the capacity problem).
Example
type Var_String_Natural is Natural range 0 .. 1000;
type Var_String( Length : Var_String_Natural := 0 ) is
record
Value : String( 1 .. Length );
end record;
Obj : Var_String;
End example
5. Alignment
The default alignment of various types have changed from DACS to SCORE. SCORE typically aligns objects of scalar types to their (byte) size. Within records, DACS 80x86 lets all components start at 2 byte boundaries. DACS SPARC native uses the same alignments for the scalar types, but uses the size of arrays and records to determine their alignment so that it may exceed that of any of their components. This difference will only require modifications where the source code implicitly relies on a particular data layout.
DACS 80x86 interprets the value in alignment specifications as a storage unit count. These values probably require modifications to work with SCORE since the storage unit of DACS 80x86 is two bytes while it is one byte in SCORE.
6. Component Clauses
DACS 80x86 allows certain record component clauses which SCORE does not allow.
Example
type Arr is array (0..31) of Boolean;
type Rec is
record
Comp : Arr;
end record;
for Rec use
record
Comp at 0 range 0 .. 31;
end record;
End example
The component clause is accepted by DACS 80x86 to pack the component of type Arr in this context though Arr itself is unpacked. SCORE does not allow a record component clause on a component of a structured type to change the layout within the component of the structured type. The source code must be modified so that the component type is packed or otherwise specified to have the size from the component clause (or to introduce a derived type with such packing and use it as the component type and add type conversions as needed).
Example
type Arr is array (0..31) of Boolean;
pragma Pack (Arr);
End example
7. Address Clauses
Due to the different definition of the type System.Address in DACS and SCORE, address clauses for objects and subprograms may require modification to change the values to be positive integer values.
SCORE does not allow address clauses on task entries which is the Ada 83 method for defining interrupt handlers. Such interrupt handlers must be rewritten, see the Interrupt Handlers section below for details.
8. Interrupt Handlers
In DACS 80x86 interrupt handlers are task entries with address clauses and possibly with pragma Interrupt_Handler; in SCORE interrupt handlers are protected procedures with pragma Attach_Handler or pragma Interrupt_Handler. The two forms cannot be mixed so source code modifications are required to go from one form to the other. The following describes some general approaches.
Example
Value : Value_Type;
task Interrupt_Task is
pragma Interrupt_Handler; – Fast Interrupt Handler
entry Int;
for Int use at 7;
end Interrupt_Task;
task Consumer is
entry Ready;
end Consumer;
task body Interrupt_Task is
begin
accept Int do
Value := Read_Value;
select
Consumer.Ready; – Signal Consumer task
else
null;
end select;
end Int;
end Interrupt_Task;
task body Consumer is
begin
loop
accept Ready;
Process( Value ); -- Process Value when ready
end loop;
end Consumer;
End example
This can be rewritten into a protected object with an interrupt handler. However, since protected objects are not allowed to make blocking calls (e.g., an entry call), the relationship between the two tasks in the example must be reversed and could then look as follows.
Example
Value : Value_Type;
protected Interrupt_Task is
pragma Interrupt_Priority;
entry Ready; -- Queue caller until Value is ready
procedure Int;
pragma Attach_Handler( Int, 7 );
private
Open : Boolean := False;
end Interrupt_Task;
task Consumer is
end Consumer;
protected body Interrupt_Task is
entry Ready when Open is
begin
Open := False;
end Ready;
procedure Int is
begin
Value := Read_Value;
Open := True; -- Signal Value is ready
end Int;
end Interrupt_Task;
task body Consumer is
begin
loop
Interrupt_Task.Ready;
Process( Value ); -- Process Value when ready
end loop;
end Consumer;
End example
[
Back to Top ]
Something to
Think About
Great
Idea! And...
By Linda Rising
risingl@acm.org
www.lindarising.org
Now that the movie "Ray" about the life of Ray
Charles is out on DVD, my husband and I were able to enjoy it last
weekend. I expected to learn from the story of the struggles of this
remarkable musician. But I saw something I didn’t expect—the wisdom
of his mother, Aretha, as a teacher.
Ray Charles Robinson -- he later changed his name
to avoid confusion with the noted boxer -- was born during the Great
Depression. Ray became blind at the age of seven; his blindness
struck just shortly after his younger brother's accidental death.
When Ray began losing his sight, his fiercely
independent mother insisted he make his own way in the world and
refused to let him wallow in self-pity. Since his sight loss was
gradual, she began to help him do things for himself. His mother
knew that not catering to Ray’s expressed needs was the best way to
help him learn to face it, to prepare him for as he later describes
it—being alone in the dark. How did she know to do this? How did she
come by all the wisdom she displayed—in the face of extreme poverty,
after the death of one child and the oncoming blindness of another?
Some of the things that Aretha knew are now being
verified by research into how people learn and how they adapt. These
techniques that Aretha applied intuitively to help her child could
seem counter-intuitive. In the movie, the scenes of young Ray
struggling to find his way as his sight faded were heartbreaking.
Ray cries out for his mother and she holds herself back, resolute,
fighting her mother’s instinct to run to protect her child, and in
the end, providing the very best protection of all—his own courage
and fierce independence.
I’ve just finished reading a book about one of
the most agile organizations to appear on the scene—the United
States Marine Corps [1]. I hope to share some of the lessons from
this book in later articles, but here I will talk about one of the
core principles for training Marines: Reward failure. Marine
officers can be as tough on willful or negligent subordinates, but
they tend to be unusually tolerant of most other types of mistakes.
No matter who is seen to be at fault, failure is
not the worst thing that can happen to a Marine. You could almost
say that they demand failure. A Marine who rarely fails is regarded
as a Marine who isn’t pushing the envelope enough, while a Marine
who takes a bold but logical action and falls on her face is likely
to be praised. "It’s very hard in our society today to have this
attitude," says retired Major General O.K. Steele. "With so much
litigation going on, we’ve become a zero-tolerance society. But a
commander with zero tolerance won’t work for us."
Marines see this kind of failure not only as a
sign that a Marine is taking chances, but also as the best possible
learning experience. As one captain put it: "It’s hard to keep quiet
when you see someone making a mistake in training, but you have to.
When that lance corporal makes the decision and sees it not work,
that’s how it becomes internalized."
Do you see what I see? Ray Charles’ mother,
Aretha, and the Marines both believed that by allowing their charges
to fail, important learning would occur. In both cases, this
learning is not only valuable, but potentially life-saving. Both
Aretha and the Marine officers know that precious lives are on the
line. We who make business decisions may not have this heightened
level of concern, but we should certainly pay attention to what
these stories have to teach us.
Unfortunately, here’s the typical business
scenario. I read this story in a Fast Company article some time ago,
but the lesson hit home for me.
The two men were having dinner. One of them
was Jon Katzenbach, who heads his own elite consulting boutique.
The other was Niko Canner, his brilliant partner. They were
planning a new venture. But when Niko floated ideas, Jon would
interrupt him, saying, "That's a great idea, but it might work
better if you…."
Successful people must battle a constant need
to win. When the issue is important, they want to win. When the
issue is trivial, they want to win. Even when the issue isn't
worth the effort or is clearly to their disadvantage, they still
want to win.
Research shows that the more we achieve, the
more we tend to want to "be right." At work meetings, we want
our position to prevail. In arguments, we pull out all the stops
to come out on top. Even at supermarket checkouts, we scout
other lines to see if there's one that's moving faster.
Jon was displaying a variation on the need to
win: adding too much value. Leaders are usually smart enough to
realize that most of their subordinates know more in specific
areas than they ever will, but old habits die hard. It's
difficult for smart leaders to listen without communicating
either that they already knew about it or that they know a
better way.
This process may improve the idea by 5%, but
they've reduced the employee's commitment to executing it by
30%, because they've taken away that person's ownership of the
idea. Whatever is gained may be lost six times over in the
employee's diminished enthusiasm for the concept.
This is not to say that bosses have to zip
their lips to keep their staff's spirits from sagging. But the
higher you go in an organization, the more you need to let other
people be winners and not make it about winning yourself.
If you find yourself saying, "Great idea, but
. . ." try cutting your response off at "idea." Even better,
take a breath before you say anything, and ask yourself if what
you're about to say is worthwhile. One high-level manager said
that once he got into that habit, he realized that at least half
of what he was going to say wasn't worth saying.
I recently attended a conference where one
session was devoted to demonstrating scenarios that would help
participants understand agile development practices. One of the
scenarios that comes to mind at this point was designed to
illustrate how simple communication practices can improve the
quality of ideas that are generated by teams.
In this exercise, two people are talking about
planning a party. The first person presents an idea for the party
and the second person responds, "Great idea, but…." The scenario
runs for several minutes, with the first person offering a series of
ideas and meeting the same response, "Great idea, but…."
Then a second scenario is run. This time the
suggestions from the first person are met with the response, "Great
idea, and…" It’s astounding what using "and" instead of "but" can do
to the conversation, the level of enthusiasm, and the good feelings
of the first speaker. What is it about the word "but" that tends to
bring out the criticism, the negative comment, and the sense that
the idea is not really all that great—while the word "and" leads us
to participate in and offer support for the idea?
If we are serious about wanting our colleagues
and our subordinates to be innovative and agile, then maybe we
should see what we can learn from all this. To encourage others’
ideas (OK, maybe they’re not perfect, but remember the penalty for
insisting that they do it "our way".) try using "and" instead of
"but" and see where the conversation goes.
I found the following story in an interview with
organizational psychologist Karl Weick [3]:
Back in 1975, the third Skylab crew had a
tight schedule of experiments to run. NASA kept leaning on them
to take on more experiments. The crew got more behind, more
overloaded, so they turned off the microphone for 24 hours and
spent some time reading and looking out the window. This says
something about how companies blend control and autonomy. People
are better able to get complex assignments done when given more
discretion within a framework of common values.
This is it, isn’t it? This discussion is really
about trust. We have to trust that our children, our recruits, our
colleagues, our subordinates are OK. Yes, they need guidance. No, we
can’t afford royal screwups. But, deep down, these others in our
lives need our trust that they can learn, if we will help them; they
can innovate, if we encourage them; they can take us to the moon and
back, if we let them be "the few, the proud."
Let me know if you try some "ands" instead of "buts" and how it
works for you!
References
1.Freedman, D.H., Corps Business: the 30 management principles
of the U.S. Marines, HarperBusiness, 2000.
2. Goldsmith, M., "Adding Value -- but at What Cost?" Fast
Company, August 2003, 58.
3. Geirland, J., "Complicate Yourself," Wired, April 1996,
137.
 |
The Something to Think About column is
written by Linda Rising. Linda has a Ph.D. from Arizona
State University in the area of object-based design metrics.
Her background includes university teaching as well as work
in industry in telecommunications, avionics, and strategic
weapons systems. She is the author of numerous articles and
has published three books: Design Patterns in
Communications, The Pattern Almanac 2000, and A Patterns
Handbook. Follow this link for information regarding her
latest book "Fearless Change: patterns for introducing
new ideas".
http://www.cs.unca.edu/~mns.html
http://www.lindarising.org
risingl@acm.org |
[
Back to Top ]
|
