From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ca9eef4d5e2078ea
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/16
Message-ID: <dewar.882330069@merv>#1/1
X-Deja-AN: 298907592
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
 <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>
 <gwinn-1212971925480001@dh5055236.res.ray.com> <dewar.882235092@merv>
 <gwinn-1612971119580001@dh5055057.res.ray.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 882330129 5658 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-12-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Joe said

<<I guess I ould have to agree, because it's certainly too expensive for
  realtime use.  We will invent some such solution as you suggest.>>

Robert replied

<<No, that's wrong. If you do nothing but assignments and comparisons, there
  is no overhead in the use of enumeration types with holes. If you index
  compact arrays, or worse, do Succ or Pred, then you should have an
  implementation model which tells you immediately that there is extra
  overhead. This should not be a mystery.>>

Joe replied

<<I was talking about rep specs on enumeration types.>>

RObert says

SO WAS I!! That's the point! First I assume you mean an enumeration
representation clause when you say "rep spec on enumeration type" (the
term rep spec, despite popular impressions to the contrary, is not
an Ada technical term!)

The whole point of my comment is that enumeration representation clauses
add ZERO overhead if the only operations are assignments and comparisons.
If your experience leads you to avoid HET's even in this case, you are
overreacting from not understanding the situation clearly.

<<Umm, the point was that many programmers were not aware of the runtime
  cost of tick-Image, not that tick-Image was inherently bad.  I had the
  same problem with fortran programmers wanting to use encode in realtime
  programs.  I recall getting an argument when I forbade the use of encode
  in the late 1970s; it turned out that the core issue was that some of the
  programmers didn't recall how to write a binary<->decimal conversion
  routine, but were afraid to admit it.  A few pages copied from Knuth
  solved the problem.  In those days, most of the embedded realtime
  programmers were retread hardware engineers who learned to program by
  reading the language and computer manuals.>>

Any programmer who does not realize that 'Image involves runtime overhead
lacks very fundamental knowledge about the computing model that underlies
the program. Yes, I understnd that retrodden hardware engineers, physicists,
etc, might conceivably have misunderstandings that are this fundamental,
or more properly, gaps in their knowledge that are this fundamental. That
is *exactly* why I emphasize the importance of having some people on a
project who are competent programmers!