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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 6 - (show annotations) (download) (as text)
Fri Oct 7 01:36:46 2016 UTC (7 years, 7 months ago) by dashley
File MIME type: application/x-tex
File size: 22932 byte(s)
Initial commit after migrating from CVS.
1 %$Header: /home/dashley/cvsrep/e3ft_gpl01/e3ft_gpl01/dtaipubs/esrgubka/c_hgr0/c_hgr0.tex,v 1.7 2004/03/17 01:37:52 dtashley Exp $
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

dashley@gmail.com
ViewVC Help
Powered by ViewVC 1.1.25