soft-eng@MITRE.ARPA (Alok Nigam) (08/07/88)
Soft-Eng Digest Sun, 7 Aug 88 V: Issue 23
Today's Topics:
Basics of Program Design
Call for participation - software CAD databases workshop (2 msgs)
COCOMO software estimating model (2 msgs)
Language-based editors (4 msgs)
Looking for a program to merge two files interactively
Proving software correct
using (ugh! yetch!) assembler (6 msgs)
----------------------------------------------------------------------
Date: Tue, 2 Aug 88 10:30:11 BST
From: Gordon Howell <mcvax!hci.hw.ac.uk!gordon@uunet.UU.NET>
Subject: Basics of Program Design
>Date: 4 Jul 88 05:46:58 GMT
>From: ucsdhub!hp-sdd!nick@ucsd.edu (Nick Flor)
>Yikes. It is kind of scary reading some of the responses to your posting James.
>Seems like there are a lot of programmers employing ad hoc methods in the
>development of their software. Reminds me of a story Professor W. Howden...
...
>
>To understand what tools are needed to develop a program, one first needs
>to understand the techniques humans use to solve complex problems.
>For things that are too complex, humans use two main techniques:
>
>1) Abstraction
>2) Decomposition
I think you've hit upon the real dilemma here --- how to reconcile the
realities of software engineering with the ideal of scientific
formalism. I applaud your sensible start at introducing reason to the
proceedings. I'd like to carry the topic a little higher, if I can
manage... (using the techniques, of course, of abstraction and
decomposition!)
First, the Subject: is misleading; I think we are discussing "system
design"; or even more abstractly, "engineering". For a moment, I'd
like to pretend "software" doesn't exist, and look at the fundaments
of good engineering practice.
Engineering is the art of applying theories based on perfection to a
world based on imperfection.
Clearly, software engineering must embrace the pragmatic, while
espousing the ideal. The direct result of this observation is that we
cannot hope to create an engineering methodology that itself is
perfect --- thus in a certain sense this discussion is meaningless!
But what we *can* do is engineer an engineering methodology suitable
for this class of problems (software). What does this mean?
When presented with an endeavour, the first step the engineer must
undertake is to sort out how they will go about solving the problem.
This is the step that is usually done "intuitively" (if at all); which
eventually leads to the informal ad-hoc procedures cited. These
procedures may not be *wrong*, but owing to the lack of discipline, we
lose the 'Newton Effect' of shoulder-standing.
{comments pointing out the design symptoms resulting from deficiencies
in this process (ie. poor user interactions <my bugbear>; maintain-
ability;&c) have been deleted here. Privately send me your favorites!}
Perhaps an implementation of this effort would be:
1. A way of thinking (call it 'art')
2. A canonical procedure
3. A set of guidelines (heuristically determined)
[Note that my conception of this 'meta-methodology' is itself somewhat
ad-hoc in nature; but if I start looking at the intuitive process I am
currently undergoing (my method for engin'r'g an engin'r'g
methodology!) I will blow a brain-fuse...]
I'm not going to go into any detail here, but just to stir up some
decent controversy, I'll add some of my gut opinions about this [God, I
can't think of a better term] meta-methodology.
Do not get the idea that I am saying we are using poor/outdated design
techniques, or even that software engineers are as a lot disorganized
and/or incompetent. It is possible to attack a problem with a highly
disciplined, logical engineering method and still end up with a
hostile user interface (f'r'instance) owing to lousy design; but on
the whole, I believe quality and competence are the rule, rather than
the exception. The problem is simply that competence is *not
exported* to other engineers, and one reason I feel for this problem
is a lack of discipline in the methodology.
Also take note that one of the more obvious manifestations of this
problem lies in management. All technical people I know complain
about bad management; but the fault is bi-directional. What is the
engineer who fails to "properly" organize an attack strategy on a
complex problem guilty of? Bad management.
As a consulting software engineer, I don't need to know *anything*
about the technical problem I am confronted with. I would use many of
the same techniques in planning how to learn Russian as in planning
how to design a user interface.
There's a *lot* more I could say about this, but I will stop now (too
long already) and ask you the following questions:
1. Do you understand me? (Because if you don't; I don't -- my fault)
2. Do you think this is a real issue? (or just smoke...)
3. Is there significantly more thought and useful work that could go
on here?
4. Assuming all of the above, could you forsee the possibility of
software tools to support 'methodology design'?
In case you were wondering --- I am working on a PhD in software
engineering methodologies promoting good human interactions, and am
seriously considering focusing on this issue. My research on the
failings of UI design so far all seem to point to a more fundamental
cause than typically cited (eg: poor specification techniques, lack of
UI separation, poor user task modelling, etc...) I think the best
feedback I can get at this point is simply by asking fellow engineers:
Do you agree?
------------------------------
Date: 4 Aug 88 06:43:46 GMT
From: larry@postgres.berkeley.edu (Larry Rowe)
Subject: Call for participation - software CAD databases workshop
CALL FOR PAPERS AND PARTICIPATION
Software CAD Databases Workshop
Dates: Feb 27-28 1989 (ACM) Location: Napa, Calif.
Sponsored by: ACM SIGMOD and SIGSOFT
A software CAD database is a critical component in a full-
function, Software Computer-Aided Design System (SCAD) sys-
tem. A SCAD database contains all information relating to
the software development process including: requirements and
design specifications, internal and external documentation,
development schedules, program source and object code, sys-
tem configuration specifications, release data, and bug
reports. SCAD databases are being developed by many
research and industrial groups.
Experience has proven that conventional relational
databases are not able to satisfy the requirements of a
full-function SCAD system. Researchers in the database
community are working on next generation database systems
(e.g., extensible relational, object-oriented, and database
toolkits) that they believe will solve the problems that
conventional relational systems cannot solve.
This workshop will bring together a group of leading
researchers and industrialists to discuss problems, work-
in-progress, and possible approaches to the design and
implementation of SCAD databases. It will be organized into
presentation and discussion sessions. Each participant will
present a summary of his or her work in one of the presenta-
tion sessions. Discussion sessions will be organized around
the various open issues.
Workshop attendance will be limited to 40 people to
foster in depth discussions and close interaction between
the participants. Prospective attendees should send 6
copies of a 3 page summary that describes their past work
and/or proposed contribution to the workshop to the address
below by 28 October 1988.
Professor Lawrence A. Rowe
Computer Science Division - EECS
University of California
Berkeley, CA 94720
Topics of interest include but are not limited to data
abstractions for program representations, database designs
for SCAD systems, database management system support for
SCAD, and practical experience with SCAD databases.
The organizing committee will read all submissions,
select the participants, and organize the workshop. The
members of the organizing committee are:
Barry Boehm William Passman
-TRW Defense Systems Group -Atherton Technology, Inc.
David J. Dewitt Lawrence A. Rowe
-Univ. of Wisconsin -UC Berkeley
Leon Osterweil Stanley B. Zdonik
-UC Irvine -Brown University
Participants will be notified in early December of the
acceptance of their contribution. Final position papers
will be due 20 January 1989. They will be published in a
proceedings produced before the workshop.
------------------------------
Date: 4 Aug 88 16:23:36 GMT
From: ubc-cs!nobody@beaver.cs.washington.edu
Subject: Call for participation - software CAD databases workshop
> ... Software Computer Aided Design
Surely that should be Computer Aided Software Design (CASD yes, SCAD no!).
------------------------------
Date: 31 Jul 88 08:39:47 GMT
From: amdahl!nsc!taux01!taux02!yuval@ames.arpa (Gideon Yuval)
Subject: COCOMO software estimating model
In article <569@csdgwy.csd.unsw.oz> ewa@csdgwy.csd.unsw.oz writes:
>Perhaps someone on the net can tell me how I might be be able to buy a COCOMO
>program.
WICOMO (Wang Institute COst MOdel -- a version of COCOMO)
is available for $70 from:
Gary Perlman
617-566-6858
P.O.Box 1880
Brookline, Mass, 02146, USA
------------------------------
Date: 3 Aug 88 13:11:20 GMT
From: steinmetz!daredevil!vita@uunet.uu.net (Mark F. Vita)
Subject: COCOMO software estimating model
In article <685@ritcv.UUCP> ark@ritcv.UUCP (Alan Kaminsky) writes:
>> Perhaps someone on the net can tell me how I might be be able to buy a COCOMO
>> program.
>
>In my opinion, any specialized COCOMO program is a waste of money. I advise
>you to spend your money on a general-purpose spreadsheet program, then take
>an hour or so to program the COCOMO model into it. The resulting "COCOMO
>program" will be far more flexible than a specialized program, since you
>have all the capabilities of the spreadsheet at your disposal as well as
>the COCOMO model.
Yes, you have a point here. The COCOMO model is not all that
complicated, and it would seem to make good fodder for a spreadsheet
program. However, this could be said about nearly any numerical
model; i.e. "any specialized XXX program is a waste of money, as you
can just get a spreadsheet and program the XXX model into it."
The key issue, though, I think, is user interface. In my opinion,
spreadsheets are only slightly above pencil and paper as far as
pleasantness of user interface is concerned.
This may be why, for example, "personal finance" programs for micros
sell so well. It would be easy enough to come up with a spreadsheet
that would handle all this stuff, figure out your taxes, etc.
However, many people (especially ones who aren't spreadsheet junkies)
prefer dedicated, off-the-shelf programs that have generally have a
much nicer interface, some quick, convenient predefined graphs, nice
reporting features, etc. For some, the convenience and ease-of-use of
such programs makes them worth the additional expense, despite the
fact that the underlying "model" isn't all that complex.
So I think it may be a bit of an overstatement to assert that "any
specialized COCOMO program is a waste of money."
------------------------------
Date: 29 Jul 88 22:52:00 GMT
From: a.cs.uiuc.edu!m.cs.uiuc.edu!liberte@uxc.cso.uiuc.edu
Subject: Language-based editors
Here is a repost of our earlier announcement.
------
We have released Leif, a language oriented editor that is based on
a recognition paradigm. In a recognition paradigm the programmer enters
text and the editor incrementally analyzes this text to determine structure.
Many other language oriented editors are based on templates. In these
editors, the program is constructed by expanding templates. Template
editors prevent the creation of syntax errors by restricting the possible
edits. In Leif, the programmer may use all of the text editing commands
of a host editor (GNU Emacs) to create a program. The programmer may also
use language oriented commands. At any point, the syntax analysis may be
consulted to locate syntax errors or display the structure of the program.
By using a standard text editor as the front end, Leif offers several benefits.
First, there is very little overhead in learning to use Leif. By learning
only one new command, the "move to syntax error" command, Leif can be useful.
Other commands allow a programmer to see the structure of the program or
examine a syntax error. A second benefit is that the user can edit the
program as text or as syntax simultaneously.
Leif has respectable performance. It uses an incremental parsing algorithm
to analyze changes to the text and to maintain a parse tree. If a change is
made that affects only a local part of the parse tree, only that part is
Analysis does not occur on every key stroke. Instead, Leif allows any
number of consecutive changes to be processed as a unit. The programmer may
use Leif transparently and request information from the parser when it is
needed. Once started, Leif does not require any actions by the programmer
for it to follow an editing session. Until a Leif command is activated,
the user does not notice any change in the editor. This translates into an
efficiency benefit and further enhances the ease of use.
A language for Leif is specified as a lexical analyzer and LALR(1) grammar.
Standard tools, Lex and Bison (similar to Yacc), are used to process the
specification. Once the tables produced by these tools have been converted
into an appropriate parse table format, Leif use the tables and edit text
in the language. Prototyping the syntax of a language is easy and a
designer of a language may specify a language and experiment with it quickly.
The language need not be a programming language, but could instead be a
specification, design or text processing language as long as a language
fits in the lexical analyzer and parser paradigm.
Leif is available via anonymous ftp from a.cs.uiuc.edu. The files are
located in the subdirectory pub/Leif. Consult the file README.DIST that
is in that directory to decide which files to retrieve. Documentation
is available in the file leif-doc.tar.Z. (If you are unable to retrieve
the files via ftp, please contact us.)
Please send Leif related queries to ihnp4!uiucdcs!leif or leif@a.cs.uiuc.edu
Bill Smith, Dan LaLiberte, Roy Campbell
------------------------------
Date: 29 Jul 88 02:08:00 GMT
From: oliveb!intelca!mipos3!td2cad!jsedayao@ames.arpa (Jeff Sedayao )
Subject: Language-based editors
>I am looking for product information about language-based editors.
What about emacs? It has a number of language sensitive modes, and
you can make up your own modes if you want. There are also versions
for MS-DOS, VMS, and UNIX. I am not sure if the Synthesizer Generator
runs on VMS or MS-DOS. These are not mentioned in my manual, but
versions could exist.
>"The synthesizer Generator creates a language-specific editor from an
> input-specification that defines a language's abstract syntax, context
> sensitive relationships,..."
That it does. The input language is a bit crusty, though, as is some
of its user interface. What I really like about it is that it allows
the user to put up templates of the language and all you have to do
is fill in the blanks. The generator comes with specifications already
made for pascal and c. Source is also included (there's lots of it!).
>I have two questions:
>
>1. How and where can I order this Synthesizer Generator?
Send mail to Liz Maxwell at maxwell@gvax.cs.cornell.edu
She will be able to tell you how to get the editor.
>2. Are there any similar products available?
There is emacs, like I mentioned above. There is also something called
LEIF which is a tool built on top of emacs. I am not sure how to get
it. Also, at UC Berkeley, there is an editor called pan that is
language sensitive. You can ask Susan Graham graham@renoir.berkeley.edu
about getting it. Pan is limited to running on suns, though.
------------------------------
Date: 31 Jul 88 02:31:11 GMT
From: ucsbcsl!bertrand@bloom-beacon.mit.edu (Bertrand Meyer)
Subject: Language-based editors
This is a follow-up to <2135@mhres.mh.nl>, where ml@mhres.mh.nl
(Marco Luiten) writes:
> I am looking for product information about language-based editors.
I believe our Cepage editor fulfils the stated criteria.
This is a commercial product. Cepage is certainly
WYSIWIG (although it works for character-oriented terminals and does not use
graphics or the mouse for the moment). It supports both structural (menu-driven)
entry and keyboard input (which is parsed). For keyboard-driven input,
a text editor is included. In this mode, you may skip parsing if you want
to enter temporarily incorrect input; you can come back later on, correct
or complete your entry, and have it parsed then.
An important aspect of the Wysiwig aspect is the presence of a completely
automatic algorithm for document formating (including indentation, adaptation to
the available window space, layout etc.). The algorithm was described in a
rather extensive article by myself, J-M Nerson and Soon-Hae Ko in Science of Computer
Programming, 1985. (Sorry, I don't have the exact issue and page numbers offhand
but they should be easy to find.) The article describes the formatting algorithm
and provides parts of a formal proof.
The most original aspect of Cepage is the ease of adaptation to any language.
Grammars are described in a simple formalism called LDL (Language Description
Language). There is no restriction such as LR (k) or similar. Grammars can
be written quickly and then changed easily, to accommodate local variants or
specific programming or documentation styles. The system comes with pre-written
grammars for Pascal, C, Troff, Lisp, Ada, Fortran. As the Troff example shows,
the applications of Cepage are not restricted to programming languages;
for example you can apply it to standardized technical documentation.
The system is written in the Eiffel object-oriented language and runs wherever
Eiffel runs, which means Unix (Sun, Apollo, Ultrix, HP etc.) and, soon,
VAX-VMS.
Various references have been published on an older version of Cepage, including
the one mentioned above and a paper called ``Cepage: A Software Design Tool''
that I published in Computer Language, September 1986. We have more up-to-date
reports of which I can send copies on request.
------------------------------
Date: 1 Aug 88 21:05:50 GMT
From: att!chinet!mcdchg!clyde!watmath!utgpu!utzoo!yunexus!oz@bloom-beacon.mit.edu (Ozan Yigit)
Subject: Language-based editors
In article <2135@mhres.mh.nl> ml@mhres.mh.nl (Marco Luiten) writes:
>I am looking for product information about language-based editors.
University of Illinois @ Urbana has a language-sensitive and
programmable editor, used to be known as FRED. [I do not know its
recent name] I think it may be available via anon. ftp from
uiuc.cs.edu. It is wysiwyg, works with partial language grammars,
programmable, and the last time I looked, it did handle C and
Pascal. It allows one to define a grammar for a language one wishes
to edit, and partial grammars allow it to do a reasonable job with
minimal language knowledge. It is in C, and sources are [were]
available.
------------------------------
Date: 5 Aug 88 22:04:28 GMT
From: ai.etl.army.mil!hoey@ames.arpa (Dan Hoey)
Subject: Looking for a program to merge two files interactively
>I have a program which consists of about 100 different files. A couple of
>months ago, I began two sets of modifications to this program, each of which
>was kept in a different directory. I now would like to merge these
>modifications into a single program.
You haven't mentioned whether you kept around a crucial piece of information:
the common ancestor from which both versions were derived. There are several
programs such as RCS's "merge" (based on Unix's "diff3") that can be used to
merge the versions semi-automatically. Where the modifications overlap, both
pieces are included in the output, and you get to merge them automatically with
your favorite editor.
------------------------------
Date: Wed, 03 Aug 88 17:29:15 PDT
From: PAAAAAR%CALSTATE.BITNET <Dick Botting (doc-dick)>
Subject: Proving software correct
In Soft-Eng Digest v5n22
>phoenix!pucc!EGNILGES@princeton.edu (Ed Nilges)
writes
>IN Soft-Eng digest v5n20 , PAAAAAR%CALSTATE.BITNET writes:
>>There are other kinds of comments.
>>Many text books and papers state that you should
>>write *assertions* which state what you want to be true at that
>>point in the program.
>[quote deleted]
>> There are about 5 people world wide who use assertions in this way
>> and they all earn their cash by writing books about programming not
by
>> programming...
>> :-)
>The attitude evidenced by this posting is one of the reasons why software
>continues to be late and hard to maintain.
I take this to be about on my sense of humour/humor.
>Assertions are only
>impossible to write when the software has not been designed in
>a structured and modular fashion.
>[definition of and examples of 'assert' in C]
The poster confuses the 'assert' function of C's and the
"Invariant Assertions" I was writing about.
"Assert" functions should be used on any large project
to instrument the code.
Perhaps I should have been less cryptic...
I was not talking about any function or tool.
I ment the work done prior to C by Floyd, Hoare, Knuth,
Manna, Dijkstra and others, which still appears in elementary Comp Sci
Texts. These all present programs that are PROVEd to work using the
"invariant assertions" that where invented by Floyd way back in the 50's.
>My assertions do not PROVE my software correct...
The people mentioned above have assertions that do!
>...any more than the designers
>of the Golden Gate Bridge (reference 2) could PROVE mathematically that
>the GG Bridge would stay up and be beautiful to boot.
Did they make drawings?
(using perspective & descriptive geometry)
Did they prove that the the bridge was long enough?
(using geometry, trigonometry, etc)
Did they calculate stresses and strains?
(using elementary mechanics/applied math)
Those engineers that I used to know used Math to PROVE that
the thing SHOULD work and then added a safety factor in case they
had left something out.
They also expected one or two bugs to turn up when the job was done...
>I don't feel that it is possible to PROVE software correct.
Ed provides evidence of my key point...
REAL PROGRAMMERS FAIL TO PROVE THE CORRECTNESS OF THEIR PROGRAMS.
I hope that somewhere in/on the networks someone is ready to disprove this...
------------------------------
Date: 29 Jul 88 18:49:49 GMT
From: trwrb!aero!venera.isi.edu!raveling@bloom-beacon.mit.edu (Paul Raveling)
Subject: using (ugh! yetch!) assembler
In article <37247@linus.UUCP> munck@linus.UUCP (Robert Munck) writes:
>In article <9763@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes:
>
>>This just isn't true. There are an aweful lot of real live products,
>>and BIG ones, that have been built in assembly language. Have you
>>read _The_Mythical_Man-Month_? 5000 man-years it did take, but OS/360
>>was a whole bunch of assembly code (millions of lines, minimum) that
>>has probably made IBM billions.
>
>Nah. Some of you may not have been born yet then, but I was one of the
>first non-IBMers to sysgen OS/360 rel 1 (PCP) in 1966 or so, and
Me too.
>probably as familiar with the source code of OS, releases 1 .. 21, as anyone
Once I was, but I wanted to forget them as fast as possible.
> ... It was, of
>course, "disassemblies" of the output of the legendary BSL compiler (Basic
>Systems Language, later PL/0). By Release 14 (that great release; I
>think Yale is STILL running it), all new modules were BSL.
I don't recall noticing those features, but maybe that explains
why so much of that code was so awful. On the other hand,
those comments the code generator stuck on the right side
of instructions would be the envy of both our natural language
synthesis group and someone else's compiler group. Maybe
we tended to work in different parts of OS/360.
The first code I can guarantee wasn't hand-coded assembly
language was the PL/S that began creeping in around Release 18
(plus or minus epsilon). It was such a curiosity that I
immediately looked at some and spotted a bug within 5 minutes.
An exception would be compilers such as FORTRAN H, which
used a lot of FORTRAN.
>>I write a 25000 line assembly program (for a class) about 4 years ago
>>that was well organized, documented, etc. I have no doubt that it
>>could be modified and maintained today (or 10 years from now).
>
>How about moved to another CPU?
Portability is the biggest argument for avoiding assembly.
It IS feasible to write well-documented, easily maintainable
assembly code. Anyone with a performance-critical application
should consider it; in my experience it takes around 20%
more time to write in a decent assembly language than in
a decent higher level language, and the code runs about
3 times faster... Unless the high level language is LISP -
then the speed ratio is about an order of magnitude.
A notable exception is a crummy machine language, such as
Intel's 8*86's. Over my 8 years of having to deal with these
atrocities, it probably took at least twice as much time to
produce "good machine language code" as it did to produce
equivalent C. (The 8*86 architecture doesn't really allow producing
"good machine language code" by comparison with most other
hardware architectures.)
>Yeah, sure, it's possible to write
>organized, maintainable assembly code (though the concepts of
>"maintenance" and "documentation" at universities are VERY different
>from the commercial and military worlds.) Real-world schedule and
>funding pressures make it very unlikely that it would stay organized,
>documented, and maintainable for very long after release.
In my experience in all three worlds, the best documentation
has tended to be found in the commercial world. The most
documentation was in the MIL-spec world, but the requirement
was for so much of it that it was a miracle if a substantial
part matched the actual system. The university world, or
at least the part whose software I've seen lately, produces
minimal documentation, and what exists is of little use.
------------------------------
Date: 29 Jul 88 15:32:46 GMT
From: clyde!mcdchg!nud!anasaz!john@bellcore.bellcore.com (John Moore)
Subject: using (ugh! yetch!) assembler
>>>[...]assembly language will "fit" only
>>>the smallest, most toy-like, never-to-be-used-for-real prototypes.
If you ever make an airline or hotel reservation, or use a credit card
and have an authorization check run on it, you are making use of very
large systems written entirely in assembly language! These systems are
based on IBM's TPF (previously ACP - Airline Control Program). They
may contain millions of lines of applications code. Likewise, if you
fly in an airplane at one of the airports with the older ARTS traffic
control computers, you are again depending on a large assembly language
system.
None of this is to imply that assembly language is a good way to do
applications! Just to show that some extremely large systems are done
that way.
------------------------------
Date: 2 Aug 88 23:14:33 GMT
From: attcan!utzoo!henry@uunet.uu.net (Henry Spencer)
Subject: using (ugh! yetch!) assembler
>If you ever make an airline or hotel reservation, or use a credit card
>and have an authorization check run on it, you are making use of very
>large systems written entirely in assembly language! ...
If I'm not mistaken, Sabre (American Airlines) for one is written in
a PL/I variant and has been for many years. They got burned by the
conversion to the 360 and swore that they would never again write in
assembler.
------------------------------
Date: 3 Aug 88 14:59:38 GMT
From: steinmetz!davidsen@uunet.uu.net (William E. Davidsen Jr)
Subject: using (ugh! yetch!) assembler
One of the claimed advantages of assembler is that you can't get
burned by changes in the compiler causing bad code. Unfortunately
assemblers do generate bad code, too, on occasion. One example was the
GMAP assembler for the GE600. Certain instructions mush be in odd
locations, such as RPD, and in some cases that was not forced. I think
it was if the RPD was the result of the expansion of a macro or
something, but it was 20+ years ago.
The Intel assembler for the 80386 still recognizes several bit
load/store instructions which have been removed from the chip. I doubt
that anyone outside of Intel ever used them, but unknown instructions
really should be flagged.
------------------------------
Date: 2 Aug 88 20:02:23 GMT
From: linus!philabs!ttidca!hollombe@husc6.harvard.edu (The Polymath)
Subject: using (ugh! yetch!) assembler
In article <1148@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
>None of this is to imply that assembly language is a good way to do
>applications! Just to show that some extremely large systems are done
>that way.
Another example:
Most of the code in the Space Shuttle's on board computers is written in
assembler. I know because I once had to document a large chunk of it (the
Initial Program Load (IPL) module).
------------------------------
Date: 5 Aug 88 17:36:26 GMT
From: ncar!noao!nud!anasaz!john@ames.arpa (John Moore)
Subject: using (ugh! yetch!) assembler
> One of the claimed advantages of assembler is that you can't get
>burned by changes in the compiler causing bad code. Unfortunately
>assemblers do generate bad code, too, on occasion. One example was the
>GMAP assembler for the GE600. Certain instructions mush be in odd
>locations, such as RPD, and in some cases that was not forced. I think
>it was if the RPD was the result of the expansion of a macro or
>something, but it was 20+ years ago.
There was some sort of pseudo-op to force that, I think... (been about 17
years for me)
------------------------------
End of Soft-Eng Digest
******************************EGNILGES@pucc.Princeton.EDU (Ed Nilges) (08/08/88)
In article <8808071435.AA05123@mitre.arpa>, soft-eng@MITRE.ARPA (Alok Nigam) writes: >Soft-Eng Digest Sun, 7 Aug 88 V: Issue 23 > >Today's Topics: > Proving software correct > >Date: Wed, 03 Aug 88 17:29:15 PDT >From: PAAAAAR%CALSTATE.BITNET <Dick Botting (doc-dick)> >Subject: Proving software correct > > >>Assertions are only >>impossible to write when the software has not been designed in >>a structured and modular fashion. >>[definition of and examples of 'assert' in C] > >The poster confuses the 'assert' function of C's and the >"Invariant Assertions" I was writing about. >"Assert" functions should be used on any large project >to instrument the code. >Perhaps I should have been less cryptic... >I was not talking about any function or tool. >I ment the work done prior to C by Floyd, Hoare, Knuth, >Manna, Dijkstra and others, which still appears in elementary Comp Sci >Texts. These all present programs that are PROVEd to work using the >"invariant assertions" that where invented by Floyd way back in the 50's. No, there is a difference between invariant assertions and the assert() function (of course!). I am suggesting that we start using asserts in real code as a way of proving (but not PROVING) our software correct. I also feel that English-language arguments have a role in proving (but not PROVING) our software correct. > >>My assertions do not PROVE my software correct... > The people mentioned above have assertions that do! That's wonderful, Dick! But my concern in the real world is not PROVING software correct. It is proving software correct. The difference in case is meant to point up the intractability of the problem. Let me see if I can explain it better. I (or any competent programmer) can write a perfect Game of Life or even a perfect compiler for a toy language and PROVE it correct. Here, mathematics is tracking mathematics and, as such, perfection is attainable. I cannot write a PROVABLE battle management system or even a PROVABLE payroll program. This is because here, mathematics is trying to track something OUTSIDE of its realm. The problem is similar to that faced by Post and Turing in PROVING that Turing machines, or Post's system, captured our intuitive notion of computability. It is impossible in a formal sense, for you cannot formally map the mathematical onto the intuitive. However, and this is important, I can prove my payroll program correct (I don't know about battle management because, you see, I won't work on such projects). Not PROVE...prove. How? By using the techniques of program correctness proving, scaled-down and humbled so they work in the real world. I envision more and more formal techniques being used as software evolves! But I don't foresee a day when all software shall be PROVED correct. Another thing to keep in mind is that the viewpoint of as program as a static thing which is PROVED correct has produced a lot of maintenance nightmares, late hours, and plain old heartbreak. A program is more fruitfully viewed as a set or collection of programs evolving over time. Any applicable model of correctness proving must allow for maintenance of the correctness proof such that transforms which preserve correctness are encouraged and those that do not are dis- couraged, and the proof is updated along with the program. >>...any more than the designers >>of the Golden Gate Bridge (reference 2) could PROVE mathematically that >>the GG Bridge would stay up and be beautiful to boot. >Did they make drawings? > (using perspective & descriptive geometry) >Did they prove that the the bridge was long enough? > (using geometry, trigonometry, etc) >Did they calculate stresses and strains? > (using elementary mechanics/applied math) >Those engineers that I used to know used Math to PROVE that >the thing SHOULD work and then added a safety factor in case they >had left something out. >They also expected one or two bugs to turn up when the job was done... > But they didn't PROVE it, did they? >>I don't feel that it is possible to PROVE software correct. >Ed provides evidence of my key point... > REAL PROGRAMMERS FAIL TO PROVE THE CORRECTNESS OF THEIR PROGRAMS. Real programmers eat quiche! >I hope that somewhere in/on the networks someone is ready to disprove this... > I hope so to! But it shall be a long and winding road. The best advice is given by Robert L. Baber's The Spine of Software. Programmers today should learn these techniques so that they stand ready to use them when they are introduced.