|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
|
Date, Time and Ada (2)
By Thorkil B. Rassmussen
When an application needs to display date and
time or maybe just keep track of time spent, it can usually rely on
the Operating System to provide such services. There is typically a
system call to get the internal system time value, and another
system call to convert that to year, month, day, hours, minutes,
seconds and fractions. Also the OS has the task of maintaining this
internal system time.
In embedded systems this job is left to the
application. In Ada the package Calendar provides an implementation,
and each embedded Ada system may have its own internal
representation of system time. There are some hard requirements on
the amount of information needed: the year range from 1901 to 2099,
as well as a reasonable resolution on the order of 100 usecs is
often needed.
The embedded kernel must maintain internal time
by responding to either timer interrupts coming at regular intervals
or specifically programmed timer interrupts, where time in between
is read by determining residual counts, before the timer interrupts
‘fire’. The latter is somewhat more elaborate to implement, but
has the advantage that the amount of cpu time the kernel needs to
maintain system time is reduced to when it is really needed, and
reading the system time additionally requires more than just reading
a kernel data area, but also evaluation of residual time.
In the majority of the DACS-80x86 systems time is
updated on a regular basis - every 1 msecs typically (user
definable). This poses an interesting problem: since time progresses
only every 1 msec, reading the time cannot tell you, if you are in
the beginning or the end of a period. Therefore a request for a
delay of the smallest possible value has to wait for at least 2
timer interrupts to ‘fire’, the first could be immediately after
the delay-request, the second guarantees that you have waited
enough. The result is that the wait in average will be 1.5 msecs, if
you ask for 60 usecs. Only by spending time reading the residual
timer unit counts could this be avoided.
An embedded system further has the problem of
setting a reasonable date. The application could choose to set the
date to its own preferred value, but this often becomes a date
selected by a programmer at the time of writing this piece of code,
and will then continue being March 31, 2002 forever. With the PC and
compatible boards there is usually a real time clock available that
is kept alive by a board battery and just ticks on and on. The board
configuration code or user configurable code (UCC) for PC boards and
other boards with a real time clock can set the system time as part
of the board initialization, using the real time clock values. The
resolution is typically seconds, but year, month and day are readily
available, and setting the internal system time to that will be a
good starting point. The SCORE-80x86 UCCs that have real time clocks
do this automatically, and the DACS-80x86 UCCs can similarly do
this.
When done during board initialization this may be
in vain with DACS however, because the elaboration of Calendar’s
specification always sets up a specific date thus overwriting the
initial setting, so the real time clock setting must await the
elaboration of Calendar.
So how is internal system time represented? The
DACS-80x86 systems use an unsigned 48 bit counter that counts in
units of the type DURATION ( 2**(-14) secs = 61 usecs). The timer
interrupt adds a number of DURATION units to the 48 bit counter and
this number is calculated from the timer frequency and the
resolution of DURATION, so that the added value to the system time,
when a timer interrupt occurs is the amount of DURATION units the
frequency represents - for a 1 msec timer period this value becomes
16.
But there is a step from having a 48 bit value
with a resolution of 2**(-14) secs to year, month, day, seconds and
fractions of seconds. The fractions are easily dealt with as the low
14 bits of the time gives us those - the total number of seconds are
then obtained by shifting the time value 14 bits to the right. The
number of bits is then reduced from 48 to 34. Calendar requires a
starting date at January 1, 1901, and a large range for dates, i.e.,
200 years. In Unix systems the starting date is January 1, 1970, and
the counter value is unsigned 32 bits, but since many programs use a
signed type for the counter, effectively 31 bits are usable,
allowing distinct dates to the beginning of 2038. To put it another
way, 31 bits can count 68 years, 34 bits over 500 years.
The second count is converted by dividing the 34
bit time value by 86400 ( = 24 * 60 * 60 ) to obtain the day local
second value (appr. 17 bits) and a day number (17-18 bits).
Getting from a day number to a proper date
requires some observations about dates. Our calendar has a leap year
cycle that repeats after 4 * 365 + 1 = 1461days. If you start your
four year cycle on March 1st after 1461 days it will be March 1st
again for all the four year cycles from 1901 to 2099, since the only
possible exception, year 2000, was a leap year despite being a
century (because it was additionally divisible by 400). This
simplifies the algorithm. When you base your time on March 1st,
1900, calculation to January 1st, 1901 (Calendar’s start date) is
a simple addition of (365-31-28=306) days.
The choice of March 1st, 1900, as the start date
is conveniently the start of a four year cycle. This covers the
required year 1901 and the 48 bit counter assures that the year 2099
is in the possible range as well.
The day number is divided by 1461 to give the
four year count to be multiplied by 4 for a year counter, and the
remainder to give local day number with the four year cycle.
When starting on March 1st the months are easiest
numbered 0..11. A local day number of 1460 is February 29th in local
cycle year 3, other values get the local cycle year via division by
365, adding the local cycle year to the year number. The remainder
from the division is the year local day number (0..364). A table can
then be set up with 13 entries, where the search stops when the year
local day number is < the table entry:
Table(0) = 0 (starting point)
Table(1) = 31 (days in March)
Table(2) = 31 + 30 (days in March + April)
... (days in March + April + May + ...)
Table(12) = 31 + 30 + 31 + ... + 28
(365 = all days, will always stop here)
Local day in month = year local day number -
Table( I - 1) + 1, when year local day number < Table( I ).
Since March is month zero we must add 3 to I - 1
to get the proper month number, and if that result exceeds 12, the
year number must be incremented and the month number subtracted 12.
We have now converted the day number to year,
month and day, using a fairly simple algorithm, involving no more
than 32 bit arithmetic on the day number. Before passing it as a
proper Calendar date, the year range must be checked to be in
1901..2099.
Going the other way we can calculate how many
whole four year cycles there are from March 1st, 1900, then how many
years and finally use the month number to look up the relevant day
counts. After adding the day number (remember that day 1 is value 0)
the total day number is easily calculated. Getting the local time of
day and the fractions in as well is a matter of multiplying by 86400
and shifting the result 14 bits to the left.
If the day of the week is also needed the day
number can also be used: a simple division by 7 yielding a remainder
0..6 will give the relative weekday from the weekday of March 1st,
1900 (day 0), which was a Thursday.
 |
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 ]
What the #$*! Do We Know!
By Linda Rising
risingl@acm.org
www.lindarising.org
What the #$*! Do We Know?! is an intriguing film. It’s a
story; it’s a documentary. It’s humorous but thought provoking.
The "heroine" is Amanda, played by deaf actress, Marlee
Matlin. She falls into a "rabbit hole" of strange
happenings where provocative characters share deep insight that she
struggles to understand. She, like most of us, has lived her life
following principles that she has developed based on her experience.
I would say "limited experience," but that’s almost a
given, since all our experience is limited! The movie has a happy
ending—I think. She learns from the strange encounters and begins
to apply the new knowledge she has acquired. She will never be the
same and, I guess, the same could be said for the viewer.
Here’s an example of one of the "experiences" in the
film. It’s about water. Water is pretty important for those of us
in Arizona, but it becomes even more important when we realize that
the Earth is largely covered by it and we are largely made up of it.
Dr. Masaru Emoto is a pioneer Japanese researcher whose photographs
were first featured in his books Messages from Water 1 and 2.
The books were first published in Japan, with over 400,000 copies
sold internationally. He shows the result of exposing water samples
to different thoughts and feelings and showing in his photographs
that the water appears to "change its expression" to
reflect the experimenters thoughts and feelings.
He uses high-speed photography, a powerful microscope, and a very
cold room to study frozen water samples. Water from clear springs
that has been exposed to loving words shows brilliant, complex, and
colorful snowflake patterns. In contrast, polluted water, or water
exposed to negative thoughts, shows incomplete, asymmetrical
patterns with dull colors.
In the film, Amanda sees an exhibit of Emoto’s work—different
water samples, labeled with the words to which the samples have been
exposed. A by-stander remarks that if words can have this effect on
water samples, what effect would words have on us, since we are made
up largely of water. Later in the file, Amanda stands in front of
the mirror yelling at her body, "I hate you! I hate you!"
and then has a flashback to the subway water exhibit. The next scene
shows her covering her body with blue hearts as an expression of
love, her way of saying to her body, "I love you! I love
you!" It’s a dramatic way of telling us that the words we use
(even when we are talking to ourselves) can have a powerful impact
on the way our world reacts to those words.
The comments of the fourteen scientists and mystics interviewed
throughout the story blend in with Amanda’s adventure and provide
an "observer" voice to the struggles of our heroine. The
experts agree on some things and have different interpretations for
others. They also bring up Big Questions—you know the "What’s
life all about?" kind of thing. The result is both inspiring
and puzzling, leaving us with more curious puzzles than real
answers.
Let me bring in some interesting research at Princeton
University, and then, finally, I’ll get to the point of this
article—the what’s in it for me that’s supposed to drive all
good business presentations!
For the past 20 years or so, the folks in the PEAR (Princeton
Engineering Anomalies Research) program have been studying unusual
phenomena in human/machine interactions. Thousands of experiments
have been carried out with random number generators, where humans
have been instructed to change the random behavior in any way they
know how: by willing it, praying for it, thinking about it, invoking
celestial beings, you get the idea. What they’ve seen is that
people can successfully influence the output of the machine. They can’t
change it by a lot, but they can change it, and, as you might
imagine, some people are better than others.
Now, I think that’s fascinating, but here’s where it gets
especially interesting. The researchers thought, "Well, if
individuals can do this. How about trying this with groups?"
They found that pairs who have something in common have a larger
effect, especially those pairs where the individuals have an
emotional bond. The effects are not altered by distance. The
subjects are sometimes thousands of miles from the laboratory, and,
here’s something really intriguing, the subjects can influence the
machine before or after (yes, after) its operation.
Well, if pairs are good, what about larger groups? The answer is
a resounding "yes" with those groups that have something
in common showing a much greater effect. The following comment is
from the Princeton web site: www.princeton.edu/~pear/2.html
Venues that appear to be particularly conducive to such field
anomalies include small intimate groups, group rituals, sacred
sites, musical and theatrical performances, and charismatic
events. In contrast, data generated during academic
conferences or business meetings show no deviations from chance.
So much for the power of those academic conferences or business
meetings!
We’ve probably all had the experience of being part of a group
that had this kind of positive power. One classic sports example is
the 1980 U.S. Olympic Hockey Team, a group of talented amateurs who
stunned the world by winning the gold medal against the vastly more
talented and experienced, virtually professional Russian and Finnish
teams. On a recent flight to Vienna, I saw the movie about this
event—Miracle. I’m not a hockey fan, but my attention to
those games was enough to get me through a lot of turbulence!
This, of course, is what this article is all about. The power of
these groups or teams of people. I’ve written several articles for
this newsletter about agile software development. In this approach,
there is a clear recognition of the desirability of small teams that
have good communication. My favorite agile approach, Scrum, talks
about daily meetings, short, 15-minute affairs. Extreme programming
talks about pair programming. Both of these practices are designed
to improve communication and build better teams. The goal is to
build better software. Better teams make better products—for a
host of reasons.
But, the movie What the #$*! Do We Know?! And the research
at Princeton point to a much wider impact for these super-teams.
Imagine if a company were made up of teams like this? Is it too
far-fetched to believe that they would not only produce better
products, but also, somehow, be able to influence the business
community around them, that they could change the world? If we give
this serious thought, we might realize that occurrences of this
kind, although unusual, are much more frequent in business than is
commonly suspected. The following is from a fascinating article by
business guru Peter Senge and Charles Keifer [1].
Every so often we hear of a group of people who have united
under extreme pressure to achieve seemingly miraculous results. In
these moments, human beings transcend their personal limitations
and realize a synergy that far surpasses any past performance.
Anyone hearing a fine symphonic or jazz group hopes for one of the
special concerts that uplifts both the audience and performers.
So, the challenge is, not to develop agile teams for the sake of
satisfying the current customer or building the product today, but
for influencing the world of tomorrow. Is that crazy or what? I’m
always interested to hear what you think, but I’d really be
interested to hear your thoughts on this topic! And, take some time
to see both movies I’ve described. They’re both designed to give
you a great summertime viewing experience that just might change the
way you see the world!
1. Keifer, Charles F., and Senge, Peter M., "Metonic
Organizations: Experiments in Organizational Innovation," Visionary
Leadership, 1982.
 |
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 ]
|
