Play 20K expressions again, Sam
Bruce Jones
>I've run into the "damn Verdix bug" limit on number of branches in a
>case statement a couple of times.
This is to announce to our patient customers that the "damn Verdix bug"
has been fixed. The limit of "20K expressions" (actually "22000 `logical
registers') has been changed to a limit of 0x40000000. A nice round number,
large enough to accommadate most compilations for the forseeable future.
Appearing soon in a Verdix 6.2 release on your workstation.
-- brucej
crispen
>I've run into the "damn Verdix bug" limit on number of branches in a
>case statement a couple of times.
Oh, please don't get me started on their case statements! Have you
seen the code they generate? Compare and branch, compare and branch...
Hasn't anyone there heard of a jump table? The foregoing is about
their 5.4.1 compiler (I think) which is on VADSWorks 1.2(?) (VxWorks
4.0.2-based). Haven't looked at the newer versions yet, so if they've
fixed it, IT'S ABOUT TIME!!!
Bob Crispen
Pretty near ready to post the multiple inheritance summary.
cri...@foxy.boeing.com
bo...@cnam.cnam.fr
...
> has been fixed. The limit of "20K expressions" (actually "22000 `logical
> registers') has been changed to a limit of 0x40000000. A nice round number,
You mean 16#40000000# ?
Sorry, could'nt resist :-)
Stephane Bortzmeyer Conservatoire National des Arts et Metiers
bortz...@cnam.cnam.fr Laboratoire d'Informatique
292, rue Saint-Martin
tel: +33 (1) 40 27 27 31 75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72 France
"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand
-------------
Stephane Bortzmeyer Conservatoire National des Arts et Metiers
bortz...@cnam.cnam.fr Laboratoire d'Informatique
292, rue Saint-Martin
tel: +33 (1) 40 27 27 31 75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72 France
"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand
Douglas N. Surber
>In article <91...@verdix.verdix.com>, bru...@verdix.com (Bruce Jones) writes:
>...
>> This is to announce to our patient customers that the "damn Verdix bug"
>> has been fixed. The limit of "20K expressions" (actually "22000 `logical
>> registers') has been changed to a limit of 0x40000000. A nice round number,
> ^^^^^^^^^^
> You mean 16#40000000# ?
Actually no. The Verdix compiler is written in C, not that silly Ada thing. :).
Douglas Surber
Lockheed
Houston, TX
Bruce Jones
>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
Michael Feldman
>
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
Arra Avakian
>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.
Alex Blakemore
> the developers really have to know Ada!
I believe Verdix's run time is also written in Ada, along with their new optimizer.
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 al...@cs.umd.edu NeXT mail accepted
david.c.willett
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!
bo...@cnam.cnam.fr
> great language for writing large programs, the new code is very readable
> and maintainable.
I take this opportunity to discuss about the best language to write a
compiler (a private discussion already occured, thanks for those who participated).
IMHO, it is better to write the compiler in the language it compiles,
whatever is this language.
It has several technical benefits:
- any improvment in the optimizer will optimize the compiler as well,
- this is the greatest test suite you can dream of: if it can compile
an Ada compiler, it will compile everything :-)
and a commercial one:
- it states clearly that you trust the language you try to sell.
I tried to list the languages used by some compilers. (If someone wants
to complete/correct this list?)
Compiler Language
Verdix C + now partly in Ada
Telesoft Ada
Alsys Ada
DEC Bliss + Ada (unknown proportions)
Meridian ?
Ada-Ed, first version SETL
Ada-Ed, second version C
Systeam ?
GNU Ada C, but may be an Ada version (?)
MILLS,JOHN M.
>...
[ lead-up discussion deleted ]
>IMHO, it is better to write the compiler in the language it compiles,
>whatever is this language.
>It has several technical benefits:
(1) >- any improvment in the optimizer will optimize the compiler as well,
(2) >- this is the greatest test suite you can dream of: if it can compile
>an Ada compiler, it will compile everything :-)
>and a commercial one:
(3) >- it states clearly that you trust the language you try to sell.
Without having come _close_ to writing a compiler or interpreter, I have
some very serious reservations about this reasoning.
Programming languages have various ranges of application, strengths and
weaknesses, and tradeoffs of power vs. mastery for effective use. I
couldn't select only one language to do all types of programming and feel
I had always the best tool. (Naturally, I think the USDoD's attempt to do
this with Ada forces some poor and expensive design decisions, some of which
were on my projects. .. Sorry, no details.) C was originally developed to
write operating systems, and its relative simplicity, implementation on
processors from 8080s to Crays (and targeting for an even _broader_ range),
led to its use for a lot of programming, development of C++ and a wide range
of programming support tools, etc.
Just because one needs (for example) a better FORTRAN compiler doesn't imply
the compiler should be written in FORTRAN. Some BASIC interpreters were
written in [compiled] BASIC, but they were generally not the good ones.
For all I know, Ada may _be_ the best language to write a compiler; in that
case it should be considered for Pascal compilers, etc. My plaint is with
the assumption that a single language has the qualities for any and all
applications.
I have seen OOP (in C++) used to provide special operations and data types
needed in DSP programming, allowing DSP code to be written in "near C."
Perhaps OOP will evolve some tool sets with [largely] common user and
programmer interfaces for _whatever_ language is best for the rest of the
program. That would help both camps, and is probably happening with
windows bindings, as we type.
>I tried to list the languages used by some compilers. (If someone wants
>to complete/correct this list?)
>
>Compiler Language
>
>Verdix C + now partly in Ada
>Telesoft Ada
>Alsys Ada
>DEC Bliss + Ada (unknown proportions)
>Meridian ?
>Ada-Ed, first version SETL
>Ada-Ed, second version C
>Systeam ?
>GNU Ada C, but may be an Ada version (?)
>
Several surveys have compared these various compilers, and I don't
recall any correspondence between user satisfaction and compiler source
language. Many users (including our team) report satisfaction with the
DEC product, in our case partly because of its close correspondence to
the XDAda for our MC680XX targets. We also use the RTAda version of the
Telesoft product, and found our development process much more painful
using that package. Depending on your benchmarks, an otherwise excellent
compiler may be unacceptable: if you _need_ 100 microsec. interrupts and
the package only turns around in 250, you're stuck!
One size _doesn't_ fit all, even in the same programming language.
Regards --jmm--
--
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: jm...@prism.gatech.edu
"f U cn rd dis, U mst uz Unix!!!" ...jaw
Paul Robichaux
[ deletia- reasons why Ada compilers are best written in Ada ]
>Without having come _close_ to writing a compiler or interpreter, I have
>some very serious reservations about this reasoning.
Fire away! As a former compiler developer, I have some disagreements
with your comments, and I'm sure some of the others will jump in (no,
not you, Ted.)
>Programming languages have various ranges of application, strengths and
>weaknesses, and tradeoffs of power vs. mastery for effective use. I
>couldn't select only one language to do all types of programming and feel
>I had always the best tool. (Naturally, I think the USDoD's attempt to do
>this with Ada forces some poor and expensive design decisions, some of which
>were on my projects. .. Sorry, no details.) C was originally developed to
>write operating systems, and its relative simplicity, implementation on
>processors from 8080s to Crays (and targeting for an even _broader_ range),
>led to its use for a lot of programming, development of C++ and a wide range
>of programming support tools, etc.
>For all I know, Ada may _be_ the best language to write a compiler; in that
>case it should be considered for Pascal compilers, etc. My plaint is with
>the assumption that a single language has the qualities for any and all
>applications.
It seems that you have rejected one extreme and adopted the other. I
didn't read Stephane's comments as indicating that Ada was the
language of choice for building _any_ compiler; rather, that writing
an _Ada_ compiler _in Ada_ was a good idea, for the reasons he
specified.
Your argument with that statement seems to turn on the point that C
(with its wide range of host & target machines and "relative
simplicity") is a better language because it's in wider use.
The reasons we liked Ada for ALS/N were the same reasons many other
projects chose Ada: better support for good software engineering
practice. The fact that our project happened to be a compiler also
enabled us to benefit from Stephane's list of benefits.. having a
better test suite than ACVC was certainly to our advantage :)
[ deletia- list of compilers & their source langauges ]
>Several surveys have compared these various compilers, and I don't
>recall any correspondence between user satisfaction and compiler source
>language. Many users (including our team) report satisfaction with the
>DEC product, in our case partly because of its close correspondence to
>the XDAda for our MC680XX targets. We also use the RTAda version of the
>Telesoft product, and found our development process much more painful
>using that package.
As you point out, there are more pieces to a development system than
just the compiler. DEC Ada produces good code, runs fast, and fully
supports interfaces to DEC's other products. Not all other
implementations are as nice, and of course the features which are
important to one application may be unimportant to another.
As has been pointed out hundreds of times here (and elsewhere), you
can write bad code in any language. I won't claim that DEC Ada, or
ALS/N, or any other tool is better because it was written in Ada;
however, I will claim that writing portable, modular, maintainable
implementations of large tools _is_ easier in Ada.
Regards,
-Paul, GT ICS '90
--
Paul Robichaux, KD4JZG | I shouldn't bitch / I shouldn't cry
robi...@lambda.msfc.nasa.gov | I'd start a revolution but I don't have time.
Bob Kitzberger
>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.
r...@visicom.com 10052 Mesa Ridge Court, San Diego CA 92121 USA
+1 619 457 2111 FAX +1 619 457 0888
Arthur Evans
has a lot of advantages. One of the biggest is the absence of rough
edges. All little annoyances in usage come forcibly to the attention
of those best positioned to fix them -- and they do so.
As for compiling the compiler being a good test: No single test is
adequate, and a vendor requires an extensive test suite of programs.
However, to the extent that a compiler stresses corners of the
performance envelope missed by other tests (and I think it does), self
hosting is a useful contribution to quality.
Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD Ada Consultant
461 Fairview Road
Pittsburgh PA 15238-1933
412-963-0839
a...@sei.cmu.edu
Michael Feldman
>ar...@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.
>
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)
mfel...@seas.gwu.edu (Internet)
"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------
Jacob Baekke-Groome
>In article <91...@verdix.verdix.com>, bru...@verdix.com (Bruce Jones) writes:
>...
>> 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.
I can only say that we have had the same reasons for using Ada to write our
Ada compilers.
>- this is the greatest test suite you can dream of: if it can compile
>an Ada compiler, it will compile everything :-)
This is not completely true - our experience is that we do not use all
facilities in Ada extensively - compilers are basicly sequential processes
so you do not need tasking and interrupt handler etc.
>I tried to list the languages used by some compilers. (If someone wants
>to complete/correct this list?)
>Compiler Language
DDC-I Ada
>Verdix C + now partly in Ada
>Telesoft Ada
>Alsys Ada
>DEC Bliss + Ada (unknown proportions)
>Meridian ?
>Ada-Ed, first version SETL
>Ada-Ed, second version C
>Systeam ?
>GNU Ada C, but may be an Ada version (?)
>-------------
>Stephane Bortzmeyer Conservatoire National des Arts et Metiers
/-----------------------------------------------------------------------\
|Jacob Baekke-Groome j...@ddci.dk |
|DDC International A/S |
|Gl. Lundtoftevej 1B tel +45 45 87 11 44 x 332 |
|2800 Lyngby fax +45 45 87 22 17 |
|DENMARK |
|To do it with Ada - is better that to C it ;-) |
\-----------------------------------------------------------------------/
Bob Kitzberger
>This is not completely true - our experience is that we do not use all
>facilities in Ada extensively - compilers are basicly sequential processes
>so you do not need tasking and interrupt handler etc.
Some compiler vendors write their runtime libraries (including tasking,
board support packages, etc.) in (mainly) Ada. As such, interrupt handlers,
representation specs, etc. are put through the ringer.
Jim Lonjers
>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.
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.
Bob Kitzberger
>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.