/[dtapublic]/pubs/books/ucbka/trunk/c_hgr0/c_hgr0.tex
ViewVC logotype

Annotation of /pubs/books/ucbka/trunk/c_hgr0/c_hgr0.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 140 - (hide annotations) (download) (as text)
Mon Jul 3 01:59:16 2017 UTC (7 years, 5 months ago) by dashley
File MIME type: application/x-tex
File size: 22306 byte(s)
Change SVN properties for EOL and keyword expansion.
1 dashley 140 %$Header$
2    
3     \chapter{The Holy Grail}
4    
5     \label{chgr0}
6    
7     \beginchapterquote{``It seems that mathematical ideas are arranged somehow in strata,
8     the ideas in each stratum being linked by a complex of
9     relations both among themselves and with those above and below.
10     The lower the stratum, the deeper (and in general the more difficult)
11     the idea. Thus the idea of an `irrational' is deeper than that
12     of an integer \ldots{} Let us concentrate our attention on
13     the relations between the integers, or some other group of
14     objects lying in some particular stratum.
15     Then it may happen that one of these relations can be
16     comprehended completely, that we can recognize and prove,
17     for example, some property of the integers, without any
18     knowledge of the contents of lower strata
19     \ldots{} But there are also many theorems about integers
20     which we cannot appreciate properly, and still less prove,
21     without digging deeper and considering what happens
22     below.''}{G. H. Hardy, A Mathematician's Apology,
23     pp. 110-111\index{Hardy, G. H.}}
24    
25     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
26     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
27     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
28     \section{Introduction}
29     %Section tag: INT0
30     \label{chgr0:sint0}
31    
32     Engineers in general and software engineers in particular are often
33     contentious and arrogant. It is common for
34     embedded software developers to derogate each other's work. The enabling
35     element for this type of contention is that there is \emph{no single right way}
36     to construct an embedded software system, and few clear unequivocal metrics
37     of goodness. Without an unambiguous way of comparing different
38     software solutions and deciding which is better (and why), differences of
39     opinion and and rivalries are unavoidable.
40    
41     In this chapter, we concentrate on the holy grail\footnote{In this context
42     we define \emph{holy grail} as an unattainable set of goals.}
43     of embedded software development. We seek a set of unattainable
44     goals to clarify our thought processes. We seek to identify what we are
45     trying to achieve in embedded software systems and in embedded software development.
46    
47     There are several attributes of software in general and embedded
48     software in particular that make it difficult to devise unequivocal
49     metrics of goodness.
50    
51     First, software has more degrees of freedom in its construction
52     than other engineering endeavors.
53     In \cite[p. 6]{bibref:b:boochoodwithapps}, Booch \index{Booch, Grady} writes:
54    
55     \begin{quote}
56     \emph{``A home-building
57     company generally does not operate its own tree farm from which to harvest trees
58     for lumber; it is highly unusual for a construction firm to build an
59     on-site steel mill to forge custom girders for a new building. Yet in the
60     software industry such practice is common. Software offers the ultimate
61     flexibility, so it is possible for a developer to express almost any kind
62     of abstraction. This flexibility turns out to be an incredibly seductive
63     property, however, because it also forces the developer to craft virtually
64     all the primitive building blocks upon which these higher level abstrctions
65     stand. While the construction industry has uniform building codes and
66     standards for the quality of raw materials, few such standards exist in the
67     software industry. As a result, software development remains a labor-intensive
68     business.''}
69     \end{quote}
70    
71     Additionally, Booch writes \cite[p. 51]{bibref:b:boochoodwithapps}:
72    
73     \begin{quote}
74     \emph{``Modules serve as the physical containers in which we declare the classes and
75     objects of our logical design. This is no different than the situation faced
76     by the electrical engineer designing a board-level computer. NAND, NOR, and
77     NOT gates might be used to construct the necessary logic, but these gates
78     must be physically packaged in standard integrated circuits, such as a 7400,
79     7402, or 7404. Lacking any such standard software parts, the software engineer
80     has considerably more degrees of freedom---as if the electrical engineer had
81     a silicon foundry at his or her disposal.''}
82     \end{quote}
83    
84     Electronic hardware designers have less freedom in hardware designs than software
85     designers do in software designs. Available hardware components are
86     naturally limited by physical phenomena, such the number of pins
87     that can be placed on an integrated circuit package, that tend to
88     limit the complexity of the connectivity between hardware components.
89     It is much harder
90     to create a truly bad hardware design than a truly bad software design.
91    
92     Second, metrics of goodness are more obvious and easier to agree
93     on in other engineering disciplines than in software engineering.
94     For example, in the design of electronic hardware, serious disagreements
95     among hardware
96     designers are rare because it is easier to reach agreement about the
97     measures of goodness of a hardware design. Given two [competing] hardware
98     designs, it is almost always clear which is better, based on simple
99     critera such as cost, circuit board area, power consumption, etc.
100     Measures of software design goodness are less clear and obvious.
101    
102     Third, software---especially small embedded software---often allows
103     tradeoffs between management of complexity and other desirable
104     attributes, such as minimum ROM consumption or the best real-time
105     characteristics. In many cases, it is easy to modify software
106     to use less ROM or RAM or to perform better in a real-time sense,
107     but at the expense of a clear and consistent design (i.e. management of
108     complexity).
109     Many disagreements between software developers
110     arise because developers can't agree which tradeoffs should be
111     made between
112     clear structure of the software (i.e. effective management of complexity)
113     and other desirable attributes.
114    
115    
116     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
117     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
118     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
119     \section{Overview Of Desirable Attributes}
120     %Section tag: ODA0
121     \label{chgr0:soda0}
122    
123     This section briefly enumerates what we consider to be the desirable
124     attributes of small embedded software and the product development
125     process and infrastructure. Each attribute is discussed in more
126     detail later in the chapter. Each desirable attribute below is
127     numbered with a ``\desirablepropertyprefix'' number so that it
128     can be cross-referenced.
129    
130     \begin{enumerate}
131    
132     \item \textbf{Desirable Properties of Embedded Software}
133    
134     \begin{enumerate}
135    
136     \item \textbf{Minimum Program Memory Consumption
137     \desirablepropertyemit\label{dp:chgr0:soda0:minpm}.}
138     An embedded software load
139     should use as little ROM or other program memory as possible.
140     Microcontrollers containing more ROM are more costly, and so
141     a primary goal is to minimize ROM consumption so that the
142     least expensive microcontrollers can be used.
143    
144     \item \textbf{Minimum RAM Consumption
145     \desirablepropertyemit\label{dp:chgr0:soda0:minram}.}
146     Minimization of RAM
147     consumption is a primary goal so that the least
148     expensive microcontrollers can be used.
149    
150     \item \textbf{Minimum EEPROM Consumption
151     \desirablepropertyemit\label{dp:chgr0:soda0:mineeprom}.}
152     Minimization of
153     EEPROM consumption is a primary goal so that the least
154     expensive microcontrollers can be used.
155    
156     \item \textbf{Optimal CPU Cycle Utilization
157     \desirablepropertyemit\label{dp:chgr0:soda0:bestcpucycle}.}
158     We seek to design
159     systems that, for a given set of requirements, can
160     meet the requirements most efficiently with respect
161     to CPU demands. Such systems enable the use of slower [less costly]
162     microcontrollers, are less likely to conceal behavior,
163     and are easier to modify.
164    
165     \item \textbf{Minimal Possibility Of Concealed Behavior
166     \desirablepropertyemit\label{dp:chgr0:soda0:minpconcealedbeh}.}
167     We seek to build
168     software systems that are not likely to
169     conceal behavior during product testing. Systems that have a large
170     ability to conceal behavior may pass product testing but
171     still exhibit defects for customers. The inability to conceal behavior
172     is closely related to other desirable characteristics:
173    
174     \begin{enumerate}
175    
176     \item \textbf{Minimization Of State Space
177     \desirablepropertyemit\label{dp:chgr0:soda0:minss}.}
178     Many software defects are tied to
179     software that holds more state than necessary. We seek to correctly
180     identify the minimum necessary state space of the software and to
181     construct software that is minimally stateful.
182    
183     \item \textbf{Minimization Of Scheduling Freedom
184     \desirablepropertyemit\label{dp:chgr0:soda0:minschedfreedom}.}
185     We seek to minimize the way in which
186     external events can affect the way software components are scheduled for
187     execution. Simpler \emph{is} better.
188    
189     \item \textbf{Minimization Of Non-Linear Behavior
190     \desirablepropertyemit\label{dp:chgr0:soda0:minnonlin}.}
191     Systems with
192     strongly non-linear or chaotic tendencies are undesirable.
193    
194     \end{enumerate}
195    
196     \item \textbf{Robustness.
197     \desirablepropertyemit\label{dp:chgr0:soda0:robustness}}
198     We seek to build systems that are robust with
199     respect to state upset of the controller, intermittent failure of
200     sensors and actuators, modeling errors, component aging, and variable
201     real-time loading of the software.
202    
203     \item \textbf{Maximum Re-Usability Of Code
204     \desirablepropertyemit\label{dp:chgr0:soda0:maxreusecode}.}
205     We seek to be able to re-use
206     software components, and we seek to be able to develop
207     new products with a minimum of new software component development.
208     This goal related to both economy and to software quality.
209     Repeatedly reinventing the wheel is expensive, and it also introduces quality
210     concerns---it is more reliable to reuse software components
211     that have had prolonged exposure in existing products.
212    
213     \item \textbf{Testability and Instrumentability
214     \desirablepropertyemit\label{dp:chgr0:soda0:testability}.}
215     We desire to construct software systems that are testable and
216     instrumentable. This desirable attribute includes the detection of
217     internal errors, the measurement of timing margins, and other requirements
218     and best practices.
219    
220     \end{enumerate}
221    
222     \item \textbf{Desirable Properties of a Product Development Process}
223    
224     \begin{enumerate}
225    
226     \item \textbf{Minimum Development Time
227     \desirablepropertyemit\label{dp:chgr0:soda0:mindevtime}.}
228     We seek to minimize the time to bring
229     product to market.
230    
231     \item \textbf{Feedback Path From Defects And Near Defects To Process, Training,
232     And Tools
233     \desirablepropertyemit\label{dp:chgr0:soda0:feedbackpath}.}
234     We seek to be able to record defects (that make it into
235     production) and near defects (that nearly make it into production),
236     and feed these back into the product development process
237     (in the event that any process step could have prevented
238     the defect or near defect), into the training for software developers, and into
239     the tool set (if the defect or near defect is automatically detectable).
240    
241     \end{enumerate}
242    
243     \item \textbf{Desirable Properties of Human Environment}
244    
245     \begin{enumerate}
246    
247     \item \textbf{Self-Actualizing Experience for Employees
248     \desirablepropertyemit\label{dp:chgr0:soda0:saexperience}.}
249     We seek to provide a self-actualizing
250     experience for employees. Any employee should leave
251     a company with far more skills
252     than they had on their arrival.
253    
254     \item \textbf{Best Experiences for the Top 20\% of Employees
255     \desirablepropertyemit\label{dp:chgr0:soda0:betop20}.}
256     It is common knowledge that the most
257     capable 20\% of software developers make 80\% of the competitive contribution.
258     It is also common knowledge that this 20\% is the most sensitive to working conditions
259     which impair productivity.
260     We seek to make it easier for this 20\% to be the most productive.\footnote{Note that this
261     notion of protecting the most productive employees is built into the work environment
262     so that we don't often think of this goal. For example, in a dentist's office, the
263     dentist certainly \emph{could} schedule appointments and follow up with insurance
264     claims, but economically it is more feasible to have an administrative staff do
265     this. Similarly, when obtaining technical support for a software product, one rarely reaches
266     the actual software developers. We also do not claim that we need to identify the
267     20\%, simply that we need to remove institutional productivity barriers.}
268    
269     \end{enumerate}
270    
271     \item \textbf{Desirable Properties of Administrative System}
272    
273     \begin{enumerate}
274    
275     \item \textbf{A Place For Everything, And Everything In Its Place
276     \desirablepropertyemit\label{dp:chgr0:soda0:placeforeverything}.}
277     We seek administrative
278     neatness and consistency.
279    
280     \item \textbf{Elimination Of Redundant Information
281     \desirablepropertyemit\label{dp:chgr0:soda0:lackredinfo}.}
282     Redundant information in product
283     development is harmful in two ways. First, it is tedious and costly to [manually] maintain
284     the same information in different places. Second, such an arrangement is a change
285     risk, because the information may be updated in one place but not another.
286    
287     \end{enumerate}
288    
289     \end{enumerate}
290    
291     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
292     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
293     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
294     \section{Detailed Description Of Desirable Attributes}
295     %Section tag: DDA0
296     \label{chgr0:sdda0}
297    
298    
299     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
300     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
301     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
302     \subsection[Minimum ROM, RAM, And EEPROM Consumption]
303     {Minimum ROM, RAM, And EEPROM Consumption
304     (\desirablepropertycite{dp:chgr0:soda0:minpm},
305     \desirablepropertycite{dp:chgr0:soda0:minram},
306     and
307     \desirablepropertycite{dp:chgr0:soda0:mineeprom})}
308     %Subsection tag: MRE0
309     \label{chgr0:sdda0:mre0}
310    
311     Typical inexpensive microcontrollers come in families of parts with
312     the same CPU core but different amounts of ROM, RAM, and EEPROM; with different
313     numbers of I/O pins; and often with different I/O peripherals.
314     Almost invariably, members of a
315     family are priced so that the parts with more capability are more expensive.
316    
317     Because of the cost differential, there is often substantial pressure
318     on microcontroller software developers to create software which
319     uese as little ROM, RAM, and EEPROM as possible; so that the least
320     expensive parts can be used. Additionally, it often happens that
321     a software load consumes nearly all the resources of the
322     largest available part in a family, so that no options are available
323     if the software cannot be made to fit.
324    
325     Thus, strategies to minimize the consumption of ROM, RAM, and EEPROM
326     are of great interest in embedded software development.
327    
328     Somewhat counterintuitively, the rigorous application of ROM-, RAM-, and
329     EEPROM-reduction strategies from the \emph{start} of a product development
330     may actually \emph{increase} the probability of a product development
331     failure. If these strategies are applied from the very start of a
332     product development, there will be little or no ``fat'' left in software modules
333     that can be trimmed if ROM, RAM, or EEPROM limits are reached.
334     The rigorous application of ROM-, RAM-, and EEPROM-reduction strategies
335     must be accompanied by an increased respect for storage size limits.
336    
337    
338     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
339     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
340     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
341     \subsection[Optimal CPU Cycle Utilization]
342     {Optimal CPU Cycle Utilization
343     (\desirablepropertycite{dp:chgr0:soda0:bestcpucycle})}
344     %Subsection tag: BCC0
345     \label{chgr0:sdda0:bcc0}
346    
347     In many applications, it may be advantageous to use the least-capable
348     microcontroller with the slowest clock rate that will suffice for the
349     application. The reasons that this may be advantageous are:
350    
351     \begin{enumerate}
352     \item More capable microcontrollers are generally more costly.
353     \item It may be advantageous to operate a micrcontroller at less than
354     the maximum allowable clock frequency.
355     \begin{enumerate}
356     \item A system with a higher clock rate usually consumes more power, and
357     the relationship is often approximately linear.
358     \item There may be certain frequencies at which the embedded system should
359     not emit signals. (For example, in an automotive application, the
360     AM and FM radio bands are to be avoided. If the clock frequency of
361     the system is chosen so that the frequency or a harmonic is in these
362     bands, the system must be shielded or otherwise made more expensive.)
363     \end{enumerate}
364     \end{enumerate}
365    
366     The general principles that apply to optimization for CPU-cycle efficiency are:
367    
368     \begin{enumerate}
369     \item The mechanisms that pervade the system must be examined carefully and
370     optimized. Typical mechanisms that must be optimized are:
371    
372     \begin{enumerate}
373     \item \textbf{Time measurement mechanisms.}
374     The notion of \emph{time} typically pervades an
375     embedded system. It is typical for many
376     software components to contain state-machine logic
377     with transition functions that are functions of time.
378     Decisions about how to represent time and how to test
379     elapsed time can have a \emph{profound} effect on
380     the performance of the system.
381     \item \textbf{IPC mechanisms.}
382     The mechanisms by which
383     \end{enumerate}
384     \end{enumerate}
385    
386    
387     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
388     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
389     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
390     \subsection[Minimal Possibility of Concealed Behavior]
391     {Minimal Possibility of Concealed Behavior
392     (\desirablepropertycite{dp:chgr0:soda0:minpconcealedbeh})}
393     %Subsection tag: mpc0
394     \label{chgr0:sdda0:mpc0}
395    
396    
397     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
398     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
399     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
400     \subsubsection[Minimization of State Space]
401     {Minimization of State Space
402     (\desirablepropertycite{dp:chgr0:soda0:minss})}
403     %Subsubsection tag: mss0
404     \label{chgr0:sdda0:mpc0:mss0}
405    
406     Many embedded software defects are directly attributable to software which
407     holds more state than necessary. It is a common observation that
408     novice programmers have difficulty in designing state-minimal
409     embedded software components---in extreme cases, novice programmers have
410     even implemented purely combinational mappings as sequential machines.
411    
412     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
413     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
414     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
415     \subsubsection[Minimization of Scheduling Freedom]
416     {Minimization of Scheduling Freedom
417     (\desirablepropertycite{dp:chgr0:soda0:minschedfreedom})}
418     %Subsubsection tag: msf0
419     \label{chgr0:sdda0:mpc0:msf0}
420    
421    
422     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
423     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
424     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
425     \subsubsection[Minimization of Non-Linear Behavior]
426     {Minimization of Non-Linear Behavior
427     (\desirablepropertycite{dp:chgr0:soda0:minnonlin})}
428     %Subsubsection tag: mnl0
429     \label{chgr0:sdda0:mpc0:mnl0}
430    
431    
432     \subsection{Freedom From Redundant Information}
433    
434    
435     \subsection{Robustness}
436     \label{chgr0:sdda0:srob0}
437    
438    
439     \subsection{Maximum Re-Usability Of Source Code}
440    
441    
442     \subsection{Minimum Development Time}
443    
444    
445     \subsection{Feedback Path From Defects To Product Development Process, Training, And Tools}
446    
447    
448     %\subsection{Self-Actualizing Experience For Employees}
449    
450    
451     %\subsection{Best Experiences For The Top 20\% Of Employees}
452    
453    
454     %\subsection{Administrative Neatness}
455    
456     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
457    
458     \noindent\begin{figure}[!b]
459     \noindent\rule[-0.25in]{\textwidth}{1pt}
460     \begin{tiny}
461     \begin{verbatim}
462     $RCSfile: c_hgr0.tex,v $
463     $Source: /home/dashley/cvsrep/e3ft_gpl01/e3ft_gpl01/dtaipubs/esrgubka/c_hgr0/c_hgr0.tex,v $
464     $Revision: 1.7 $
465     $Author: dtashley $
466     $Date: 2004/03/17 01:37:52 $
467     \end{verbatim}
468     \end{tiny}
469     \noindent\rule[0.25in]{\textwidth}{1pt}
470     \end{figure}
471    
472     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
473     % $Log: c_hgr0.tex,v $
474     % Revision 1.7 2004/03/17 01:37:52 dtashley
475     % Edits.
476     %
477     % Revision 1.6 2004/03/12 11:24:07 dtashley
478     % General edits and changes.
479     %
480     % Revision 1.5 2004/02/22 19:27:47 dtashley
481     % Edits.
482     %
483     % Revision 1.4 2003/03/18 06:20:34 dtashley
484     % Section on "robustness" labeled so could be referred to from rational counting
485     % algorithm section.
486     %
487     % Revision 1.3 2002/08/22 03:56:55 dtashley
488     % Aesthetic changes.
489     %
490     % Revision 1.2 2001/07/01 19:28:00 dtashley
491     % Move out of binary mode for use with CVS.
492     %
493     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
494     % $History: c_hgr0.tex $
495     %
496     % ***************** Version 3 *****************
497     % User: Dashley1 Date: 3/07/01 Time: 12:17a
498     % Updated in $/uC Software Multi-Volume Book (A)/Chapter, HGR0, Holy Grail
499     % Edits.
500     %
501     % ***************** Version 2 *****************
502     % User: Dashley1 Date: 6/13/00 Time: 7:49p
503     % Updated in $/uC Software Multi-Volume Book (A)/Chapter, HGR0, Holy Grail
504     % Initial check-in.
505     %
506     %End of file C_HGR0.TEX

Properties

Name Value
svn:eol-style native
svn:keywords Header

dashley@gmail.com
ViewVC Help
Powered by ViewVC 1.1.25