Site Map
DDC-I, # 1 in Customer Care     · Safety Critical Embedded Software Development
    · Customized Tools & Services Tailored to Fit Your Needs
    · Legacy Software System Modernization
    · Ada Compilers, C Compilers, C++ Compilers, JOVIAL Compilers, FORTRAN Compilers
 



October 2005

Products / Services

 
   
 

Products

 
   
 

 

 
   
 

Custom Services

 
   
 

 

 
 

Spotlight

 
   
 

"We are pleased that this seamless integration is now available for our safety critical customers and look forward to working with them in the future."

Rob Hoffman,
Senior Director Aerospace & Defense,
Wind River Systems
 

 
   
 

 

 
 

Contact the Editor

 
   
 

DDC-I Online News is published by DDC-I, Inc., 400 N. 5th Street #1050; Phoenix, AZ 85004, Editor: Jennifer Sanchez

Comments and submissions of articles are welcome and should be sent to the editor at the above address or by email to editor@ddci.com.

Copyright 2005, DDC-I, Inc. Permission to copy is prohibited. References to other companies and their products use trademarks are owned by the respective companies and are for reference purposes only.

 

 
   
 

 

 
DDC-I Online News
Inside this Issue

 

For Immediate Release

Customer Loyalty Brings New Opportunities for DDC-I

Phoenix, Arizona -- November 1, 2005 -- DDC-I today announced that the company's initiative to help companies migrate legacy code to new hardware and programming languages is winning support from some of the industry leading defense contractors. Numerous existing customers are asking for assistance in tossing out the old and bringing in the new. Last August, the company announced project-specific Migration Assessment Packages for programs facing this daunting task. Today, customers making this move are seeing successful results for many reasons.

Development tools on outdated hardware can be migrated to newer technology and can drastically improve productivity and future flexibility. For example, SCORE® from DDC-I can instantly offer mixed language, multi-target capability, allowing for easier integration of older programming languages with newer languages, such as Ada83 and C++.

"Our customers know the value of our tool suites and services, and they appreciate how our #1 in Customer Care policy produces customer service which is unmatched in the industry" stated Bob Morris, President and CEO, DDC-I, Inc.

DDC-I's Migration Assessment Package begins with on-site migration needs assessment and application/data/infrastructure evaluation culminating in a complete migration assessment report. Once the assessment is complete, the customer can make an informed choice of how to move forward. They can also choose to do the work themselves, or let DDC-I handle it for them with significant time and costs savings.

[ Back to Top ]

Tech Talk

Optional Arguments of Pragma Import and Export

 

Recently I received a question from a SCORE user. She reported that her program build without incident for both PowerPC and 80x86 bare environments; now she attempted to build it for Windows native but got a failure at link time. What was wrong?

The program included a C source like this

int GET5( int value )
{ ... }

and an Ada source like this

package Imports is
   function Get5( Value : in Integer ) return Integer;
   pragma Import( C, Get5, "GET5", "GET5" );
end Imports;


Cutting to the chase, I'll tell you that the problem is one of over-specification. If you had spotted that already, you know what I'll discuss below.

In the Ada file you have "pragma Import( C, Get5, "GET5", "GET5" );". The first two arguments are required; they specify the interface convention and the imported or exported Ada entity and they can and will be checked by the Ada compiler, so no discussion about them.

The third argument is the external name, that is the spelling used at the source level in the foreign language you are importing from. The fourth argument is the link name, that is the spelling at the assembler level of the symbol you are importing. When you specify both the external name and the link name, the external name is in effect ignored and the link name wins. These arguments cannot be verified by the Ada compiler beyond being string literals so it is up to the programmer to ensure that they are correctly specified.

The Ada package quite correctly specifies (as external name) that the spelling at the C source level is "GET5" (note that casing matters); given a particular C source the external name is the same regardless of which target the C source is compiled for.

The Ada package also specify (as link name) that the external label at the assembler level is "GET5" (casing still matters). The external label resulting from compiling a particular source varies however from one target to another. This phenomenon is best known from the name mangling of C++. The naming conventions of each target determines how e.g. C maps a function name to an external label. Most conventions are one-to-one mappings (typically ELF targets including Solaris, PowerPC EABI and SCORE 80x86 cross); others prefix an underscore (including Windows and SunOS pre-Solaris). Here is the reason why the program links for PowerPC and 80x86 bare and fails for Windows native!

When you interface from Ada to actual C sources you should never need to specify the link name, SCORE Ada will perform the mapping from external name to link name for you. The advantage is that your Ada source is not tied to one particular mapping convention. You should thus write "pragma Import( C, Get5, "GET5" );". This import should really work with any Ada (95) compiler.

So when is link name used? Well, rarely. If you really, really want to import a C++ function directly (without creating a function in the C name space calling it) you might need to write something like "pragma Import( C, PlusPlus, "plusplus", "_plusplus_$ii" );". Note that Ada 95 does not have a standardized interface to C++ as C++ was standardized after Ada 95 (and because it is more complicated since different C++ compilers use different mangling schemes). Note also how non-alphanumeric characters like dollar sign can be specified in the link name (but it is a bad idea making such labels yourself because you cannot use them in C/C++ sources).

So why specify any of external name and link name? To be portable! Sensible Ada 95 compilers will default to something close to "GET5" as external name if neither is specified but this is not standardized (and in SCORE the default for convention C is the local Ada name in lowercase i.e. "get5" which is not what is needed here).

In short: Pragma Import and Export should normally be given three arguments when interfacing to high level languages. If you have two or four then double check!

[ Back to Top ]

In The News

Old Drives Fade Away

By David Mosley

I have an Apple iPod Mini. It has a small, hard drive and holds about 1,000 songs (currently I've only loaded 386; so I still have a lot of room). Now, Apple has brought out the iPod Nano -- no hard drive; flash memory; no moving parts. Very appealing. Of course, RAM is still more expensive than a hard drive; even after getting a big discount from Samsung, the 4G Nano costs $249, while the 30G iPod (with hard drive and video support) costs only $50 more, $299.

This brings us to this month's article by Tom Yager in the October 17, 2005 issue of InfoWorld, aptly entitled, "Hard Disks' Autumn Years." Some years ago a RAM-based storage device was big, hot, loud, and expensive, but it was the future roaring away. There are and have been applications in which a hard drive was inappropriate, and "RAM disks" have been used. Hard drives still flip the magnetic orientation of moving metal particles with an electromagnet. Are you using hard drive cartridges for backup? They need to be handled carefully -- think of eggs.

RAM is silent. It is always on-line. It very rarely grows defects. Even slow RAM runs rings around a fast hard drive, yet it is potentially more power efficient because its power usage characteristics can be changed instantly during operation. In standby mode, RAM only draws the power needed to refresh the charge on memory cells. In contrast, the only thing you can do with a hard drive motor to make it draw less power is shut it off entirely.

RAM today is not where it needs to be to push hard drives to the sidelines. Data written to the platters of well-cared-for hard drives lasts, while batteries eventually lose their juice and whatever RAM they were protecting fades away. Flash memory isn't nearly fast or dense enough to take over for disks in systems, and its lifetime is limited to about 100,000 write cycles. More than tape but nothing compared to a hard drive.

Still memory technology is improving. Some current flash devices can sustain 1,000,000 writes, and we should expect order-of-magnitude improvements to lifetime, density, and performance. Nonvolatile RAM, which places a smaller battery close to each RAM bank can hold its data for an estimated five years. That's roughly the lifetime of a hard drive.

The future will take us to small, fast, multi-terabyte hard drives. Persistent memory storage, however, will proceed on a parallel track to provide options for high-end applications. It is moving toward larger markets even now.

[ Back to Top ]

 

Something to Think About

Humans: The Helpful Species

By Linda Rising
risingl@acm.org
www.lindarising.org

There are so many startling lessons from the recent and on-going invasions by hurricanes in the U.S. The horrifying stories of people who lost everything are shadowed with moving reports of people who helped others, often when the helper was at risk of losing his or her own life or safety. It’s interesting to learn that animals demonstrate this behavior, too. That is, animals and people both help other members of the community even when there is no obvious benefit. Since working on the patterns for introducing new ideas in my latest book Fearless Change, my co-author, Mary Lynn Manns and I have been researching the origins of influence strategies and how we arrived where we are today with respect to making decisions.

At first, it seems that helping behaviors fly in the face of what we learned in Econ 101. I remember being told that we are "profit maximizers," that is, we follow the "what’s in it for me" maxim. Now a new flavor of economics is developing to address the helping phenomenon—it’s called behavioral economics. It’s based on the survival patterns that have evolved with us. Many of these patterns have their foundation in strategies based on cooperation.

The evolutionary biologists among us would say that there is a genetic advantage in these behaviors. If you help members of your family or tribe, then they are more likely to survive. This increases the chances that your familial traits will continue for another generation. But what about those situations where the helper is not closely related to the recipient?

Psychologist Robert L. Trivers has proposed a theory of reciprocal altruism, which states that helping another pays off downstream when the recipient returns the favor. This has been called "tit for tat" and suggests some kind of mental bookkeeping—that we keep track of who helped us in the past. Chimpanzees in the wild hunt in small groups. Observational studies note that one member of the hunting party usually captures the prey, tears it apart, and shares it. But only those who actually participated in the hunt receive food; even the highest-ranking male is excluded (although he may whine about it).

Chimpanzees in captivity when given food in an experiment, also share selectively. The animals who are given a treat by experimenters are soon surrounded by others who hold out their paws, palm upward, as human beggars do. Neglected individuals may complain, but aggressive attacks are rare. When they do happen, the chimpanzee with the food pelts the aggressors with a stick or yells at them until they leave. Regardless of rank within the community, possession is the law.

In a series of observations of grooming incidents that are followed by giving food, the "beggars" who had groomed possessors of food were more likely to receive a share, regardless of rank or connection between the individuals. This suggests that chimpanzees, like humans, show special treatment for those who have been nice in earlier encounters. The system seems to operate differently for those who are close. A similar "buddy" system can be seen in humans, where we reward tit for tat only with those who are not our friends or family. It could be added that keeping score in close relationships is a sign of lack of trust.

In a recent study at Emory University, brain scans have revealed a biological basis for altruistic behavior, with several regions of the brain being activated when players of a game decide to trust each other and cooperate. The game is called Prisoner’s Dilemma. Suppose that you and a fellow conspirator, Albert, are picked up by the police and interrogated in separate cells without a chance to communicate with each other. For the purpose of this game, it makes no difference whether you or Albert actually committed the crime. You are both told the same thing:

If you both confess, you will both get four years in prison.

If neither confesses, the police will still be able to pin part of the crime on each of you, and you'll both get two years.

If one of you confesses but the other doesn't, the confessor will make a deal with the police and will go free while the other goes to jail for five years.

At first glance the correct strategy appears obvious. No matter what Albert does, you'll be better off confessing. Unfortunately, Albert realizes this as well, so you both end up getting four years. If you had both refused to confess, you would both be better off. If you play repeatedly, the goal is to figure out Albert's strategy and use it to minimize your total jail time. Albert will be doing the same. Remember, the object of the game is not to take advantage of Albert. The object is to minimize your jail time. This game can also be played by rewarding players with money or tokens or points.

In two separate experiments, researchers scanned the brains of subjects while they played Prisoner’s Dilemma. Mutual cooperation was the most common outcome in games played in both experiments, even though a player was maximally rewarded for defecting when the other player cooperated. During the mutually cooperative social interactions, activation was noted in those areas of the brain that are linked to reward processing.

The study shows that social cooperation is intrinsically rewarding to the brain, even in the face of pressures to the contrary. It suggests that the altruistic drive to cooperate is biologically embedded—either genetically programmed or acquired through socialization during childhood and adolescence.

Here’s an interesting story about Bill Ernstrom, the CEO of Voyant Technologies.

Ernstrom faced a disconnect in his company: His top engineers weren't listening to his product managers—and vice versa. The company would head down a path, get the engineers excited, they would produce code, and then discover that they could only sell about 10 units.

Ernstrom, an engineer himself, isn't the first high-level exec to watch revenue disappear as a result of the gap between computer geeks and their colleagues on the business side. It happens time and again: In the early phases of projects, when it's crucial to get the technology right, engineers are in the driver’s seat. What they produce, however, is often elegant technology that has no market, is too complicated, or doesn't match customers' expectations.

Ernstrom tried several approaches to get his engineers and product managers to collaborate—everything from recruiting more business people to restructuring compensation. He finally created a new position, chief product officer, and recruited John Guillaume, who had a solid background in telecom. He could throw technical terms around with the best of engineers and still make sense to the less tech-savvy product managers.

Guillaume's first move was to raise the profile of the product managers by involving them in visible tasks, such as writing product definitions and presenting market research. Then Guillaume requested that two of Voyant's top engineers, Warren Baxley and Randy Schultz, lead the product group. Guillaume realized that the star engineers would give instant credibility to the product teams and get the two sides working together in earnest. After a bit of coaxing, Baxley and Schultz accepted the challenge.

As part of the reorganization, the Voyant executive team reconfigured seating arrangements – breaking up clumps of engineers and lumping them together with their product managers and with Baxley and Schultz.

Any of these changes might have accomplished nothing, but together they've gone a long way toward closing the divide. Drop in on a product meeting today and you might have a hard time figuring out who the geeks are. A lead engineer says that he wants the product manager's feedback on an important decision. Meanwhile, the engineers sound like market research pros: Who's our customer base? Are we targeting people like that? We don't want to go to customers and say we're not supporting a feature we used to have.

Ernstrom believes that his customers are happier than ever before. The company has increased sales 25 %, added three more products to the pipeline, improved time to market by 40 %, and reduced research and development costs by 20 %. The cultural healing has persisted, even though Guillaume recently parted amicably. Schultz, the star engineer turned product manager, has helped assume Guillaume's role. It hasn't been easy, but everyone at Voyant now agrees on the goal. As one engineer puts it, "We're building stuff that people use."

Can you see the patterns that were used here? Based on what we know about evolutionary biology and animal behavior studies, these are the same strategies that Mary Lynn and I identified based on our own experiences and those of other successful change agents. The role that John Guillaume played, someone who could talk to both engineers and the business guys, is called Bridge Builder. Many times the great ideas we have are not accepted, not because the idea is bad, but because the idea is being proposed by the wrong innovator. Many times people will only listen to those who have credibility—for them. Finding the right person who has the ear of the target group will help get things going. In other words, it’s all about the messenger.

The other, very strong, pattern in the story is Group Identity. When we see ourselves as a "team" with a common goal, we naturally cooperate. It is in our own best interest to help each other. Whether it’s pulling down cubicle walls or re-arranging offices or buying t-shirts, building a common, shared vision of who we are is a powerful motivator. In an organization we need to see ourselves working together as the Voyant engineer said, "…building stuff that people use." In other words, we’re all on the same side.

I heard this story from a consultant.

One of my clients asked me for a quick fix to a rough peer relationship he had to improve. I asked him if he could give it five minutes a day of concentrated influence. He said, "Sure, I guess it’s worth five minutes a day if I could turn this relationship around." I told him simply to seek common ground with this person—that he shouldn’t push this person at all during these five minutes but should focus on what they had in common and express this commonality directly. I told him that the best influencers can find commonalities between themselves and almost anyone. That was a real challenge for this engineer, a very assertive person. Two weeks later, though, he emailed me to say that although he and his peer still didn’t agree on most issues, their relationship had markedly improved and he could see now that he and his peer had much in common. This was their first step to a good working relationship.

This theme was brought home when I heard a recent radio broadcast. Andre Codrescu was talking about New Orleans’ Mayor Ray Nagin’s proposal to build a light rail system connecting New Orleans and Baton Rouge as part of the recovery effort after Hurricane Katrina. The benefits are obvious, but for non-residents, the reasons why this proposal was not taken seriously until now are as muddy as some of the standing water in the besieged Louisiana cities. Baton Rouge and New Orleans have long been adversaries. The two urban centers have battled each other on all fronts. The short distance (about 90 miles) doesn’t come close to showing the real distance felt by residents who held each other’s city in complete disdain.

Only in the recent wake of Katrina did many thousands of New Orleans’ evacuees discover that the citizens of Baton Rouge were not only generous, but also human, with the same needs and hopes as themselves. Common interests became abundantly clear as well as the years of mutual neglect. Residents of both cities saw that light rail would be beneficial to the entire area, not only to provide easier future evacuation, should that be necessary, but to allow civilized transport for a whole host of reasons. We can all look forward to an era of cooperation based on the new connections and awareness.

Citizens of these two cities realized that they are on the same side— that "they’re all in this together," as Red Green wisely notes at the end of his show. It’s a good lesson for all of us. In our teams and wider organizations, we all know that working together will produce the most powerful results, but we don’t always know how to make that happen. I hope that thinking about the results of these experiments and the work that’s being done by sociologists, psychologists, and biologists, will give you some ideas to apply "on Monday morning." I recently saw something at an innovative company where testers and developers realized that they really were "on the same team" and that their job was to deliver a product that delighted the customer. They were all involved in the same task. They shared a common goal. Working together was the best way to make it happen. It’s amazing how a different view of the world of work can help a team "take off." It’s magical.

Let me know if you see magic happen for you and your team!

References

Clifford, S., "How to Get the Geeks and the Suits to Play Nice," April 2002 Business 2.0, www.business2.com

Codrescu, A., Poet on Call, All Things Considered, NPR http://www.npr.org/templates/story/story.php?storyId=4945326

De Waal, F.B.M., "How Animals Do Business," Scientific American, April 2005, 73-79.

Dugatkin, L., Cheating Monkeys and Citizen Bees: The Nature of Cooperation in Animals and Humans, The Free Press, 1999.

"Emory Brain Imaging Studies Reveal Biological Basis For Human Cooperation," news release issued by Emory University Health Sciences Center.

 

About the Author
http://www.lindarising.org

risingl@acm.org

Linda Rising 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/~manns/intropatterns.html

[ Back to Top ]

 

   

©2005, DDC-I, Inc., Phoenix, AZ - All Rights Reserved - Webmaster@ddci.com

DDC-I, Inc. -  USA - Phone: (602) 275-7172