Inteliiotnt editJSHB

An editor is a person who takes text pre­pared by a writer, fixes mistakes, inr^proves ofS^. i^ikKi. ΒΓ^ o t f^fwl^ rmkss d i a * ^ ^ and t»^n passes it back to the writer, usualty with recomnr>endations for addi­tional improvenrvents. An editor can also be a program that acc^pis keyboard input from a writer and allows it to be easily rTMxlIf led before being passed on to a type­setter, compiler, or other destination. Human editors make significant choices about style, organization, and content while handling text, whereas software edi­tors generally leave users to make their own choices.

(n some cases, however, intelligent soft­ware ^f iofs are beginning to eKercise some discrimination about what users actually write. The most widely known ex­amples are spelling and style checkers, such a s those available on the writers' workbench under the UNIX operating sys­tem, or for microcomputers under various operating ^^^^·τ\ζ. ΜοΓέ ^ynufyiaiiu are language-specific program editors, which "know" about the syntax of the language they are being used for and can act appro­priately

Possibly the first of these were intelli­gent editors for LISP, the artificial-intelli­gence language. lISp editors, which run t>oth on specially designed LiSP machines and on mainframes or minicomputers, are largely useful because they can keep track of the innumerable parentheses that de­marcate lists, lists of lists, and lists of lists of lists within the language. To make pro­grams understandable, they can fomnat source code so that a given level of nest­ing yields a consistent indentation (a func-tk>n sometimes known as prettyprinting), and they can also deal with lists as single obiects, copying program text within a set of matching parentheses from one place io anoihef, moving the cursor from the beginning of a list to its end, and so forth.

Other indented languages, such as Pas­cal, can also benefit from prettyprinting editors. More important for languages such a s Pascal, however, is the develop­ment of editors that can recognize pro­gramming cliches, such as the basic con-sirucls of structured programming: While-Do, if-Then-Else, and so forth. An editor that can provide source-code templates for the programmer to fill out can signi­ficantly improve productivity, especially in less structured languages such as Fortran or Cobol. where the appropriate cliches are not always obvious. Intelligent editors can also be combined with preprocessors for unstructured languages, so that the programmer can use structured code, which is then translated into the requisite unstructured statements before being compiled.

In addition to making programming a fiii-inthe-blanks exercise, Janguage-spe-cific l i t e r s can also make sure that the blanks are filled in correctly, checking the syntax of program code as it is entered. Such ediiors exist in some high-end sys terns where program developnient is an­cillary to other functions, such as hard­ware testing, and also in some very iow-

PROGRAM NOTES

SOFI WARE rOPICS

end systems: the Sinclair/Timex 1000 home microcomputer, for example, will not accept a line of Basic code unless it is syn-tacticauy c-orrect.

Computers as physical objects In the early days of computers, pro grammers were acutely aware of the physi­cal realizations of the idealized Gomputing machines they worked with: Grace Murray Hopper scouted the interior of the Mark I at Harvard for moths; Alan Turing in Man­chester, England, was reputed to have a particular flair for programming memo each evening's particular hardware failures; and an unnamed computer oper­ator in Africa augmented his paycheck by kicking the central processing unit at the appropriate point during its monthly calcu­lations. Even during the late 1%0s, pro­grammers, by checking results, could detect when the air-conditioning unit for an IBM mainframe first began to fail.

Today, most programmers deal with their machines only in an abstract fashion: though processing cycles are an important commodity, their precise number is seldom significant. In certain video-game hardware, programmers must synchronize their actions to the movement of the elec­tron beam across a television screen, but most run-ofthe-mill computing applica-tk>ns are less demanding, especially as computing power and speed increases, so that a few more central-processing unit cycles more or less shrink in maonitude.

in some high-speed processing situa­tions, however, physical considerations have reared their head again: supercompu­ters, for example, are currently limited by the number of circuits that can be placed within the distance spanned by an electri­cal signal in a single processing cycle, or else iheif different components could become hopelessly out of step. Multipro­cessing systems, where independent seg­ments of a calculation are parceled out among different processors, are the solu-tk>n currently t>eing adopted, although at­tempts are also being made to shrink com ponents further and reduce their heat dis­sipation so that they can be placed togeth­er without melting. {Conversely, heat re­moval can be increased by arcane methods, such a s the Cray-2 supercompu­ter's expedient of a large aquarium filled with circulating flourocarbon liquid.)

As prcK;^ssing speeds increase for more pedestrian machines, some of the sa,me problems may crop up as are now faced by supercomputers: physical place­ment of parts will become important to performance in subtle ways. Though much of this may be masked by the hardware designer, programmers (at least those who write compilers) may have to t^come cog­nizant of the physical configuration of machines; certain areas of menoory may

require more time to access than other areas, and in multiprocessor systems, communication between neighboring or distant processors may take place on significantly different time scales. One current maker of a multiprocessor super­computer has attempted to ameliorate the synchronization probSsm by piocing queues, or buffers, within individual pro­cessors and between proces^rs and memory so that even if a message to the outside world takes an unexpectedly long time to send or receive, each processor will still have some things to do.

Code-quality metflcs How is a particular piece of source code? The right answer to that question depends on what one means by "good,** of course, and actually getting an answer to the question depends on having some way of translating a definition of "good" Into a form that can t>e applied consistently to programs. One method is to give the source code to an expert programmer and ask, "How good is this code?" but it re­quires the availability of an expert pro­grammer. Some egregious programming constructs can be recognized even by novice programmers, and a fair amount of work has been done in converting qualita­tive evaluations into tests that can be run by a computer program, possibly using itself as a testbed.

Depending on the particular language, code-quality programs can look at various features of a program: variables initialized but never used, variables used but never initialized, subroutines never called, and the like are common in older, less struc­tured languages, while factors such as the number of variables, functions, or proce­dures interchanged between supposedly independent modules can be an interest­ing metric for structured programming lan­guages, metrics ίηαΐ measure ihe fre­quency of certain constructs known to be error-prone, or the number of layers pro­gram execution must pass through before it reaches a routine that actually performs an action or computation, are also occa­sionally used.

Software metrics tend to award high scores to programs generated by prepro­cessors, which translate programs written in pseudoforms of high-level languages in­to forms that compilers can accept. This makes sense, since the purpose of struc­tured-programming methodologies is to help humans cope with complexity, and eomputefs ihemseives have iiitie trouble dealing with inordinately elaborate book­keeping, overly long subprograms, and the like. Researchers have reported being disturt:^, though, on running their code-quality metrics on production-quality pro­grams that had been running for some tinte and endured significant tuning for size and speed; such programs still ex­hibited typographical errors, unused variables, and significant portions of code that could not possibly be executed.

Assistance in the selection of topics and the review of material prior to publication were provided by Jack R. Distaso of TRW Inc.

22 IEEE SPECTRUM AUGUST 1984

back on fhe fast track IBIS puts your computer system on the fast track, if you are building systems that require large-scale data storage and don ' t want to wait for data input /ou tpu t de­lays, IBIS has the answer. Theirs is a new s tandard in disk drive technology. Especially if you are involved with image processing, super-mini systems, or other high performance computer requirements. IBIS gives you 1.4 gigabytes of data storage on a single 14-inch Winchester disk drive. The data transfer rate is 12 megabytes per second with a track-to-track access time of 2.5 milliseconds and an average access time of 16 milliseconds. IBIS gives you the fastest drive in the industry with throughput that pu ts your system on the fast track.

There's ««ΟΓβ to an IBIS disk drive systent than lasge-scale storage and a high-speed transfer rate. Our "designed-in" reliability assures 3/our system's perfomi" ance. IBIS utilizes the latest technology in thin film plated media and advanced air filtration. IBIS disk drives also have self-diagnostics, dynamic error detec­tion, and modular construction that promotes ease of maintenance and service. In fact, with the high reliabil­ity of the IBIS drive, preventive maintenance consists of merely changing the pre-air filter once a year.

To put your computer system on the fast track with a reliable, high-performance disk drive,

contact IBIS Systems, Inc., 5775 Lindero Canyon, Westlake Village, CA 91362. Telephone (818) 706-2505.

Set us ai NCC B! Siggrsph Bootb mi9

Ciret® No. 2