Re: Ada Embedded Systems Efficiencies

[enterpoop.mit.edu!spool.mu.edu!howland.reston.ans.net!paladin.american.ed]

In article <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com> wisniews@saifr0
0.cfsat.honeywell.com (Joe Wisniewski) writes:
>... I
>am involved in a very large Ada project where there is currently much concern 
about whether
>or not we are going to 'fit in the box'. As a result as you can probably imagi
ne, there
>is an increasing amount of attention being paid to addressing "micro-efficienc
ies". This
>attention takes on various forms:
>	1. Optimizing the compiler (back-end developed in-house)
>	2. Addressing issues that the compiler hasn't optimized well or can't o
ptimize
>	   well
>		i.e. getting rid of case statements
>		     limiting the number of parameters that are passed
>		       in procedure calls
>                     pushing for the use of package spec data vs. package body
 data
>			accessed by procedures and functions for state data usa
ge
>		     in-lining during design
>		     etc.
> 
>	Note: Very little prototyping was done and as a result effective early
>	      timing studies were not available or used.
>
>I am concerned that "good design" macro-efficiencies are going to be "un-done"
>due to perceived net overall gain of over-implementing micro-efficiencies.

I think you should be even more concerned that some of these "micro-efficiencie
s"
make no contribution to efficiency at all.  Some of them sound like
rank superstition. In particular:
(a) What advantage is obtained by getting rid of CASE statements?  The
    answer to this question should take into account how the compiler
    generates code for a case statement, and how the same compiler 
    would generate code for the alternative.
(b) What advantage is gained by moving "state data" from a package body
    to a package spec?  This affects only the visibility of those data,
    and does nothing to the way code is generated to use them.
(c) "Inlining during design" sounds like an oxymoron.  
>
>In short, many Ada object-oriented concepts are being 'questioned'; i.e. data
>encapsulation, private types usage, call-through procedures; in groups that 
>used them. 
(d) In general, when I hear that "X has been questioned," I want to
    know if the questioning was reasonable and responsible.  It isn't 
    always.  The value of pi has often been questioned.  See 
    _Mathematical Cranks_ by Underwood Dudley.
(e) What advantage is gained by not using private types?  Again, the 
    answer should be related to the way that the compiler generates
    code for operations on a private type.  I would conjecture that
    there is no difference in code generation.
(f) I don't really know what a "call-through procedure" is; if it 
    is a procedure that does nothing more than call another 
    procedure, then it can be expanded in-line.

I think that the motive force behind the objections that Mr. Wisniewski 
raises is not "fitting into the box" but upsetting the habits
of programmers.  It is regrettable that the programmers feel they
must disguise their concerns in this way.  

I see two issues raised in Mr. Wisniewski's article that may
affect efficiency in a substantial way.  One is a really messy
case statement.  Suppose that one of 5 things is to be done,
depending on the value of a variable J, range 0 .. 255; and
the relation between J and what's to be done is not simple.
It may be faster to look up the number of the correct alterna-
tive in a table and act depending on the value in that table.
If the choice depends on the values of two variables, then
constructing that table may be much better than trying
to organize an efficient scheme of cases and sub-cases.
I know of a compiler which does convert a case statement into
a table look-up if it determines that this is more efficient.
I have never heard of a compiler that would do this for a
complex structure of nested case statements.

The second issue is that of procedure calls with numerous 
parameters.  If the procedure is called frequently, and 
some of the parameters change seldom or not at all,
then efficiency is served by moving those parameters
into a package body, and having a noew procedure to
change their values.  Another useful technique is to
group such values in a record structure; usually the
compiler passes a record parameter by address.  OF
course, it is clear that these techniques have to be applied
with careful judgement of the individual situation.
Just handing down an edict from on high that there
shall be no procedures with more than N parameters
is not going to help.

Regards,
Chris Henrich