|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
|
|
Exception Handling (1)
By Thorkil B. Rassmussen
In this and in a following article we will look
at how DACS-80x86 and SCORE deal with exception handling and the
pros and cons of each approach.
The Ada language defines the concept of an
exception and how to handle it. There is a set of predefined
exceptions as well as the ability for the user to define and handle
her own exceptions. Implementations additionally map some hardware
interrupts onto the predefined exceptions, e.g., Storage_Error, when
a null or wild pointer causes an address fault, Constraint_Error,
when a hardware bound instruction fails, or Numeric_Error, when
division by zero or overflow occurs.
But in general interrupts cannot be modeled by
exceptions, since the catching of an exception always brings you
away from the point of the interrupt. Device interrupts are supposed
to be transparent to the code they interrupt; exceptions are far
from transparent.
Ada requires that when an exception occurs, the
exception handlers of the enclosing block (i.e., Ada subprogram,
task, or block statement) must be checked for the appropriate
handler. If the enclosing block lacks an appropriate handler, then
that block is left and the next dynamically enclosing block
is searched, and so on, to the outer most level.
Ada states that exceptions which are raised
during block elaboration or within an exception handler cannot be
caught by that block=s possible handlers. These exceptions are propagated
to the next outer block.
Ada further requires that before blocks for which
actions are pending are left, the actions must be completed before
the handling can proceed. Such actions could be the deallocations of
local collections and waits for inner task completions. Since the
exception handling must be carried out by the runtime system (RTS),
the RTS must be able to find such information as well.
When implementing exceptions in an Ada compiler
system there are several points that must be considered.
Exception identification. An Ada exception
is defined in some Ada compilation unit, e.g., STANDARD, and must be
related to that unit uniquely. However, since the runtime system may
raise exceptions as well, there must be an agreement as how these
exceptions are identified.
In DACS a numbering scheme is used for each
compilation unit (where package STANDARD always has the unit number
zero) and exceptions are numbered systematically within the unit, so
that an exception id is a pair (unit_no, exception_no).
In SCORE® the address of a unique string is used
to identify an exception and a symbol is attached to where this
address is stored. If the RTS needs to raise an exception, it must
use the symbol attached to the string to denote the exception.
The expense of exception handling.
Exceptions may be raised anywhere and caught in specific exception
handlers. When an exception is raised nothing more than the
exception identification and the place of invocation is known - the
rest must be deduced from this information. A solution is to
guarantee that each block creates a machine frame on the
stack. The frame helps the search algorithm find the return address
and block relevant information.
In DACS-80x86 it was a design criterion that
exception handling should not generate any extra code, except for
handler code. Code that is not concerned with exception handling
should not have any additional code that marked the frame that had
to be executed. In order to handle exceptions that are raised during
block elaboration or within an exception handler, there must be a
flag of some kind that can tell where in the block we are at any
time.
The DACS solution was to make a code address
mirror of a compilation unit called the Exception Address Table
(EAT). To find the EAT that is active, the RTS locates the current
frame and finds the return address. A zero return address is used to
signal that this is an inner block, and the EAT must be found by
following the frame pointer chain, until a proper return address is
located. When such is found it is checked that the return address is
indeed the return point for some call instruction.
Here it will be mentioned that the DACS compiler
always uses explicit CALL instructions to call subprograms and never
use indirect calls. SCORE on the other hand frequently uses indirect
calls for purposes such as dispatching that is required in Ada95 as
well as C++. But DACS does not have this need and can therefore use
the EAT approach.
Once known where the call was made this is used
to read the 2 or 4 bytes preceding the point where the call
initially took us, because this denotes the EAT value:
|
|
+-------------+
| EAT-address | entry -2 (16 bit) or
-4 (32 bit)
+-------------+
C--> | code entry | the subprogram starts here
+-------------+
|
|
If a routine does not have EAT information, the
EAT address should be zero. This is for instance the case for RTS
code that does not have any EATs, but still creates frames.
The EAT defines a number of unit relative
addresses (relative to the A_xxxxx_yyyyy symbol defined in the code
start of each compilation unit) with information about what is known
about this address. The value of the A-symbol is written in the
beginning of the EAT. This EAT address information tells about an
address, its block number, dependent tasks, collections declared,
Ada inner block and the presence or non-presence of an exception
handler table (EHT). By looking up the A-symbol relative address
of the point of exception in the EAT, the RTS can do the required
actions and eventually end up with an EHT. This is again an A-symbol
relative address that points into the code and which describes
explicit exceptions being handled as well as the others-handling.
Here the RTS searches for the unique exception pair (unit_no,
exception_no) and may return with a code address to enter or with
instructions to keep on the search for a new handler, as the
exception was not caught here.
Possibly the exception may remain unhandled and
the program or task dies, or a proper handler is found. In the
latter case the stack pointer is moved to the last valid frame
pointer that was not unrolled during the search - this assures that
stack overruns will not happen immediately again, when the handler
is sufficiently >far away=. Handlers typically set the stack
pointer to an explicit value relative to the frame pointer, if such
is known, as their first action.
Though the exception scheme is elaborate and
requires a lot from the compiler with respect to setting up the EAT
and EHT tables, it is in fact quite efficient. The critical area is
where an exception occurs in non-Ada code, both foreign and RTS
code. Therefore the pragma Interface that specifies that a call to
non-Ada is made can be set up to set an RTS flag that informs the
RTS that the >safe world of Ada= was left, with a particular
value of the frame pointer (the Ada code flag). Should an exception
occur, the RTS will start by moving the frame pointer to this point
and thus not risk that the foreign code could not be treated like
the Ada code can. For instance, it cannot be expected that a foreign
subprogram is preceded by a zero-value, and this could be fatal to
the search algorithm and lead to protection faults.
So finding the EAT is a reasonably fast action.
Scanning the EAT depends on the amount of blocks and inner blocks
that are met. The EHTs have to be scanned by any exception strategy.
The test measurements also suggest that exception handling speed is
fair. The added bonus is that the code that does catch exceptions
has no extra code executed for it. The downside is that each
subprogram must have a frame pointer for the search scheme to work,
even though the code in the subprogram may be very brief, because
locating return addresses is crucial in the algorithm.
The contents of the EAT for a compilation unit
with exceptions can be seen in a disassembly of the unit. When no
special actions are needed the EAT is very brief, as the address
information need not be traversed.
EATs are subjects to change, when selective
linking removes one or more of the subprograms present in the
compilation units.
In a later article we shall look at how SCORE®
exception handling is implemented.
 |
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 ]
We're
All in This Together
By Linda Rising
risingl@acm.org
www.lindarising.org
One of my all-time favorite TV shows appears on
public television in Phoenix on Saturday night—the Red Green Show.
During this hilarious program, Red Green, the star of the show,
introduces a monologue with "I want to talk to all you
middle-aged guys out there." He then goes on to offer an
amusing look at getting older and closes with, "Remember, I'm
pullin' for you—we're all in this together." That’s it.
That’s really it, isn’t it? All the advice columns and all the
business books. It’s all about collaboration and cooperation.
Warren Bennis reminds us in many of his interviews and publications,
"None of us is as smart as all of us." All of this sounds
great. We all know how important it is to "pull together,"
but it’s not always easy. Sometimes we’re not sure how to begin,
especially if we’re introverted, especially if others around us
are introverted, especially if we’re so busy—we just don’t
have time to think about what it would take to bring others into our
space. It’s not that we don’t see the benefits. We all know it
would be a better world if we worked together. Wonderful things
would be achieved.
The rest of this article is to help you address
these problems. We need some practical, down-to-earth ways to help
us work and play well together. Collaboration with a capital ‘C.’
The article includes a pattern (with some stories) and another
account from that inspiring book I’ve been talking about The
CEO and the Monk.
Actually, the pattern is just a fledgling. It’s
an example I used as an exercise in a pattern writing class I taught
a few weeks ago. I like to help people learn about patterns by
having them write one and I tell the participants in the class that
when they write patterns, they begin with their own experience. They
begin with a story…
…when I was working on release 4.1.2, we had
a real struggle with some nasty bugs. These bugs would appear in
some installations and not others. It was a challenge to nail down
the source of the problem. So, what we did…"
The audience leans closer. They’ve been there.
They want to know what saved the day.
To show the budding pattern writers how this
works, I tell a story and then we write a sample pattern together.
Here’s the story I told.
In 1803, Talleyrand (Charles Maurice
Talleyrand-Périgord), Napoleon’s Foreign Affairs Minister
purchased Valencay, an elegant castle built in 1540. Talleyrand
was one of the most illustrious diplomats the world has ever
known. He was a master politician. His "job" was to wine
and dine Europe’s celebrities. He had lots of help with this
task, of course, an enormous staff to not only serve, but to
prepare incredible meals for his guests. On a recent trip to
France, I stopped by Valencay and in a tour of the impressive
facilities, I visited the kitchen. There I heard an interesting
story about Talleyrand and how he treated the people who worked at
Valencay.
Early each morning, Talleyrand would visit the
kitchen and join in the gossip and latest news. He knew all the
staff and their family. He would inquire about the health of a
spouse, the career of a son or daughter, or the latest on an
adventuresome cousin. He lent a sympathetic ear to troubles and
joined in celebrating successes. He wasn’t play-acting. He was
genuinely concerned about the people who were part of his life at
Valencay.
Talleyrand not only got a happier staff and,
therefore, better service for himself and his guests, but he also
found that snippets of conversation between visiting dignitaries
were passed along. In those days, servants were
"invisible" and it wasn’t uncommon for state secrets
or covert strategies to be laid out in front of a servant who was
close enough to hear everything. Because Talleyrand treated his
people well, they were loyal to him and to France and were
probably rewarded for this information.
To further support the example pattern, I told
another story—from the modern corporate world.
I was shocked to see a manager at one company
treat the secretaries as second-class citizens. He would walk into
their cubicles and interrupt conversations without apology. He
would demand that certain tasks be done at certain times—usually
at the last minute. He never expressed his appreciation when these
demands were met. As a result, I noticed that the secretaries were
somewhat reluctant to help him—except to meet his stated
requirements. No one ever volunteered anything. No one ever said,
"There’s an easier way," or "I can suggest
something that would help you with this project." They
typically did what was expected and no more. My boss, on the other
hand, was always polite, excused himself when he stopped by a
worker’s cubicle with a request. He took a little time to talk
one-on-one with the worker. In other words, he treated his people
as human beings who were collaborators, instead of lackeys who
were there just to do his bidding. He was more like Talleyrand. He
listened. He learned. Since he involved everyone’s contribution,
he was able to get things done faster and more effectively.
Here’s the pattern we wrote. Do you like the
name?
Name:
We’re All in This Together
Context:
You’re part of an organizational or cultural hierarchy where
some others are your subordinates.
Forces:
People who work together in a hierarchical structure have different
levels of responsibility and authority. Just giving orders with
minimal interaction can sometimes seem the most efficient way of
operating.
You need the support of others to get work done,
but you also need to maintain your position and show strength as a
leader.
You also need to support the efforts of your
superiors. You probably have deadlines and quotas to meet.
Subordinates may not be truthful with you because
they are overly impressed with your position in the hierarchy. There
is a danger that subordinates will only give the appearance of doing
their work, while structuring the outcomes to meet their own ends.
In some cases workers may sabotage your efforts if they are not
fully committed to the task.
Problem:
Individuals have their own personal styles, but sometimes those
higher in the hierarchy treat those who are lower with lack of
respect.
Solution:
Establish a good working relationship with your subordinates.
Treat them as real human beings and engage them in the task
assignment and responsibility. All your subordinates must understand
your vision for the organization and you must have their buy-in.
Relationships built on trust take time and cannot
be called into being "just in time." Make sure that
communication is regular and consistent. Stay in Touch [1].
Good working relationships are the result of
sincere interaction on a personal level and cannot be faked. Use a
Personal Touch [1]. Know the names of family members and pets and
keep updated on any who are ill.
Communication can take place at many levels,
including electronic, but personal connection one-on-one is the most
effective.
Always remember to Just Say Thanks [1], even for
assignments where subordinates might feel they are "just doing
their job."
Resulting Context:
You’ll find that you have more respect from your subordinates and
that they will be honest with you about what is happening in the
organization. They will be more likely to tell you the truth, even
deliver bad news.
You and your subordinates will find that you
enjoy your work more and that good working relationships based on
trust will evolve.
You must remember that you are always walking a
fine line and must be careful to preserve your own dignity and
integrity. Subordinates can lose respect for you if you are too
casual in your interaction or you try to play down to them.
Every member of your organization has a slightly
different view of his personal life. Be sensitive to those feelings
and don’t intrude or make anyone feel threatened if you enquire
about personal details.
Rationale:
Getting things done in an organization is not a one-person task. It
requires the effort of many people working together. The
relationships with people can produce the success you want.
People usually feel happy, important, and
responsible when they are treated respectfully, especially by people
who occupy higher positions in the hierarchy.
You can increase your effectiveness by being
close to your people. You can grow to understand their views and
help them realize that you care about them and their problems.
Known Uses:
My stories of good and bad bosses would go here.
My story of Talleyrand visiting the kitchen each
morning would go here.
A posting on the Internet:
Our facilities manager has a sign on his desk
that says 'Bitter little person.' I guess he understands the view
most people have of facilities people. He is known for going
ballistic when people do anything to the cubicles (or any
furniture for that matter).
I find that good working relationships with
maintenance, facilities, admin assistants, human resources folks,
and others with staff support positions are critical to project
success. As a project manager, I have gone out of my way to
establish those relationships early and often. Sometimes it
involves the distribution of really good cookies (the kind you
eat) or other 'high value' tokens. As a result, lo and behold, a
couple of weeks later some professional cubicle panel removers
appeared and, just as I wanted, removed all of the panels! Now,
everyone is productive and happy. Sometimes you have to meet
things head on and other times compromise is best. Facilities
people and most admin staff have the ability to make your life
hell if you go up hard against them. You might win the battle yet
lose the war.
From a member of the pattern writing class who is
a subscriber of A Word-a-Day e-mail:
disparage (di-SPAR-ij) verb tr.
1. To speak slightingly; to belittle.
2. To lower in rank or estimation.
This week's Guest Wordsmith is Robert W.
Fuller. He taught at Columbia University and served as president
of Oberlin College. His latest book is Somebodies and Nobodies.
Appears Everywhere Except the Dictionary:
Rankism.
In kindergarten, I was put behind the piano on
parents' visiting day for some minor infraction. My mother had to
ask where I was and, even then, the teacher wouldn't let me out.
Later in life, as an ex-college president I noticed that many whom
I thought were friends didn't return my calls, or no longer kept
their promises to me, once I lost my title.
Racism is in the dictionary. It means
race-based abuse and discrimination.
Sexism is in the dictionary. It's gender-based
abuse and discrimination.
Rankism isn't in the dictionary, but it should
be because it's as pervasive and as damaging as the familiar
"isms." Rankism is the abuse of the power inherent in
rank.
Rankism happens every day: a teacher humiliates
a student, a boss harasses an employee, a cleric abuses a
parishioner, or a guard degrades a prisoner.
Rank in itself is not necessarily a bad thing.
Many people have earned their rank and use it to serve others,
however, others "pull rank," using their status to
diminish, even exploit, others. That's rankism. A dignitarian
society is one that disallows rankism.
Authors:
Members of a writing workshop in Houston, Texas.
In addition to this pattern, which you can apply
in your family or organizations, I’m including another story from
the book I hope you’ve all been able to get hold of and enjoy: The
CEO and the Monk. The rest of this article is from Kenny Moore.
Take it away, Kenny!
This is a story from yet another book, a children’s
book, written by Eileen Spinelli. The book is Somebody Loves You,
Mr. Hatch. It’s a story about an introvert, an isolated
working man, who lives and works alone. His neighbors said,
"Mr. Hatch likes to keep to himself." One Saturday the
postman delivered a heart-shaped box of candy with an anonymous
note: "Somebody loves you." Mr. Hatch was confused because
he interacted with no one. He finally concluded, "I’ve got a
secret admirer." Mr. Hatch began to change, dressing up and
walking the streets of town, greeting and helping strangers—all
with the hope of meeting the person who sent the candy. He baked
brownies, served lemonade, and played an old harmonica that he had
from his boyhood. Children were drawn to him. Everyone danced. Time
passed. Mr. Hatch had so much fun, he forgot about his secret
admirer.
Then one morning, the postman returned informing
Mr. Hatch that he delivered the candy to the wrong address and took
back the now-empty box. The "Somebody loves you" note fell
out in the transfer, reminding Mr. Hatch that he was correct at the
outset: nobody loves him. He started to withdraw back into his
isolation. But the children wouldn’t have it. The neighborhood
revolts: "We can’t let this happen to Mr. Hatch" ... and
they don’t.
The story left me thinking. What would happen if
Mr. Hatch showed up in corporate America? What havoc might be
wrought by small gifts, anonymously given to an ordinary worker? I
decided to find out.
My plan was to anonymously send a floral
arrangement to two unsuspecting employees every Monday morning—a
Mr. Hatch Award. Attached to the flowers would be a note: "Don’t
ever think your good efforts go unnoticed." Signed: "From
someone who cares." The business world has taught me to always
do a "pilot" before you jump into full implementation. I
also learned that it’s better to ask forgiveness than permission,
so I kept the idea to myself and got no formal approval. For my
trial run, I picked an employee who worked on my floor and my Senior
Vice President. I’ve noticed that no one ever says "thank
you" to executives. Granted, they do make mistakes—but they
also do some good things—for which they seldom get credit.
On Monday morning I walked down to the florist
who handles our corporate account. She showed me a small bowl with
five petite flowers in it. (Their overhead must be high.) I told her
I wanted to send two arrangements and to ensure anonymity, I would
pay cash and would not sign my name or leave my phone number. The
florist was extremely uncomfortable with this. I wasn’t feeling
too happy about the transaction either. Maybe this is how all pilot
projects feel? By that afternoon, the flowers arrived. I said
nothing.
On Tuesday I made it a point to pass by the desk
of the woman who worked on my floor. I said: "Hey, nice
flowers. Is it your birthday?" "No" she said.
"Somebody sent them to me. Look. Here’s the note." Her
co-workers crowded around, telling me the strange turn of events.
They also knew that an executive got the same flowers. One of them
had even called the florist to find out who sent it, but no one
seemed to know. They continued to speak in utter giddiness about the
strangeness of the delivery and wondered what made this woman so
special. They also spent considerable time trying to understand what
she had in common with the executive. As I left, they continued in
frenzied conversation and merriment.
A few days later I had a project-update meeting
with my Senior Vice President. I planned to tell him about my pilot
and get his reaction as a recipient. Before I had a chance, he said:
"You know, Kenny, last week someone sent me flowers, thanking
me for something I did. I’m not sure who it was, or what I did.
But it got me thinking. I only have a few more years before I retire
and I think I’d like to use that time focusing on individual
employees, their needs and concerns. I know it’s impractical—we’ve
got 13,000 of them. But I’d like to give it a try." Gulp! Now
I felt both trapped and embarrassed. How could I tell him that I had
sent the flowers—that he was just part of a pilot? He had created
a worthwhile executive goal and I didn’t want to knock it off
track. I kept my mouth shut, gave my project update, and exited as
fast as I could.
These two encounters made me want to continue my
plans. Even though the company knew nothing about the program, I
believed they would support it. If I can give an employee a $5,000
on-the-spot award for customer excellence, a small amount for
flowers is not going to break the bank. The pilot even taught me a
few lessons: (1) run the program on my own and forget about formal
corporate support; (2) keep the anonymity of the program and (3)
ditch the corporate florist.
Next Monday I moved into full implementation. I
chose two more workers, but instead of the corporate florist, I
walked a few blocks into the combat zone of downtown Brooklyn and
found an all-purpose store. The proprietor sold a lot of things,
including flowers. I said to him: "Here’s my offer. Each week
I want you to deliver two floral arrangements to my headquarters. I
want a "thank you" balloon attached along with a note that
I’ll give you. You put the note in an envelope and deliver it
all." "OK with me," he said. "I’ll pay cash.
You don’t contact me. I only contact you. I’ll show up every
Monday with the names, notes, and money." Unlike the corporate
florist, he had no problem with this arrangement. Apparently, he
does a lot of business this way. "One final question," I
said. "What can I get for my money?" "Give me a
minute," and he disappeared. He brought back a massive array of
floral specimens: birds of paradise, tulips, roses, babies’
breath. I think I got half of his storefront display. "Looks
fine to me. Do a good job and I’ll come back every week."
It’s a year later and I’m still sending
flowers, anonymous notes, and balloons. My company still knows
nothing about it. Have I changed our corporate culture? No. Was I
able to get everyone together, tell them the business plan, and
demand that they believe and implement the Mr. Hatch Award? Hell,
no. But here’s what has happened:
1. I actually look forward to coming to work on
Monday mornings.
2. A small number of employees go home Monday
night with a smile or quizzical look on their faces.
3. Co-workers are having a blast trying to figure
out who’s sending flowers to their friends, what for, and how
come. I suspect a few dream of receiving flowers and a balloon for
themselves.
4. One aging executive is making retirement
preparations by meeting individually with employees. While this is
the least verifiable part of the program, I trust that the S.V.P. is
making the effort.
5. I’ve got a proprietor in downtown Brooklyn
who smiles when he sees me coming and warmly shakes my hand. I also
have the feeling that the storefront area is a bit more revitalized
than it was a year ago.
That’s the present state of the Mr. Hatch
Award. I’ll probably keep it up until I read another children’s
book that leaves me feeling hopeful and alive. Then I’ll
experiment with another idea. Maybe something based on The
Velveteen Rabbit or Ira Sleeps Over.
Some well-meaning executive might read this
article and try to establish a corporate Mr. Hatch Award. Forget
about it! Not everything needs to be imitated and mandated into
business policy. Some things work just fine when they’re small,
personal, and unique. There’s organizational strength in
fermenting a mixture of the institutional along with the
idiosyncratic. Executives would be better served by encouraging
staff to "hatch" their own ways of nurturing the corporate
common good.
Kenny Moore (kmoore@keyspanenergy.com) is a
former monk and present day businessman, improvising his way through
the work-a-day grind. He’s co-author of The CEO and the Monk:
One Company’s Journey to Profit and Purpose and
Director of Human Resources and Corporate Ombudsman for KeySpan.
Kenny has survived "incurable" cancer and open heart
surgery - largely due to luck and Divine playfulness. Having dealt
with both God and death, he now finds himself eminently qualified to
work with executives on corporate change efforts.
References
1. Manns, M.L. and L. Rising, Fear Less: and
other patterns for introducing new ideas into organizations,
Addison-Wesley, 2004.
 |
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 ]
|
