|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
|
Unsigned Numbers in Ada83(2)
By Thorkil B. Rassmussen
As discussed in a previous article, working with
unsigned numbers in Ada83 does not always provide an efficient
implementation. In Ada83 the concept of a type being an unsigned
number exists only by constraining the larger signed type that
encompasses the unsigned range, as in:
type Unsigned16 is
range 16#0000# .. 16#FFFF#;
This type may be allocated in 16 bits, but is in
fact a constraining of the 32 bit signed integer type, and to work
properly operations will be performed on the 32 bit signed type and
range checked before, e.g., assignment. This has the consequence
that an addition of one to the value Unsigned16=Last
will result in CONSTRAINT_ERROR being raised, as the result
16#10000# is outside the range of Unsigned16. It may be confusing
that with checks off the result of such an overflow condition
sometimes gives the value 16#0000# and sometimes 16#10000#,
depending on whether the destination variable is 16 bit or 32 bit in
size. A solution to this problem is to make a MOD operation:
Uns16Obj + 1) mod
16#10000# B<<
notice that 16#10000# is allowed here
The Ada95 answer to this is to use the modular types
that automatically >wrap=
and stay within the required representation bits.
As unsigned numbers require the use of the next
higher signed type in Ada83, the choice for some special uses of
unsigned numbers is critical. An example of this is the choice
DACS-Ada83 compilers make for the System.Address type. There are two
cases that are considered: the segmented targets (8086/80186/80286
and 80386 and up in protected mode) and the flat targets (80386 and
up in flat mode, including Native mode).
With the segmented targets an address is a two
component structure mirroring the addressing being a 16 bit selector
value and a 16/32 bit (unsigned) offset value. The offset part is
therefore implemented as an unsigned 16 or 32 bit type, using the
rules above. Inside the SYSTEM.ADDRESS record structure 16 or 32
bits are set aside for the value, but calculations on the offset
will be done in the higher signed arithmetic automatically. The
programmer need not take any precautions here.
With the flat (32 bit) targets such as PC/Native, an
address type would be expected to be a 32 bit unsigned type, but
such a type does not exist. Using the same strategy as for segmented
targets, but leaving out the selector field, would make the address
type a record type, and passing records to other languages would
then pass the address of the record, which will be the address of
the address. Passing the content (the offset field) would force
passing the full 64 signed integer value, and that is not what you
would expect. Therefore the address type has been defined as a type
which is a NEW INTEGER. Addresses are then same sized as access type
and will be passed as 32 bit entities. The drawback is that a signed
integer does not act properly as an unsigned integer.
The remainder of this article will show some
techniques that using the Integer type may be used to work with the
signed 32 bit integer as an unsigned value. We will only deal with
simple arithmetic such as A+@
and with comparisons other than A=@
and A/=.@
When adding to an address there may only be a
problem, if the result ends up with another sign. For instance a
value such as 16#7FFF_FFFF# will give an overflow in signed integer,
when adding any value > 0, and a value such as 16#FFFF_FFFF#
would give a wrapped result, when adding any value > 0. The easy
response to this problem is to have checks off with such operations,
which may be achieved for these operations only by declaring an
inline function AUnsAdd@
that suppresses checks for overflow and use these:
function UnsAdd
(op1, op2 : integer) return integer is
pragma suppress(overflow_check);
begin return op1 + op2; end;
pragma inline(UnsAdd);
However, in most cases addition is not a problem,
but rather the comparisons.
The trouble is that the unsigned 32 bit value in its
top range (>=16#8000_0000#) have values that are signed negative,
and when comparing to another unsigned value the test will only go
well, if both values have the same sign. This is because both the
signed and the unsigned compare identically with values solely in
the range 0..16#7FFF_FFFF# or solely in the range 16#8000_0000# ..
16#FFFF_FFFF# (the signed subrange Integer=First
.. -1).
With different signs the higher value is ALWAYS the >signed
negative= value, because
this range for unsigned is the higher range. We may therefore use
this to implement the A<A
operation:
function UnsLess(
Op1, Op2 : integer ) return boolean is
begin
if ( Op1 < 0 ) = ( Op2 < 0 ) then
return Op1 < Op2; -- same signs:
simple compare
else
return Op2 < 0; -- diff signs: the
negative is higher
end if;
end UnsLess;
By inlining this function the overhead may be
reduced.
If a hand-inlining is required, a variable holding
the same signs situation is preferable:
Same_Signs := (
Op1 < 0 ) = ( Op2 < 0 );
if ( Same_Signs and then ( Op1 < Op2 )) or else
(( not Same_Signs ) and then (Op2 < 0 ))
then -- less case
...
The similar comparison functions can be modeled
after the above, where the conditions for the same signs remain
unchanged, but the two other conditions ( Op1 < Op2 and Op2 <
0 ) change according to the relation requested.
A more intricate solution is to use the XOR boolean
operator on conversions between Integer and a packed array of
boolean of size 32. Each operand is XOR=ed
with the bit pattern 16#8000_0000# which has the effect of swapping
the unsigned range with the signed range after which a signed
comparison will compare correctly. The drawback is the extra
overhead of conversions:
type Bits32 is
array(0..31) of Boolean;
pragma Pack( Bits32 );
function Mk_Bits is new Unchecked_Conversion( Integer,
Bits32 );
function Mk_Intg is new Unchecked_Conversion( Bits32,
Integer );
Bits_Sign : constant Bits32 := Mk_Bits( Integer'First );
function Unsless2(
Op1, Op2 : integer ) return Boolean is
begin
return Mk_Intg( Mk_Bits( Op1 ) xor Bits_Sign ) <
Mk_Intg(
Mk_Bits( Op2 ) xor Bits_Sign );
end;
pragma Inline( UnsLess2 );
Finally converting ADDRESS values to
Unsigned_Pack.Unsigned_Intg and use the Unsigned_Pack comparisons is
a simple and efficient solution.
 |
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 ]
Even More Patterns (for introducing change)
By Linda Rising
risingl@acm.org
www.lindarising.org
This will be the last article of three in the DDC-I
Newsletter on patterns for introducing new ideas 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. You can find an early version of the
patterns here:
http://www.cs.unca.edu/~manns/intropatterns.html
Let’s start this article with a good story! I
received an e-mail from an old friend a few days ago. He knows that
I’ve written three books and have another in progress and he’s
thinking about writing one and asked my advice. We exchanged some
e-mails. He asked about the format for the proposal and
whether he should have most of the book written before he contacted
the publisher and if his idea was too broad or whether he
should focus on just one part of it and…. Finally, I said,
"Brad, I’ve got a great pattern that you might think about
applying at this point in your writing adventure. It’s called Just
Do It!"
In product development, Brad’s state is often
the death knell for complex projects. It’s called "analysis
paralysis." We engineering types love to wallow in details. We
love to plan out our strategies to anticipate every problem before
it occurs and (here comes the killer), we strive for perfection.
Someone once explained to me the difference (because we often get
them confused) between perfection and excellence. Someone striving
for perfection strives to make things "perfect," that is,
without errors. Someone striving for excellence knows that it’s
impossible to avoid mistakes. Edison knew this. He said, "The
secret is not the 71 times you fail, but to persevere to the 72nd
time, in which you succeed." Gandhi observed, "Only a fool
expects perfection. A wise man seeks learning." And the way to
learn? Take a step on the path to your goal. As Goethe observed,
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power, and magic in it." Just Do It.
This is especially true now, during the chaotic
upheaval of change and transition we are all experiencing. If you’re
interested in innovation and taking on the role of a change agent,
you will likely make more headway pursuing excellence than
perfection. So, my advice to Brad, the writer, and to all of you
interested in introducing new ideas into your organizations, Just Do
It. You don’t have to do it all, just take Goethe’s advice and
begin it. Just stick a toe in the water. Once you begin, take time
to learn from your experience and use the pattern Step by Step to
reach your goal of excellence. The result will be excellent, because
you are learning, not because you’ve planned it all out.
What are good ways to Just Do It if you’re a
change-agent-wannabe? I’m happy you asked! I have a few good
patterns for you! The first is Brown Bag. Most of the folks you work
with these days have little time to hear about your new idea. But,
there’s still lunch. In the middle of the day, when many of us are
eating at our desks and catching up on e-mail, we might just make
room for a gathering to hear about an intriguing topic if we can
bring our lunch and use the time to do at least two things at once—eat
and learn! As one company advertises their Brown Bags:
"OK, you´ve heard of food for thought? Well, how about
Food AND Thought?"
You can plan an informal presentation, after all,
you’re just learning about this topic yourself, but remember the
Evangelist pattern. This is a chance to show your enthusiasm and
engage others.
To make the pattern Brown Bag even more powerful,
invest more than your time and pony up for some really nice
chocolate chip cookies. The pattern is called Do Food, and recommends using food because it is a
powerful influencer. In her article "Seven Secrets to
Good Brainstorming" Linda Rischler wisely observes,
"Cookies always spur creativity." Research has shown that
people are more favorably inclined to ideas that are presented while
they are eating. Think of it! You can get the world on your side
with the right snacks! Sharing food has long been associated with
building friendship and community. In French, the word "compagnon"
means "companion" or "people belonging to the same
community of craftspeople." The Latin origin of the word means
"sharing bread." There is no better way to build a
community and get your change effort going than to hold an informal
meeting and buy cookies or some other treat. Try it.
While you’re having your Brown Bag and passing
around the cookies, if you have copies of a recent article about
your new idea, you can share these with interested participants who
want more information. Books are also good. Even though we don’t
have time to read a book, just seeing that the book exists and
having a chance to leaf through it adds credibility to your
presentation. There are two patterns at work here, Plant the Seeds
(spreading around the articles and books as "seeds" to
grow interest) and External Validation. Books and articles are
especially influential if they are authored and published by sources
that mean something to the participants. If the author writes about
the success of your new idea in an environment that is familiar, the
report speaks more clearly to your readers. If you can find an
article about the experience of a competitor, that would be a really
powerful "seed" to plant!
After your Brown Bag, you might be able to
identify a handful of colleagues who would be willing to invest some
more lunchtimes to learn about the new idea. An inexpensive yet
effective way to do this is to use the pattern Study Group. As
famous psychologist Carl Rogers has observed, "The only kind of
learning which significantly influences behavior is self-discovered
or self-appropriated learning - truth that has been assimilated in
experience." This is especially true for adult learners.
I have co-authored an article about one company’s
success with study groups. It was published in the Bell Labs
Technical Journal and can be downloaded from my web site. Joshua
Kerievsky, another well-known pattern writer, has another useful
source of information for this effective learning activity. See Knowledge
Hydrant: A Pattern Language for Study Groups
http://www.industriallogic.com/papers/khdraft.pdf.
Study Groups are interesting learning models
because no expert is present. Each member of the group takes turns
leading a session and preparing a "lesson." When eight
people read a section or a chapter, it’s astounding to see the
eight different interpretations that show up at the meeting. Even
more astounding is how much you learn from hearing the different
views of your colleagues. It’s bootstrapping at its best! I’ve
known many companies that sponsor Study Groups. The company buys the
books and, in some cases, also buys lunch for the participants.
Spreading out the learning over several weeks means that
participants have time to digest the new approach. I once heard
someone call training sessions like "Trying to drink from a
fire hose!" When a Study Group takes a chapter a week and
rotates the role of leader, the learning is less hectic and the
slower pace means that there’s time for insight to develop. It’s
also cost effective compared to in-house or off-site training of any
kind.
Finally, as you consider applying these patterns,
there’s one more to keep in mind called The Right Time. There are
always better times than hitting a team right before a deadline, for
example, or anyone in an academic setting (student or teacher) at
the end of a semester. Mary Lynn tells the following story:
Our first event about a new idea was held at the start of the
semester. The second one was held at the end of the semester, just
after grades were due. Both events were well attended. Attendees
were excited about continuing the workshops. But when the third
event was scheduled during the fourth week of the semester, just
as the workload was heating up, it had to be cancelled due to lack
of responses.
This simple recommendation can help you in the
beginning when you are sensitive to the constraints of your target
audience. As you venture forth into the larger organization, it may
not be possible to always consider timing, but certainly December in
almost any organization is not a good choice. As the Cowboy’s
Guide to Life wisely notes, "Timing has a lot to do with the
outcome of a rain dance."
I hope you’re not patterned-out by now! I hope
you’re intrigued by these patterns. Mary Lynn and I have been
working on them for several years and have based our findings on the
experiences of many people across the globe. I’m always learning
more about the patterns, so I welcome your comments and "known
uses." Thanks for reading!
 |
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 September 2004. |
[
Back to Top ]
|
