• TADS Sun/Solaris Upgrade - Now Available
• Updated Version of DACS IDE - Now Available
• Thoughts from Thorkil - Unsigned Numbers in Ada83(1)
• A Few More Patterns - For Introducing Change

DDC-I Updates Sun/Solaris-Hosted TADS Development System

Phoenix, AZ — March 1, 2004 — DDC-I is pleased to announce the release of a fully updated Sun™/Solaris®-hosted TADS Ada Development System (TADS). This release incorporates the full complement of improvements and enhancements integrated during the now-completed TADS for PC/Windows® rehosting development effort. After releasing TADS-1750A in November 2003, TADS-i960 and TADS-68xxx are scheduled for full release in March 2004.

"Offering our TADS customers consistent performance across the full range of hosts and targets is the best way to support changing needs. Whether they plan to rehost using a PC/Windows platform, perform regular program maintenance, port legacy code using existing Sun/Solaris resources or any combination of the above, all variants are now uniform" explains DDC-I Senior Software Engineer Michael Hash.

Specific enhancements include: improved compiler symbol management, enhanced internal consistency to facilitate program linking; enhanced and generalized serial communication connectivity of the AdaScope debugger (for better compatibility with standard serial port expander boards in the host computer); improved handling and resolution of internal compiler errors, as well as improved machine code insertion of 1750A assembly instructions into Ada source code.

A mature solution for each target, TADS offers classical, Ada specific and target specific compiler optimizations to deliver performance benefits tailored to processor architecture. TADS generates the most compact code available via highly optimizing compilation, selective linking and modularization of the run-time system.

"Many aerospace, avionics, defense and other customer programs still depend on TADS safety-critical real-time embedded system development," Hash concludes," and DDC-I's philosophy of ‘#1 in Customer Care’ focuses on providing the best possible software tools for every client, coupled with superior engineering services and customer support."

Thoughts from Thorkil

Do you have a topic you'd like Thorkil to write about? Click here to send a request.

Unsigned Numbers in Ada83(1)

By Thorkil B. Rassmussen

Programs often need to manipulate objects that are unsigned, 8, 16, 32 or perhaps 64 bits wide. While C defines unsigned numbers as part of the language, Ada83 does not really address the issue, and Ada95 has introduced the modular numbers concept that in many respects is a generalization of the C unsigned numbers.

In Ada83 you may define unsigned ranges, as long as a larger signed integer type can encompass the unsigned range requested. The idea is then that you can use the signed arithmetic of the larger signed type, and when assigning the result check that the result is within the unsigned constrained range, again using the signed operations for the test. This may appear as a sound way of addressing the unsigned issue, but it has a very important drawback which is that you may be forced to use arithmetic that is not readily supported by the machine in question.

Let us take the example of a 32 bit 80x86 processor, e.g. a 386 / 486 or Pentium, where you need to have unsigned 32 bit objects. In Ada83 you would be forced to use something like this:

    type Unsigned32 is range 0 .. 16#FFFF_FFFF#;

You may add a representation clause to force objects to reside in 32 bits:

    for Unsigned32'SIZE use 32;

but there is no way around that this type is a subtype of a 33 bit signed type, and since no such type typically is available, the next step will be a 64 bit signed type (or Long_Integer), This type requires two 32 bit registers to hold a value, and may need RunTime support for more complex operations such as multiply or divide/rem/mod. So, all in all, the price of using the Unsigned32 type may be comparatively high. The 80x86 processors have unsigned machine instructions, both for arithmetic and for comparison, which would be much more efficient to use, even if the request for proper detection of overflow should be observed.

Arithmetic operations with second operand being a power of 2 will for multiply and divide be handled using shifts, and for mod and rem using bit masking.

An unsigned range starts at 0 and runs through all the signed type's positive values, until the largest positive value is encountered. Its follower is then the signed type's smallest negative from where the range continues up to the largest value for an unsigned type which is all ones or -1 signed. For the 32 bit signed type this means that the signed values that represent the unsigned range are in this order:

    0, 1, ... , 16#7FFF_FFFF#, 
                              -16#8000_0000#,
                              -16#8000_0001#, ..., -2, -1

An important attribute is that both the 'positive' and the 'negative' subranges are ordered, and that any 'negative' value is larger than any 'positive' value.

To address the unsigned issue, DACS-80x86 for Ada83 added the Unsigned_Pack package that provides a true unsigned 32 bit type with all the arithmetic and comparison operations, plus conversion operations that convert values to and from LONG_INTEGER type. The type provided is simply a "new INTEGER" type, that is a signed 32 bit type used to 'host' the unsigned value, but otherwise use true unsigned machine operations in the generated code which additionally is inlined for maximum efficiency. An inconvenience is that you need to either specify the operators explicitly, such as Unsigned_Pack."*"( ..., ... ), or add a USE clause to Unsigned_Pack, because the operators otherwise would not be directly visible.

Following the same lines the 32 bit DACS-80x86 compilers also come with a package Unsigned_Short_Pack that defines a similar 16 bit unsigned type.

For the 8 bit unsigned type there is usually not any problems of either using the nearest 16 bit signed type or even the 32 bit signed type for the arithmetic, though again using a true 8 bit unsigned type would be preferable.

For 32 bit targets a 64 bit unsigned type is impossible to achieve in the prescribed manner, since this would require a 128 bit signed type, which is not available. So for these choose a range that stays within the signed upper limit, so that the arithmetic and comparison can use the 64 bit signed operations, even though this is not a perfect choice:

    type Unsigned_64 is Long_Integer
    range 0..16#7FFF_FFFF_FFFF_FFFF#;

In an upcoming article the problems of handling unsigned types, where only arithmetic involving add, subtract, and comparisons is needed, and using their signed counterparts will be discussed.

About the Author Thorkil Bjørn Rassmussen has worked with DDC-I for over 20 years. He has a Master of Science, Computer Science, from University of Copenhagen. Thorkil has substantial experience with all of the DACS tools and is the key individual involved in all FAA certifications for the DACS product line. Thorkil lives with his wife Jane and two children Jonas and Tine, just outside of Copenhagen, Denmark.

[ Back to Top ]

A Few More Patterns (for introducing change)

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

I’ve received some interesting responses to my last article, A Few Good Patterns (for implementing change), so I’m encouraged to give you another small package of patterns from a book that Mary Lynn Manns and I are writing. The book will appear in September of this year. The working title is Fear Less: Patterns anyone can use to introduce new ideas.

Let’s start with a good story! I was attending a conference recently, listening to a very compelling speaker talk about his discouraging experiences trying to introduce agile software development practices into his organization. He all but described himself as a Don Quixote, doing battle against the fierce "old-style-process" windmills. I thought that at any moment he was going to break into song, "To dream the impossible dream…" but instead he seemed to be saying that his effort was wasted, that people didn’t appreciate what he clearly pointed out to them as "The Way" to solve their problems. Only he, in his infinite wisdom could see the path clearly.

Yes, it’s easy to get carried away. Yes, we know that to introduce a new approach, you’ve got to be enthusiastic and apply all the sales techniques you can muster. Yes, there will be dark days; two steps forward and one step backward. But playing the lone hero role is not the way to win friends and influence people.

Since Mary Lynn and I have been working on our patterns for several years, it was all I could do to stay in my seat and not jump up to say, "Did you ask anyone for help?" The presentation used up the question period, so I resolved to talk to him later. I was not surprised to learn that no, he had not asked for help. It’s surprising how many change agents make the mistake of trying to go it alone. Somehow, it adds to the challenge, but it’s not the strategy that leads to successful introduction of new ideas.

The pattern we call "Ask for Help," outlines the reasons for bringing in others. The risk with introducing anything is that you can get caught up in the passion you feel for your vision and pretty soon others see this as "all about you." From the beginning, enlist others to avoid this trap. In fact, you may have to hand over some credit for the idea in order to get it going. If you truly believe that adoption of the new approach is the right thing to do, this should be a step you are willing to take.

The other critical component of the pattern is ownership. Here’s another story. How many meetings have we all attended where a proposal was made and the rest of the meeting time was spent hashing and re-hashing the details, re-casting elements to essentially produce the same thing. "Why," we wonder, "do we have to re-word and re-state and argue over things that really don’t matter? The end result is always pretty much the same as it was when we started!" The answer is—ownership. People resist change because of many reasons, but one powerful way to overcome their resistance is ownership. When people feel that they have contributed to the implementation, even in a small way, they have "marked"—yes, just like dogs do—the new thing so it’s theirs. They want to have input. Instead of having new stuff forced down their throats, they want a say in what happens and, especially, how it happens to them.

The analogy I once read is this. Most of us like to re-arrange our office furniture or the way we organize the stuff on our desks, every now and then, when it suits us. But, what if we lived under a repressive organizational regime that appeared unannounced and, while we were at lunch, moved all our stuff? Whoa! That’s scary! No one would like that! We like change when we’re in control. We don’t like change when it’s forced on us.

So, as a change agent, take the time to Ask for Help. Not only will others not see the idea as "all about you," but they’ll be able to take ownership of some of the change effort.

Last, but not least, of course, is that every person you bring in will help you understand the impact of the idea, how it can be improved to help the organization, what other techniques you might apply to get the innovation going in your environment, the pool of ideas for making this a successful story will improve with every new person you bring in. Such a deal!

I hope I have convinced you to Ask for Help! There are some special people you might target. First, the Connectors. Malcolm Gladwell wrote a very interesting book called The Tipping Point, where he describes three important roles for making real change: Mavens (people with knowledge), Salesmen (obvious), and Connectors. The people in the last group are valuable assets because they know "everybody." Well, at least they know a lot of people! They are members of several diverse groups and can spread the word about anything very quickly. In most organizations, secretaries, especially those who have been with the company a long time, are valuable people to get on board. They are the ones who make things happen and they know the people and the people who know the people. Be very happy to have them on your side.

Another small group or, in some organizations, a single person, is described in the pattern Respected Techie. I like to call him "Fred." When Fred is on your side, others will listen. Here’s how you approach him. "Fred, I’ve just read an article about <Big Idea> and I know you have probably heard about it. What do you think about how it would work for us? I’ve been thinking I might have an information meeting (we call this a Brown Bag) to tell our team about it. Would you be willing to show up and add your input? Here are a couple of things I think would be good to share – blah, blah, blah." Keep it low key. Keep your approach humble. Never threaten a Respected Techie. Never make him (I keep saying "him" but, of course this person could be a "her.") feel that you are trying to take over in some way. Power is always an issue! Your goal is to win Fred’s support. In some organizations what Fred says can make or break you. If he shows up at your meeting and nods a couple of times, you’re set.

Never forget the help you get from Connectors or Respected Techies or anyone else who joins your team. The pattern Just Say Thanks is unbelievably critical. We forget how important this is. I lead project retrospectives for organizations. One of the exercises I use is from Norm Kerth’s excellent book called Project Retrospectives. The exercise is "Offer Appreciation." In it, team members simply say to each other, "Fred, I know you’ve spent the last three months working overtime and week-ends to get this product out the door. I just want to say thanks for that. I appreciate your hard work." Then someone else will offer an appreciation. It gets going. It has a life of its own. It’s so wonderful to be in the middle of that. We don’t need to wait until a retrospective at the end of a long delivery schedule. We can do that everyday and the difference it will make in your life is hard to explain to anyone who hasn’t seen it. It costs so little and the return is so great. Just Say Thanks!

OK, that’s your gift for this month. If you have some known uses for any of these patterns, I would love to hear from you. I’ll send you another package next month.

Enjoy!

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. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in 2004.

[ Back to Top ]