comp.lang.ada
 help / color / mirror / Atom feed
* Play 20K expressions again, Sam
@ 1992-08-28 16:29 Paul Byrley
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Byrley @ 1992-08-28 16:29 UTC (permalink / raw)


I was willing to be prejudiced again against "those academics" when
I first read about the supposed bug in a compiler that balked at 20k
expressions.  After reading Sam Harbaugh's good natured
commentary, I rethought my position and decided to just comment.

About 1985, I asked the net at SIMTEL20 what to do about
contractually limiting the size of Ada packages. We had been using
FORTRAN and MIL-STD-1679 or 1644 where the limit was 200 LOC
for a sub-program (1679 and 1644 predated Ada by 5 to 10 years). 
 I thought 200 LOC was excessive for good life cycle support
(assuming 50% comments and 64 lines per line printer page you got
6 pages of code plus a page or two of declaratives).  We had just
started talking about the Hrair limit then, thanks to Grady Booch (and,
I think, some rabbit in Watership Downs) and six pages of listings was
too much for my brain to encompass.  I felt sure, however, that the
200 LOC limit we used for FORTRAN subroutines wouldn't translate
into a valid Ada limit.  Anyhow, when I asked the net, I got back
about eight comments, all saying "no LOC limits for Ada packages". 
I believe that Grady Booch and Ed Berard were among the
commenters and that was support enough for me.  

Since then, our agency has used the no LOC limit approach on
probably 50 procurements for real time training systems, ranging in
size from 5000 LOC to 800K LOC of Ada.  I think only one vendor
has violated what, as near as I can tell, is industry agreement on good
practice on package size.  Most packages seem to be from 100 to
500 LOC, and almost never over 1000 LOC.  The one "violator of
good practice" insisted on delivering a 10K LOC package.  It worked,
but is going to be more expensive for all us taxpayers to support for
the next 10 to 15 years.  

My opinion is that if a person is hanging together large amounts of
code and will support it himself forever (promises not to quit or die
before his employer ceases to need the software), then 20K
expressions is ok. (Does one expression = one LOC or are we talking
one expression = LOC/4 to LOC/8?)  If a taxpayer (even a federal
research grant comes from taxpayers) is going to have to pay extra for
the indulgence of a 20K expression programmer, then I thank Verdix
for their choice. Actually I wish it were lower.  I remember, years ago,
learning that the reason my latest FORTRAN "gem" was not compiling
was that I had overrun the compiler tables- that program was about
1000 LOC and I was briefly indignant also.  Yeah Sam, that was half
a box of cards, red ones and blue ones and even green ones, with a
diagonal magic marker across the top so you could maybe recover
when someone dropped them.

Regards to all, even the long package advocates.

Paul Byrley

\x1a

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-08 22:02 haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogics
  0 siblings, 0 replies; 10+ messages in thread
From: haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogics @ 1992-09-08 22:02 UTC (permalink / raw)


In article <dnsurber.715958256@node_26400> dnsurber@lescsse.jsc.nasa.gov (Dougl
as N. Surber) writes:
>Actually no.  The Verdix compiler is written in C, not that silly Ada thing. :
).

Well, our new optimizer is written in Ada.  It turns out that Ada is a
great language for writing large programs, the new code is very readable
and maintainable.

Boy were we surprised!  :)

	-- brucej

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-09 16:13 Michael Feldman
  0 siblings, 0 replies; 10+ messages in thread
From: Michael Feldman @ 1992-09-09 16:13 UTC (permalink / raw)


In article <dnsurber.715958256@node_26400> dnsurber@lescsse.jsc.nasa.gov (Dougl
as N. Surber) writes:
>
>Actually no.  The Verdix compiler is written in C, not that silly Ada thing. :
).
Indeed. Verdix, ICC, DEC, and Meridian use other languages to write their
compilers. Alsys, RR, TeleSoft, and Rational all use Ada.

Is Verdix' commitment to C as a host language a contributing factor in the 
bugs being so hard to fix?

A nice consequence of compiler houses writing their stuff is Ada is that
the developers really have to know Ada! I believe that will help them
better to understand the kinds of programs their customers will write.
(The Verdix guy's use of a C-ism shows me which language he focuses on...)

Mike Feldman

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-09 18:05 Arra Avakian
  0 siblings, 0 replies; 10+ messages in thread
From: Arra Avakian @ 1992-09-09 18:05 UTC (permalink / raw)


In article <1992Sep9.161353.5418@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:

>A nice consequence of compiler houses writing their stuff in Ada is that
>the developers really have to know Ada! I believe that will help them
>better to understand the kinds of programs their customers will write.
>...

Perhaps even more significant, if the developers bootstrap (compile their
compiler using their compiler), then you know that their compiler has
successfully compiled a fairly large and complex application program,
increasing the liklihood YOUR program will compile and execute without problems
.
(As has been mentioned here before, the ACVC does not serve this purpose!)

Real world test suites are critical to compiler quality, no matter the 
language it compiles or the its implementation language.
Boostrapping puts a real world test case in the hands of the compiler developer
,
with a very desirable impact on its quality.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-09 18:11 Alex Blakemore
  0 siblings, 0 replies; 10+ messages in thread
From: Alex Blakemore @ 1992-09-09 18:11 UTC (permalink / raw)


In article <1992Sep9.161353.5418@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:
> A nice consequence of compiler houses writing their stuff is Ada is that
> the developers really have to know Ada! 

I believe Verdix's run time is also written in Ada, along with their new optimi
zer.
When I last messed with it a long time ago, it looked alot like C in Ada syntax
.

I can see some arguments for writing the code generator in C for easier ports,
but I cant help but wonder if we'ld see fewer "internal assertion errors" if
they'ld used Ada.  Actually, as long as it worked, I wouldnt really care.


-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-09 20:24 att!cbnewse!cbnewsd!att-out!cbnewsl!willett
  0 siblings, 0 replies; 10+ messages in thread
From: att!cbnewse!cbnewsd!att-out!cbnewsl!willett @ 1992-09-09 20:24 UTC (permalink / raw)


>From article <1992Sep9.180517.20788@inmet.camb.inmet.com>, by arra@orb.camb.in
met.com (Arra Avakian):
> In article <1992Sep9.161353.5418@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
> 
>>A nice consequence of compiler houses writing their stuff in Ada is that
>>the developers really have to know Ada! I believe that will help them
>>better to understand the kinds of programs their customers will write.
>>...
> 
> Perhaps even more significant, if the developers bootstrap (compile their
> compiler using their compiler), then you know that their compiler has
> successfully compiled a fairly large and complex application program,
> increasing the liklihood YOUR program will compile and execute without proble
ms.
> (As has been mentioned here before, the ACVC does not serve this purpose!)
> 
> Real world test suites are critical to compiler quality, no matter the 
> language it compiles or the its implementation language.
> Boostrapping puts a real world test case in the hands of the compiler develop
er,
> with a very desirable impact on its quality.

The second paragraph isn't necessarily true.  While a compiler is clearly a
"large & complex" program, it is doing a simple, straightforward job.  It
may or may not use the features that you are trying to use.  I'll concede
that "bootstraping" is impressive, but not as much so as compiling a
varied suite of "typical" application programs.  Defining "typical" is 
what targets the compiler.  A vendor trying to service the avionics market
should put together a suite of "typical" avionics programs.  One going after
financial markets should use a suite of financial programs, etc.


-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
attmail!dwillett      (AT&T FSAT)

A dog is a dog until he is facing you.  Then he is *MISTER* dog!

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-09 23:36 Bob Kitzberger
  0 siblings, 0 replies; 10+ messages in thread
From: Bob Kitzberger @ 1992-09-09 23:36 UTC (permalink / raw)


arra@orb.camb.inmet.com (Arra Avakian) writes:

>Real world test suites are critical to compiler quality, no matter the 
>language it compiles or the its implementation language.
>Boostrapping puts a real world test case in the hands of the compiler 
>developer, with a very desirable impact on its quality.

A downside to bootstrapping is that it increases a vendor's time-to-market.

"Good cooking takes time.  If you are made to wait, it is to serve you better,
and to please you".

			-- Menu of Restaraunt Antoine, New Orleans
			   (shamelessly snagged from "The Myth. Man-Month")

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
			+1 619 457 2111    FAX +1 619 457 0888

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-14  4:12 Michael Feldman
  0 siblings, 0 replies; 10+ messages in thread
From: Michael Feldman @ 1992-09-14  4:12 UTC (permalink / raw)


In article <rlk.716081797@amstel> rlk@VisiCom.COM (Bob Kitzberger) writes:
>arra@orb.camb.inmet.com (Arra Avakian) writes:
>
>>Real world test suites are critical to compiler quality, no matter the 
>>language it compiles or the its implementation language.
>>Boostrapping puts a real world test case in the hands of the compiler 
>>developer, with a very desirable impact on its quality.
>
>A downside to bootstrapping is that it increases a vendor's time-to-market.
>
...as TeleSoft discovered. On the other hand, once the first bootstrapped
product is out there, each new version gets easier and better, as I think
TeleSoft also discovered.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-17  7:20 Jim Lonjers
  0 siblings, 0 replies; 10+ messages in thread
From: Jim Lonjers @ 1992-09-17  7:20 UTC (permalink / raw)


In article <1992Sep9.180517.20788@inmet.camb.inmet.com> arra@orb.camb.inmet.com
 (Arra Avakian) writes:
>Perhaps even more significant, if the developers bootstrap (compile their
>compiler using their compiler), then you know that their compiler has
>successfully compiled a fairly large and complex application program,
>increasing the liklihood YOUR program will compile and execute without problem
s.
>(As has been mentioned here before, the ACVC does not serve this purpose!)
>
>Real world test suites are critical to compiler quality, no matter the 
>language it compiles or the its implementation language.
>Boostrapping puts a real world test case in the hands of the compiler develope
r,
>with a very desirable impact on its quality.

While this is undoubtably true, we must really be careful about how much a
compiler vendor believes in this as a testing method.  In a prior life, I
was responsible for the Unisys ALGOL compiler which was written in Unisys
ALGOL.  We implemented coverage analysis, which marked which lines in a
program are covered in an execution.  After compiling the compiler with the
compiler, we ended up with on 20% of the compiler covered.

There are lots of reasons for this, but the compiler

1. is a batch program and thus does not do any interactive I/O.
2. is a single thread of execution so it used no tasking.
3. had no static errors, nor any uncorrected execution time
   errors, so the error detection/correction logic was not used.
4. had to be fast (~ 10_000 lines per minute on a 1 MIPS machine),
   so it did nothing with dynamic memory allocation.

This list can get very long, but you get the idea.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Play 20K expressions again, Sam
@ 1992-09-17 17:39 Bob Kitzberger
  0 siblings, 0 replies; 10+ messages in thread
From: Bob Kitzberger @ 1992-09-17 17:39 UTC (permalink / raw)


lonjers@prc.unisys.com (Jim Lonjers) writes:

>While this is undoubtably true, we must really be careful about how much a
>compiler vendor believes in this as a testing method.  In a prior life, I
>was responsible for the Unisys ALGOL compiler which was written in Unisys
>ALGOL.  We implemented coverage analysis, which marked which lines in a
>program are covered in an execution.  After compiling the compiler with the
>compiler, we ended up with on 20% of the compiler covered.

There is usually much more to a modern Ada development environment than
the compiler itself, and there are often interactive components,
real-time components, GUI components, etc.  The more of this that is written
in Ada, the better the code coverage.

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~1992-09-17 17:39 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-09-17 17:39 Play 20K expressions again, Sam Bob Kitzberger
  -- strict thread matches above, loose matches on Subject: below --
1992-09-17  7:20 Jim Lonjers
1992-09-14  4:12 Michael Feldman
1992-09-09 23:36 Bob Kitzberger
1992-09-09 20:24 att!cbnewse!cbnewsd!att-out!cbnewsl!willett
1992-09-09 18:11 Alex Blakemore
1992-09-09 18:05 Arra Avakian
1992-09-09 16:13 Michael Feldman
1992-09-08 22:02 haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogics
1992-08-28 16:29 Paul Byrley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox