- Email: [email protected]
Program portability in high-energy physics
Computer Physics Communications 9 (1975) 221—229 © North-Holland Publishing Company
PROGRAM PORTABILITY IN HIGH-ENERGY PHYSICS R.K. BOCK CERN, Geneva, Switzerland Received 1 July 1974
This paper discusses the computing problems in high-energy physics and reviews the portability achieved in software in the field. The techniques employed at CERN for developing programs are described and suggestions put forward for the future solution of the problems of portability.
1. lntroduction The short and animated history of high-energy physics is closely linked to the development of cornputers. The first particle detectors producing massive amounts of data came into operation in the late 50s, together with the accelerators built for providing the bombarding particles for this kind of experimentation. Their recordings were on film and ultimately needed computing power for the sheer complexity of the calculation process on each single “event”, which was then precision measured by hand, Ever since, computers have played a decisive role in high-energy physics. Their major applications are for event analysis and for experiment preparation, i.e. of the “number crunching” type. In many cases, the availability of computer capacity confines the amount of data that can be taken and analysed or determines the analysis methods. But computers have even more revolutionised the data recording process. Rather complex arrangements of very fast chambers for particle detection could only be developed during recent years, because their output could be digested readily by on-line computers. And even where the original recordings of traces are still on film, data acquisition computers have taken over most of the measuring tasks from the human and thus boosted the rates of data by an order of magnitude. This article is confined to a review of achieved pottability of application software in this field, hence to problems in which software can usefully be shared by
different installations. Whoever has followed the rapid development of small computer systems will readily conclude for himself tl1at data acquisition problems will be excluded by tius definition. Portability requires a minimum of standardisation and stability, and it introduces inefficiencies. Small computers still are in quest of the first and the economy of data acquisition tolerates little of the second. We will therefore restrict the discussion of portability to application programs run off-line and usually on large computer systems. As an introduction to the computing problems encountered in high energy pl1ysics, this field of research is briefly described in section 2. In section 3, the problems arising from this research environment for application programs are examined in more detail and the existing gaps between computer user demands, computer science literature and practical possibilities are duly deplored. Section 4 presents the essentials of the path which has been followed during recent years in developing programs at the European Organisation for Nuclear Research (CERN). Finally, an outlook is given in section 5 on what might one day usefully substitute those sohutions.
2. High-energy physics and CERN’s role
“a
Portability is an la mode” name for the computer independence of programs. Poole and Waite [11 define it as the measure of the ease with wh1ich a program can be transferred from one environment to
222
R.K. Bi5ck/Program portability in high-energy physics
another. In the same article they define “adaptabihity” as a similar quality concerning the solution of different problems, a synonym for flexibihity. Both portabihity and adaptabihity are of paramount importance to most of the apphication software in hugh-energy physics. The following brief introduction hopefuhhy makes clear why.
2.1. Experiments with accelerators The aim of high-energy physics, also called physics of elementary partiches, is to study interactions between the constituents of the atom when cohhiding-at very high energies. To obtain such energies, protons or ehectrons are accelerated to relativistic speed by accelerators. When fast partiches hit matter, kinetic energy and mass can be converted into each other and new partiches, sometimes of extremely short lifetimes, can be generated. The probabilities of the occurrence of certam reaction classes, the distribution of the participating particles in space and their energy spectrum usually are the interesting parameters in an experiment. They have to be derived painfully from many single observations or measurements of position, speed or momentum in particle detectors.
2.2. International collaboration Accelerators are highly expensive machines and can, even must, serve simultaneously a large community of research teams. They lend themselves ideally to joint organisations which provide the basic facihities and play host to the visiting teams of scientists. In Europe, the European Organisation for Nuclear Research (CERN) has provided accelerators and associated facilities since the late ‘50s. Similar joint organisations exist in the USA and the USSR. Among the secondary apparatus which research teams around accelerators rely on for their experimentation, detectors and computers hold a dominant position. Depending on size, they may again be shared. Typical detectors are chambers using the ionising effects of charged particles in gases or liquids to make their path visible or record it by electric discharges. They may allow very high precision recording by stereophotography as in the bubble chamber, or record
simply the electric pulse in a wire caused by a particle passing nearby. Time constants in these detectors may be up to fractions of a second, if mechanical movements are involved as in fihm cameras or bubble chambers. As the processes to be studied are of quantum medianicah nature, and in most experiments buried in a large background of uninteresting “events”, high statistics is one of the necessary ingredients for high-energy physics experiments. Modern electronic detectors have therefore been pushed to very short “dead times”, and proportional counters can record hundreds of events during the ~ 0.5 sec spilh time of the accelerator, when incident particles are avaihabhe. Needhess 3 to iü~bits to say that, with a data volume of i0 for one event, the limits on the number of events one can take are thien set by the data acquisition and recording possibilities. Frequently also the available computer capacity for subsequent analysis limits the physicists’ ambitions, despite a defined pohicy to use the team’s home computers rather than CERN’s cornputing facilities, whenever possible. The user community for programs developed in this environment is anyth1ing between a few friends in an experiment, and more or less organised worldwide user groups of up to 200 laboratories. The majority of analysis software is, at heast in principle, usable in different contexts and hence should be subject to portability and adaptability constraints. No enforcement of rules, though, is attempted beyond that of common sense. The conventions and rules of program writing, of maintenance, of documentation as described below, are followed by some, but ignored or rejected by others.
2.3. Typical computer tasks in high-energy physics The main elements of high-energy physics have been introduced above: accelerators providing beams of particles, targets which are hit by these particles, detectors which allow to record on film or, in digitised form, on magnetic tape a long or short part of a particle track. What typical load, apart from data acquisition, does this produce for the computer centers available to high-energy physicists? With some simplification, one can see four different categories of computer usage: — Preparation of experiments: simulation of detec-
R.K. Bock/Program portability in high.energy physics
223
tor behaviour, optimisation of chamber positions, simulation of behaviour of critical parts of event ps~-
sionals collaborate very closely with engineers and physicists, and keep in touch with each other across
essing software, understanding of effects observed
the borders of experiments to ensure continuity and
in test runs. Event processing: reconstructing tracks in projections and space from observations, solving assodiation problems of observations, finding space angles and momenta for all tracks, testing various kinematical hypotheses for each interaction. Statistical analysis of events: sorting events into the possible categories or channels, converting their variables into an adequate space, plotting and histogramming these variables, hunting for cross-correlations between physics variables and dependence on parameters describing the detector or data processing methods, comparison of data with theoretical models, Computer center background work: theoretical physics, engineering problems, apparatus development, graphical data presentation, etc. As was said before, not all of this load is taken by CERN, but to a large extent carried by computers available at the home base of the teams working at CERN. Much of the computer analysis, though, is required during the time when these teams work, often under time pressure, at the accelerator. For many experiments, the development of data proc-
to avoid duplication. Their working constraints are numerous: Inasmuch as a vital contribution to the development of application programs comes from visitors to CERN, who will later use them on their home cornputer installation, portability is a dominant concern. Inasmuch as experiments need to get under way and to be analysed quickly, program development time has to be kept in limits. Inasmuch as some of the limits on possible experiment statistics are found in the limits of the available computer time for analysis, efficiency of program execution is important. Inasmuch as the investments in software should be capitalised on by subsequent experiments, the adaptability of the resulting program to various experimental situations is of paramount importance, and inasmuch as a close collaboration is necessary between computer specialists and physicists, language and documentation standards must be carefully selected. These are largely conflicting requirements aggravated by the necessity to live in the existing cornputer world out of the manufacturers’ hands. Frequently, substantially less ambitious solutions have
essing tools and detectors is so closely connected,
to be chosen than the study of computer science lit-
that the above categories are unseparable and that some of the computing load generated during data taking needs to be taken care of on-line. To give an idea of the scale of tie problem, one should mention that more than 200 institutes collaborate with CERN in physics, and a largely overlapping equal number uses CERN software of some kind.
erature seems to suggest possible. What is presented below has an uninspired and conventional look, but still works at the large scale of CERN’s application software. Any attempted solution is a compromise between the requirements and does not attain any of the objectives ideally. The portability of programs is no exception: if programs could be written in a way as to run with no change on any of the major computer systems available, they would surely have to seriously sacrifice economy. Even the possibility of quick program writing might be lost because in the real present day world people express themselves readily in a high level language supported by manufacturers, but not in a new language that might have to be invented for the purpose of portability. It is possible, though, to single out the few areas of computer system peculiarities (which include hardware, configuration and cornpiler differences) and to provide as a program a 100% portable skeleton with well defined holes to be filled in by a computer dependent finishing touch.
—
—
—
3. The high-energy physics software environment The above demands make of CERN a natural collection place of the software used in experimentation, CERN has never attempted, though, to exclusively provide the necessary software (excepting some large projects). Detectors, data acquisition systems, data processing software and physics outcome are very interrelated during development and running. Independent software teams as in commercial or in cornputer systems projects do not find the necessary definition in this environment, Instead, computer profes-
224
R.K. BOck/Program portability in high-energy physics
It can be understood that computer manufacturers have never made a great effort towards portability of software; their objective is to be competitive, not to be compatible. It would be a much less obvious story to explain why computer scientists have for many years retreated to solving the portability problem by a restriction of the definition of “program” to the expression of mathematical algorisms, leaving out of the definition of a language anything that relates language comcepts like “variables” with computer concepts like “memory”. This and the incredible proliferation of languages, often for reasons of personal ambition, forced many users interested more in their problem than in the computers’ to use the tools which they got support for from manufacturers, i.e. mostly systems and languages lagging years behind the academic state of the art.
of secondary importance although not negligible for scientific application. And then there does, of course, exist the history: FORTRAN was the first widely used higher level language, it is known by a large community of users, who never could see the advantages of any of the alternatives sufficiently outweighing the disadvantages to make program conversion and relearning worthwhile. And none of the alternatives ever offered a simple way to capitalise on the investments already made in FORTRAN libraries.
4. Programs in high-energy physics under the angle of portability
puter developments of a (presently) less influential character like the USSR’s BESM6 [12] or the Japa-
4.1.
Language
choice
It was already hinted in the last paragraph, and is an obvious fact, that one of the first steps towards portability is the choice of a proper, i.e. high level language. The high-energy physics community made this choice very early, around 1960, and not so much with the portability problem in mind. Its objective was more to speed up programming and to obtain a valid contribution, if not the dominant part of programs, from the interested parties, i.e., the physicists involved in the research. Needless to say that the choice was FORTRAN, then the only widely usable language with scientific orientation, As it happens, this choice had to be reconfirmed whenever put in question. This happened for some long-lived programs for each major rewrite and for a large processing center like CERN also for each change of computer system. FORTRAN would probably even stand the best chance of being chosen if one had to pick the language now without any of the continuity constraints: it is the most widely imphemented language and sufficiently “direct” i.e., close to the computer to allow expressing nearly any of the high-energy physics problems. Its weaknesses in the area of character or byte handling or in I/O are
4.2. Language definition FORTRAN is today defined in a worldwide accepted standard by the American National Standards Institute: ANSI FORTRAN [2] , formerly called ASA or USAI FORTRAN; it is implemented on all major and medium size computer installations. Even com-
nese FACOM and HITAC series [13] adhere to these standards. Before the ANSI developed the FORTRAN standards into their present form, CERN had made an attempt to define a FORTRAN standard of its own which could be proposed for communicating highenergy physics codes amongst laboratories. This standard was called CERN FORTRAN [3] and defined between several interested laboratories in 1964. It was solely based on common practice principles and the then available compilers, and was absolutely useless to define FORTRAN for the compiler writers. Lack if not impossibility to check code for compliance with the CERN standard made its acceptance largely a matter of discipline, which is to say that it was accepted “in principle”, but even people whose intentions were serious would follow the rules “up to a point” only. The publication and general acceptance of the ANSI standard made such efforts of language definition superfluous. All the same, the ANSI document does not constitute a sufficiently clear definition of certain parts of FORTRAN to ensure portability of code, at least not for programs which have to reach beyond the areas of purely mathematical algorisms and very simple program and data structures. There is no doubt that a compiler writer unaware of day-to-
R.K. BOck/Programportability in high-energy physics day problems and common practice could produce a FORTRAN compiler not in contradiction with the ANSI definition but not serving the portability purpose at all. This is why users, tacitly or in explicit form, resort to add their own ideas about compiler
225
material that has to be digested by a precompiler and converted into FORTRAN. Both extension possibilities are used in CERN’s high-energy physics programs. The following is a summary of existing areas in whichi they are used.
definition in a very unambitious way but with an immensely practical effect. Examples are the PIDGIN FORTRAN in crystallography [4] or the FORTRAN conventions used in the HYDRA of high-energy physics [5] .What is practiced on top of the pure language is in the area of what we call “directness” or the relation between language and hardware: — The meaning of “word” is taken in relation to a variable depending on its type. Arrays may thereby
4.3.1. Machine dependence By defining the programming language in which to communicate with the computer, a base is estabhished which ensures a large degree of portability. However, no such language will allowance to express larger problems in a 100% machine-independent way efficiently. Nor is complete portability worth a major effort. As long as the machine oriented part of a
carry a REAL and an INTEGER name, and, if their
program concerns few sufficiently well defined areas,
origin is equivalenced, the nth element will be so as well. — Calling sequences are assumed to be “by address”,
and their interface with the higher level language can be clearly defined, the adaptation of any program will be a negligible because largely clerical job. Note
to allow for private storage organisation schemes. If
that “machine dependent” is not synonymous with “only expressible in machine language”.
they are not, ad-hoc circumvention becomes necessary. —
The meaning of EQUIVALENCE is taken in
terms of computer memory addresses. —
Words are assumed to be made of bits and bytes
which are individually addressable. In addition a restrictive use of FORTRAN h usually recommended in order to enhance readibihity and efficiency. Both HYDRA [5] and the X-ray system [4] make no or minimal use of TYPE statements, of multi-dimensional arrays, of mixed mode expressions, or of complicated calling sequences preferring to pass data through COMMON store.
In the case of high-energy physics codes, the inter-
face from FORTRAN written parts to machine dependent parts is, naturally, by SUBROUTINE or
FUNCTION calls, and concerns the following: Insertion or extraction of single bits or groups —
implemented (or even discussed) ones, there will be
of bits into or from computer words. (Application: packing of information that is frequently repeated and infrequently looked at. Restriction for the FORTRAN code: never use more bits than the minimum word size for which the program still has to run; normally used: 32 bits.) — Interrogation of the computer system for resources like “time” or “memory”. Frills, perhaps, but in a production environment a very useful convenience, and in some form available on all systems. — Handling of characters. This is largely a lack of the FORTRAN language, which is not very efficient-
areas in which the choice will turn out inadequate.
ly overcome by an interface relating words and char-
When talking about programs or program parts made accessible to many users there will therefore have to be extensions to that language. “Language extension” may be a pompous name for additional rules, as long as a language does not contain as part of its own definition the possibility of adding new syntactic ele-
acters, in a similar way to the word-to-bit relation. However, characters existing as part of contiguous information blocks that are to be handled in a simple way, remain an unsolved problem even if the TYPE CHARACTER statement existed in the language. In High Energy Physics the problem is minimised by
ments. The only interface offered by FORTRAN for extensions is that of the SUBROUTINE or FIJNC-
using character information only in very few limited contexts.
4.3. Language extensions
Whatever language one chooses from the presently
TION. “Extensions” then can only be thought of
either as SUBROUTINE libraries or as non-FORTRAN
—
Handling of program transfer addresses. This
cannot be considered a necessity, but is brought about
226
R.K. BOck/Program portability in high-energy physics
by using extended concepts like reentrant program modules and trap-returns, which do help enormously to obtain modularity in large programs. Not intended to be seen by the user, subroutines for ad-
[5,6] They concern mostly the problems of very large application programs, but have been found to be useful also in more modest environments. The supporting software can be considered as an “em-
dress handling and the simulation of proper callreturn information are not only machine-, but even
bedded language” like SLIP [l0} ,i.e., it is made of groups of library subroutines. HYDRA concepts in-
system-dependent. There is no doubt that such concepts should rather be part of a language, but can be introduced efficiently only if they are used with a
elude data blocking and structuring (in store and externally), dynamic memory management, program
proper understanding of the implications of reentrance, recursion, trapping. — Input—output. Seemingly a proper and perfect-
ly portable part of FORTRAN, we have not succeeded in providing generally accepted input—output state-
-
structuring into reentrant modules, and trap returns to higher level programs. Some analysis programs have been developed rather far in the direction of using a control card
tion or printing. Bulk data transmission and external
“language” which is interpreted by FORTRAN programs. Not elaborated to the syntactic complication of ICES [11] ,the “statements” of this language do, however, entirely determine the behaviour of the
storage formats constitute in many cases one of the
program. A wide-spread program of this kind is
major bottlenecks of a data processing program. They are consequently adapted not only to computer sys-
SUMX [7] ,which provides a wide variety of statistical analysis tools for data files in environments that
tems and configurations, but equally often to the data characteristics of a given application. The best compromise found so far consists in defining program
may be far from that of high-energy physics. We should perhaps not generalize this conclusion, but there seems to be indication that such programs are
interfaces in terms of internal storage only, and to concentrate all input—output operations into few routines, usually in (system dependent) FORTRAN.
being used less by casual users, who shy away from learning the program’s “language”. More frequent users, instead, commonly request the provision of hooks giving practical access to all the guts of the program, i.e. they want freedom to program, in
ments for more than trivialities like control informa-
4.3.2. Application dependent libraries The use of subroutine libraries as a tool supple-
FORTRAN, various extensions or shortcuts to the
menting the language is well known and adds nothing to the portability problem. Frequent use of standard
available “language”.
procedures even of the most trivial kind presents the advantage of readibiity if not compactness of programs and offers the possibility of run-time optimisa-
4.3.4. Program maintenance Unlike hardware components, pieces of program do not suffer much from physical wear and the mean-
tion by hand-coding of critical and extremely well-defined parts of programs. Areas which are widely
ing of “maintenance” for software is in reality that of adaptation and evolution. In our environment, on-
covered by such library routines at CERN are: array handling, matrix and vector operations, table lookup, interpolation, histogramming and plotting,
ly an arbitrary line can be drawn between “development” and “evolution”, and a major effort has been made to allow for developments and improvements in all directions without giving up stability. The modularity concepts of HYDRA go far in this direction
4.3.3. Application dependent concepts and support software
FORTRAN covers certain problem areas and provides, by the notion of SUBROUTINE and of shared storage (COMMON), means of organising programs into modules. We have found it necessary, to provide some guidelines in the structuring both of programs and data at a higher level. These concepts are known under the name HYDRA and have been described before
by guiding contributors to submit suitable program modules representing major developments. For maintaining source material on a lower level,
though, an editing program PATCHY [7] has been in use which allows multi-level replacement of material at the level of single FORTRAN statements, and the selection of versions according to control cards. PATCHY also contains options specifically introduced
R.K. BOck/Program portability in high-energy physics
for the hard core of statements which cannot be made machine-independent but which cannot conveniently be grouped into routines, Such statements may firstly appear in different parallel forms inside a program, each form with a defined tag in a field treated as comment by the compiler (card columns 73—80) and defining a configuration, a word size, etc. Properly instructed, PATCHY will select one of these statements, passing the alternatives on as comment fields. Secondly, machinedependent code may be introduced as a “sequence”, i.e. a group of statements invoked by an identifying name and previously defined to PATCHY by selecting one of the foreseen possibilities. The same “sequence” option is used to define centrally the sometimes tedious COMMON, DIMENSION and EQUIVALENCE statements shared by many routines. PATCHY itself was originally meant to remain a program for use at CERN only, but has turned into a generally used editing program preceding compilation on many systems using CERN programs. Its program maintenance features even seem to survive happily the advent of reliable interactive editing systems. The portability problem for an efficient PATCHY has been one of the recurring concerns for the people involved. 4.3.4. Documentation
CERN as a collection place and main contributor for application software to be distributed to a widespread user community has a special responsibility to provide documentation together with programs. Contrary to computer systems software or large “blackbox” programs of any other kind, the permanent evolution of programs makes a detailed written doeumentation impossible. The fact that programs or program modules come from a wide variety of authors at best loosely coordinated, makes documentation rules unenforcable. There is, however, a minimum of written documentation for any distributable program unit (subroutines, HYDRA processors [5] or complete programs). This minimum is given by: a) the data interface on input, b) the internal functioning of the program, ,
c) the data interface on output,
d) the user interface.
227
Subroutines have their data interfaces defined by the calling sequence, HYDRA processors in terms of data structures, complete programs as data on external storage media like card, tape or disk files and printer files. A user interface may be defined when a user may or must supply additional code to interfere with the functioning of a program, or when control cards are read to steer the program logic. Detailed documentation is usually expected to be part of the program itself in form of comments in the code; this alleviates the updating task and provides an easy way to produce computer dependent documentation in the case of alternative coding.
5. A dream of a future FORTRAN substitute
Assume for a moment, a user community like that of high-energy physics were to act in common and with benevolent support both from computer science and computer manufacturers. Assume also, as papers in computer science journals usually do, that the questions of implementation, documentation, (re-)education of users all are negligible. What tools might users define so that their programming problems, in particular that of portability, could be solved better than by the means described above? No doubt, the answer to this question will consist mostly of stating desirable language characteristics, in particular language extension possibilities. Any language to be accepted in place of FORTRAN will have to present a solution for the investments already made in libraries, and it will have to be an overall order of magnitude better in the areas below, without being worse than FORTRAN in any single one of them. 5.1. Efficiency
Average FORTRAN programs with a minimum of machine language constituents execute in about 10 to 20% more time than competently written machine language programs. FORTRAN compilers are of tolerable size and on most machines compilation time is reasonable which is surprising given the necessity —
of context identification for key words.
228
R.K. BOck/Program portability in high-energy physics
5.2. Simplicity The accumulation of “facilities” as is done in PL/l is probably the very opposite of what a language should provide in order to be the vehicle for portable pro-
grams. The aim should rather be a universal l1ost language at a basic level. This should niake compiler
mentation, bring a relevant improvement over FORTRAN, which does not prevent but cannot enforce this way of expressing problems. 5.5. Extensibility
5.3. Rigour and directness
As has been shown for the environment of highenergy physics, large user groups develop a certain number of concepts and related procedures winch constitute, in that problem area, a “language” of higher level, In FORTRAN the embedding of such
FORTRAN is reasonably well defined in the ANSI document, but its success is based not only on that definition, but on common practice. Compilers could be (and have been) written which obey the letter but not the spirit of the FORTRAN definition, and which make serious overhauls of programs necessary when
“languages” is possible only by external linkage. The supported program explicitly uses code details which are defined in correspondence with a back-up library of “primitives”. High-level languages later than FORTRAN attempt to anticipate such additional concepts, generalise them and offer them as part of the language, like PL/l and PASCAL. Tins makes
writing easy and hence an introduction of the lan-
guage attractive even on resource-limited systems.
going to a new computer. The major reason for this incompleteness of definition is the desire to slueld language definitions, ironically under the heading portability, from conputer components. A famous example is the “call by value” versus “call by address” argument. It is our considered opinion, that many computer users would
them more useful for some applications, at the ex-
have a lot to gain from introducing “directness” into the language. In other words, the most common no-
e.g. the usage of additional keyword “libraries” which define sequences of instructions of the basic
tions of computer hardware should be used in the definition of the language. Only in writing very simple and casual programs may one get away with using
language, that can be invoked by new keywords. Extensions of the basic constituents of the language and hence of the compiler code as proposed
computers without learning the concepts of “word”,
by Newey [8] are certainly superior; but they en-
“address”, “memory” or “random access”; the rela-
tail the danger of proliferation of compiler versions,
tion of these concepts with those of the language, like “variable”, “static storage”, “external identifier”
unless such extensions come in a rigorously packaged form.
determines the way in which programs are written, and many of the latter are meaningless without the first.
5.6. Handiness
5.4. Readability Post-FORTRAN high-level languages have developed special ways of expressing branching and looping instructions, and for decomposing local problems
into procedures. Those constructs educate the programmer in writing clear and easy-to-read algorithms. None of these beauties of structural programming are in contradiction with directness, and they would certainly, in the sense of readibiity and easier docu-
pense of simplicity and efficiency for all others.
Much harm can been done by attempting such global solutions. A much more acceptable approach might be to define the basic language only such that all basic problems can be expressed, and to permit growth of the language inside the language’s rules;
Under the headings “aesthetics” or ‘‘correctness checking” much ink has been spent already to defend verbosity of code, complete declaration lists — or the contrary. In all this there is rarely a reference to the fact that the prime number finder of a student, and a piece of code for nuclear reactor calculations written by a computer physicist might not have the same de-
mands on the language. Clearly the conciseness of instructions with no superfluous redundancy in many circumstances reduces human errors, whereas in a different context the 100% complete problem definitior
R.K. BOck/Program portability in high-energy physics
229
may have the same effect. A language using a minimum of typed characters, hence default definitions and ad-hoc conventions,
[31 CERN 6600 Comp.19.11.1964. Document.: CERN FORTRAN, Internal Document,
sounds attractive to many users. Not accidentally
[41J.M.
“pre-compilers” have already been used to attain this goal, like the Language Independent Macro Processor of Waite [9] which has been used to allow a shorthand ALGOL. There is no reason, though, to impose
programming shorthand on everyone. For instance, language keywords might be defined to start with a “keyword character”, be recognised by their first
three characters only, and terminated by a blank or other terminator, leaving as much room as desired to verbosity: DEC, DECLARE or DECLARATION then
all have the same meaning, and nobody is punished even when typing DECLARTAION.
References [11 P.C.Poole and W.M. Waite, Lect. Notes in Economics and Mathem. Systems 81(1973)183.
[21 USA Standard FORTRAN USAS X3.9 — 1966, USA Standards Inst. (now ANSI). Stewart et al., Techn. Rep. TR-192, Univ. Mary-
land, Comp. Sc. Centre (June 1972). 151 HYDRA System Manual, CERN, TC Division, Internal Document; Initiation to HYDRA; CERN/DPhII/Prog 74—4, Internal Report. 161 R.K. BOck, E. Pagiola and J. Zoll, Computer Phys. Commun. 5 (1973) 400. [71 CERN Computer Library, PATCHY, Long Write-up (L400). Internal Document; CERN Library, SUMX Long Write-up (Y200). InternalComputer Document. 181 M.C. Newey, AFIPS Proc., FJJC 33 (1968) 1339. [91 W.M. Waite, Comm. ACM 10 (1967) 433. [101 J. Weizenbaum, Comm. ACM 6 (1963) 524. [11] D. Roos, AFIPS Proc. FJCC 27 (1965) 151. 1121 W.P. Schirikow, JINR Dubna, Preprint 10-4242 (1968); and BESM-FORTRAN, Zentrum für Rechentechnik der Akademie der Wissenschaften, Zeuthen 1969. [131 S. Moriguti et al., in: First USA—Japan Comp. Conf. Proc. AFIPS and IPSJ, October 1972, Tokyo.
PROGRAM PORTABILITY IN HIGH-ENERGY PHYSICS R.K. BOCK CERN, Geneva, Switzerland Received 1 July 1974
This paper discusses the computing problems in high-energy physics and reviews the portability achieved in software in the field. The techniques employed at CERN for developing programs are described and suggestions put forward for the future solution of the problems of portability.
1. lntroduction The short and animated history of high-energy physics is closely linked to the development of cornputers. The first particle detectors producing massive amounts of data came into operation in the late 50s, together with the accelerators built for providing the bombarding particles for this kind of experimentation. Their recordings were on film and ultimately needed computing power for the sheer complexity of the calculation process on each single “event”, which was then precision measured by hand, Ever since, computers have played a decisive role in high-energy physics. Their major applications are for event analysis and for experiment preparation, i.e. of the “number crunching” type. In many cases, the availability of computer capacity confines the amount of data that can be taken and analysed or determines the analysis methods. But computers have even more revolutionised the data recording process. Rather complex arrangements of very fast chambers for particle detection could only be developed during recent years, because their output could be digested readily by on-line computers. And even where the original recordings of traces are still on film, data acquisition computers have taken over most of the measuring tasks from the human and thus boosted the rates of data by an order of magnitude. This article is confined to a review of achieved pottability of application software in this field, hence to problems in which software can usefully be shared by
different installations. Whoever has followed the rapid development of small computer systems will readily conclude for himself tl1at data acquisition problems will be excluded by tius definition. Portability requires a minimum of standardisation and stability, and it introduces inefficiencies. Small computers still are in quest of the first and the economy of data acquisition tolerates little of the second. We will therefore restrict the discussion of portability to application programs run off-line and usually on large computer systems. As an introduction to the computing problems encountered in high energy pl1ysics, this field of research is briefly described in section 2. In section 3, the problems arising from this research environment for application programs are examined in more detail and the existing gaps between computer user demands, computer science literature and practical possibilities are duly deplored. Section 4 presents the essentials of the path which has been followed during recent years in developing programs at the European Organisation for Nuclear Research (CERN). Finally, an outlook is given in section 5 on what might one day usefully substitute those sohutions.
2. High-energy physics and CERN’s role
“a
Portability is an la mode” name for the computer independence of programs. Poole and Waite [11 define it as the measure of the ease with wh1ich a program can be transferred from one environment to
222
R.K. Bi5ck/Program portability in high-energy physics
another. In the same article they define “adaptabihity” as a similar quality concerning the solution of different problems, a synonym for flexibihity. Both portabihity and adaptabihity are of paramount importance to most of the apphication software in hugh-energy physics. The following brief introduction hopefuhhy makes clear why.
2.1. Experiments with accelerators The aim of high-energy physics, also called physics of elementary partiches, is to study interactions between the constituents of the atom when cohhiding-at very high energies. To obtain such energies, protons or ehectrons are accelerated to relativistic speed by accelerators. When fast partiches hit matter, kinetic energy and mass can be converted into each other and new partiches, sometimes of extremely short lifetimes, can be generated. The probabilities of the occurrence of certam reaction classes, the distribution of the participating particles in space and their energy spectrum usually are the interesting parameters in an experiment. They have to be derived painfully from many single observations or measurements of position, speed or momentum in particle detectors.
2.2. International collaboration Accelerators are highly expensive machines and can, even must, serve simultaneously a large community of research teams. They lend themselves ideally to joint organisations which provide the basic facihities and play host to the visiting teams of scientists. In Europe, the European Organisation for Nuclear Research (CERN) has provided accelerators and associated facilities since the late ‘50s. Similar joint organisations exist in the USA and the USSR. Among the secondary apparatus which research teams around accelerators rely on for their experimentation, detectors and computers hold a dominant position. Depending on size, they may again be shared. Typical detectors are chambers using the ionising effects of charged particles in gases or liquids to make their path visible or record it by electric discharges. They may allow very high precision recording by stereophotography as in the bubble chamber, or record
simply the electric pulse in a wire caused by a particle passing nearby. Time constants in these detectors may be up to fractions of a second, if mechanical movements are involved as in fihm cameras or bubble chambers. As the processes to be studied are of quantum medianicah nature, and in most experiments buried in a large background of uninteresting “events”, high statistics is one of the necessary ingredients for high-energy physics experiments. Modern electronic detectors have therefore been pushed to very short “dead times”, and proportional counters can record hundreds of events during the ~ 0.5 sec spilh time of the accelerator, when incident particles are avaihabhe. Needhess 3 to iü~bits to say that, with a data volume of i0 for one event, the limits on the number of events one can take are thien set by the data acquisition and recording possibilities. Frequently also the available computer capacity for subsequent analysis limits the physicists’ ambitions, despite a defined pohicy to use the team’s home computers rather than CERN’s cornputing facilities, whenever possible. The user community for programs developed in this environment is anyth1ing between a few friends in an experiment, and more or less organised worldwide user groups of up to 200 laboratories. The majority of analysis software is, at heast in principle, usable in different contexts and hence should be subject to portability and adaptability constraints. No enforcement of rules, though, is attempted beyond that of common sense. The conventions and rules of program writing, of maintenance, of documentation as described below, are followed by some, but ignored or rejected by others.
2.3. Typical computer tasks in high-energy physics The main elements of high-energy physics have been introduced above: accelerators providing beams of particles, targets which are hit by these particles, detectors which allow to record on film or, in digitised form, on magnetic tape a long or short part of a particle track. What typical load, apart from data acquisition, does this produce for the computer centers available to high-energy physicists? With some simplification, one can see four different categories of computer usage: — Preparation of experiments: simulation of detec-
R.K. Bock/Program portability in high.energy physics
223
tor behaviour, optimisation of chamber positions, simulation of behaviour of critical parts of event ps~-
sionals collaborate very closely with engineers and physicists, and keep in touch with each other across
essing software, understanding of effects observed
the borders of experiments to ensure continuity and
in test runs. Event processing: reconstructing tracks in projections and space from observations, solving assodiation problems of observations, finding space angles and momenta for all tracks, testing various kinematical hypotheses for each interaction. Statistical analysis of events: sorting events into the possible categories or channels, converting their variables into an adequate space, plotting and histogramming these variables, hunting for cross-correlations between physics variables and dependence on parameters describing the detector or data processing methods, comparison of data with theoretical models, Computer center background work: theoretical physics, engineering problems, apparatus development, graphical data presentation, etc. As was said before, not all of this load is taken by CERN, but to a large extent carried by computers available at the home base of the teams working at CERN. Much of the computer analysis, though, is required during the time when these teams work, often under time pressure, at the accelerator. For many experiments, the development of data proc-
to avoid duplication. Their working constraints are numerous: Inasmuch as a vital contribution to the development of application programs comes from visitors to CERN, who will later use them on their home cornputer installation, portability is a dominant concern. Inasmuch as experiments need to get under way and to be analysed quickly, program development time has to be kept in limits. Inasmuch as some of the limits on possible experiment statistics are found in the limits of the available computer time for analysis, efficiency of program execution is important. Inasmuch as the investments in software should be capitalised on by subsequent experiments, the adaptability of the resulting program to various experimental situations is of paramount importance, and inasmuch as a close collaboration is necessary between computer specialists and physicists, language and documentation standards must be carefully selected. These are largely conflicting requirements aggravated by the necessity to live in the existing cornputer world out of the manufacturers’ hands. Frequently, substantially less ambitious solutions have
essing tools and detectors is so closely connected,
to be chosen than the study of computer science lit-
that the above categories are unseparable and that some of the computing load generated during data taking needs to be taken care of on-line. To give an idea of the scale of tie problem, one should mention that more than 200 institutes collaborate with CERN in physics, and a largely overlapping equal number uses CERN software of some kind.
erature seems to suggest possible. What is presented below has an uninspired and conventional look, but still works at the large scale of CERN’s application software. Any attempted solution is a compromise between the requirements and does not attain any of the objectives ideally. The portability of programs is no exception: if programs could be written in a way as to run with no change on any of the major computer systems available, they would surely have to seriously sacrifice economy. Even the possibility of quick program writing might be lost because in the real present day world people express themselves readily in a high level language supported by manufacturers, but not in a new language that might have to be invented for the purpose of portability. It is possible, though, to single out the few areas of computer system peculiarities (which include hardware, configuration and cornpiler differences) and to provide as a program a 100% portable skeleton with well defined holes to be filled in by a computer dependent finishing touch.
—
—
—
3. The high-energy physics software environment The above demands make of CERN a natural collection place of the software used in experimentation, CERN has never attempted, though, to exclusively provide the necessary software (excepting some large projects). Detectors, data acquisition systems, data processing software and physics outcome are very interrelated during development and running. Independent software teams as in commercial or in cornputer systems projects do not find the necessary definition in this environment, Instead, computer profes-
224
R.K. BOck/Program portability in high-energy physics
It can be understood that computer manufacturers have never made a great effort towards portability of software; their objective is to be competitive, not to be compatible. It would be a much less obvious story to explain why computer scientists have for many years retreated to solving the portability problem by a restriction of the definition of “program” to the expression of mathematical algorisms, leaving out of the definition of a language anything that relates language comcepts like “variables” with computer concepts like “memory”. This and the incredible proliferation of languages, often for reasons of personal ambition, forced many users interested more in their problem than in the computers’ to use the tools which they got support for from manufacturers, i.e. mostly systems and languages lagging years behind the academic state of the art.
of secondary importance although not negligible for scientific application. And then there does, of course, exist the history: FORTRAN was the first widely used higher level language, it is known by a large community of users, who never could see the advantages of any of the alternatives sufficiently outweighing the disadvantages to make program conversion and relearning worthwhile. And none of the alternatives ever offered a simple way to capitalise on the investments already made in FORTRAN libraries.
4. Programs in high-energy physics under the angle of portability
puter developments of a (presently) less influential character like the USSR’s BESM6 [12] or the Japa-
4.1.
Language
choice
It was already hinted in the last paragraph, and is an obvious fact, that one of the first steps towards portability is the choice of a proper, i.e. high level language. The high-energy physics community made this choice very early, around 1960, and not so much with the portability problem in mind. Its objective was more to speed up programming and to obtain a valid contribution, if not the dominant part of programs, from the interested parties, i.e., the physicists involved in the research. Needless to say that the choice was FORTRAN, then the only widely usable language with scientific orientation, As it happens, this choice had to be reconfirmed whenever put in question. This happened for some long-lived programs for each major rewrite and for a large processing center like CERN also for each change of computer system. FORTRAN would probably even stand the best chance of being chosen if one had to pick the language now without any of the continuity constraints: it is the most widely imphemented language and sufficiently “direct” i.e., close to the computer to allow expressing nearly any of the high-energy physics problems. Its weaknesses in the area of character or byte handling or in I/O are
4.2. Language definition FORTRAN is today defined in a worldwide accepted standard by the American National Standards Institute: ANSI FORTRAN [2] , formerly called ASA or USAI FORTRAN; it is implemented on all major and medium size computer installations. Even com-
nese FACOM and HITAC series [13] adhere to these standards. Before the ANSI developed the FORTRAN standards into their present form, CERN had made an attempt to define a FORTRAN standard of its own which could be proposed for communicating highenergy physics codes amongst laboratories. This standard was called CERN FORTRAN [3] and defined between several interested laboratories in 1964. It was solely based on common practice principles and the then available compilers, and was absolutely useless to define FORTRAN for the compiler writers. Lack if not impossibility to check code for compliance with the CERN standard made its acceptance largely a matter of discipline, which is to say that it was accepted “in principle”, but even people whose intentions were serious would follow the rules “up to a point” only. The publication and general acceptance of the ANSI standard made such efforts of language definition superfluous. All the same, the ANSI document does not constitute a sufficiently clear definition of certain parts of FORTRAN to ensure portability of code, at least not for programs which have to reach beyond the areas of purely mathematical algorisms and very simple program and data structures. There is no doubt that a compiler writer unaware of day-to-
R.K. BOck/Programportability in high-energy physics day problems and common practice could produce a FORTRAN compiler not in contradiction with the ANSI definition but not serving the portability purpose at all. This is why users, tacitly or in explicit form, resort to add their own ideas about compiler
225
material that has to be digested by a precompiler and converted into FORTRAN. Both extension possibilities are used in CERN’s high-energy physics programs. The following is a summary of existing areas in whichi they are used.
definition in a very unambitious way but with an immensely practical effect. Examples are the PIDGIN FORTRAN in crystallography [4] or the FORTRAN conventions used in the HYDRA of high-energy physics [5] .What is practiced on top of the pure language is in the area of what we call “directness” or the relation between language and hardware: — The meaning of “word” is taken in relation to a variable depending on its type. Arrays may thereby
4.3.1. Machine dependence By defining the programming language in which to communicate with the computer, a base is estabhished which ensures a large degree of portability. However, no such language will allowance to express larger problems in a 100% machine-independent way efficiently. Nor is complete portability worth a major effort. As long as the machine oriented part of a
carry a REAL and an INTEGER name, and, if their
program concerns few sufficiently well defined areas,
origin is equivalenced, the nth element will be so as well. — Calling sequences are assumed to be “by address”,
and their interface with the higher level language can be clearly defined, the adaptation of any program will be a negligible because largely clerical job. Note
to allow for private storage organisation schemes. If
that “machine dependent” is not synonymous with “only expressible in machine language”.
they are not, ad-hoc circumvention becomes necessary. —
The meaning of EQUIVALENCE is taken in
terms of computer memory addresses. —
Words are assumed to be made of bits and bytes
which are individually addressable. In addition a restrictive use of FORTRAN h usually recommended in order to enhance readibihity and efficiency. Both HYDRA [5] and the X-ray system [4] make no or minimal use of TYPE statements, of multi-dimensional arrays, of mixed mode expressions, or of complicated calling sequences preferring to pass data through COMMON store.
In the case of high-energy physics codes, the inter-
face from FORTRAN written parts to machine dependent parts is, naturally, by SUBROUTINE or
FUNCTION calls, and concerns the following: Insertion or extraction of single bits or groups —
implemented (or even discussed) ones, there will be
of bits into or from computer words. (Application: packing of information that is frequently repeated and infrequently looked at. Restriction for the FORTRAN code: never use more bits than the minimum word size for which the program still has to run; normally used: 32 bits.) — Interrogation of the computer system for resources like “time” or “memory”. Frills, perhaps, but in a production environment a very useful convenience, and in some form available on all systems. — Handling of characters. This is largely a lack of the FORTRAN language, which is not very efficient-
areas in which the choice will turn out inadequate.
ly overcome by an interface relating words and char-
When talking about programs or program parts made accessible to many users there will therefore have to be extensions to that language. “Language extension” may be a pompous name for additional rules, as long as a language does not contain as part of its own definition the possibility of adding new syntactic ele-
acters, in a similar way to the word-to-bit relation. However, characters existing as part of contiguous information blocks that are to be handled in a simple way, remain an unsolved problem even if the TYPE CHARACTER statement existed in the language. In High Energy Physics the problem is minimised by
ments. The only interface offered by FORTRAN for extensions is that of the SUBROUTINE or FIJNC-
using character information only in very few limited contexts.
4.3. Language extensions
Whatever language one chooses from the presently
TION. “Extensions” then can only be thought of
either as SUBROUTINE libraries or as non-FORTRAN
—
Handling of program transfer addresses. This
cannot be considered a necessity, but is brought about
226
R.K. BOck/Program portability in high-energy physics
by using extended concepts like reentrant program modules and trap-returns, which do help enormously to obtain modularity in large programs. Not intended to be seen by the user, subroutines for ad-
[5,6] They concern mostly the problems of very large application programs, but have been found to be useful also in more modest environments. The supporting software can be considered as an “em-
dress handling and the simulation of proper callreturn information are not only machine-, but even
bedded language” like SLIP [l0} ,i.e., it is made of groups of library subroutines. HYDRA concepts in-
system-dependent. There is no doubt that such concepts should rather be part of a language, but can be introduced efficiently only if they are used with a
elude data blocking and structuring (in store and externally), dynamic memory management, program
proper understanding of the implications of reentrance, recursion, trapping. — Input—output. Seemingly a proper and perfect-
ly portable part of FORTRAN, we have not succeeded in providing generally accepted input—output state-
-
structuring into reentrant modules, and trap returns to higher level programs. Some analysis programs have been developed rather far in the direction of using a control card
tion or printing. Bulk data transmission and external
“language” which is interpreted by FORTRAN programs. Not elaborated to the syntactic complication of ICES [11] ,the “statements” of this language do, however, entirely determine the behaviour of the
storage formats constitute in many cases one of the
program. A wide-spread program of this kind is
major bottlenecks of a data processing program. They are consequently adapted not only to computer sys-
SUMX [7] ,which provides a wide variety of statistical analysis tools for data files in environments that
tems and configurations, but equally often to the data characteristics of a given application. The best compromise found so far consists in defining program
may be far from that of high-energy physics. We should perhaps not generalize this conclusion, but there seems to be indication that such programs are
interfaces in terms of internal storage only, and to concentrate all input—output operations into few routines, usually in (system dependent) FORTRAN.
being used less by casual users, who shy away from learning the program’s “language”. More frequent users, instead, commonly request the provision of hooks giving practical access to all the guts of the program, i.e. they want freedom to program, in
ments for more than trivialities like control informa-
4.3.2. Application dependent libraries The use of subroutine libraries as a tool supple-
FORTRAN, various extensions or shortcuts to the
menting the language is well known and adds nothing to the portability problem. Frequent use of standard
available “language”.
procedures even of the most trivial kind presents the advantage of readibiity if not compactness of programs and offers the possibility of run-time optimisa-
4.3.4. Program maintenance Unlike hardware components, pieces of program do not suffer much from physical wear and the mean-
tion by hand-coding of critical and extremely well-defined parts of programs. Areas which are widely
ing of “maintenance” for software is in reality that of adaptation and evolution. In our environment, on-
covered by such library routines at CERN are: array handling, matrix and vector operations, table lookup, interpolation, histogramming and plotting,
ly an arbitrary line can be drawn between “development” and “evolution”, and a major effort has been made to allow for developments and improvements in all directions without giving up stability. The modularity concepts of HYDRA go far in this direction
4.3.3. Application dependent concepts and support software
FORTRAN covers certain problem areas and provides, by the notion of SUBROUTINE and of shared storage (COMMON), means of organising programs into modules. We have found it necessary, to provide some guidelines in the structuring both of programs and data at a higher level. These concepts are known under the name HYDRA and have been described before
by guiding contributors to submit suitable program modules representing major developments. For maintaining source material on a lower level,
though, an editing program PATCHY [7] has been in use which allows multi-level replacement of material at the level of single FORTRAN statements, and the selection of versions according to control cards. PATCHY also contains options specifically introduced
R.K. BOck/Program portability in high-energy physics
for the hard core of statements which cannot be made machine-independent but which cannot conveniently be grouped into routines, Such statements may firstly appear in different parallel forms inside a program, each form with a defined tag in a field treated as comment by the compiler (card columns 73—80) and defining a configuration, a word size, etc. Properly instructed, PATCHY will select one of these statements, passing the alternatives on as comment fields. Secondly, machinedependent code may be introduced as a “sequence”, i.e. a group of statements invoked by an identifying name and previously defined to PATCHY by selecting one of the foreseen possibilities. The same “sequence” option is used to define centrally the sometimes tedious COMMON, DIMENSION and EQUIVALENCE statements shared by many routines. PATCHY itself was originally meant to remain a program for use at CERN only, but has turned into a generally used editing program preceding compilation on many systems using CERN programs. Its program maintenance features even seem to survive happily the advent of reliable interactive editing systems. The portability problem for an efficient PATCHY has been one of the recurring concerns for the people involved. 4.3.4. Documentation
CERN as a collection place and main contributor for application software to be distributed to a widespread user community has a special responsibility to provide documentation together with programs. Contrary to computer systems software or large “blackbox” programs of any other kind, the permanent evolution of programs makes a detailed written doeumentation impossible. The fact that programs or program modules come from a wide variety of authors at best loosely coordinated, makes documentation rules unenforcable. There is, however, a minimum of written documentation for any distributable program unit (subroutines, HYDRA processors [5] or complete programs). This minimum is given by: a) the data interface on input, b) the internal functioning of the program, ,
c) the data interface on output,
d) the user interface.
227
Subroutines have their data interfaces defined by the calling sequence, HYDRA processors in terms of data structures, complete programs as data on external storage media like card, tape or disk files and printer files. A user interface may be defined when a user may or must supply additional code to interfere with the functioning of a program, or when control cards are read to steer the program logic. Detailed documentation is usually expected to be part of the program itself in form of comments in the code; this alleviates the updating task and provides an easy way to produce computer dependent documentation in the case of alternative coding.
5. A dream of a future FORTRAN substitute
Assume for a moment, a user community like that of high-energy physics were to act in common and with benevolent support both from computer science and computer manufacturers. Assume also, as papers in computer science journals usually do, that the questions of implementation, documentation, (re-)education of users all are negligible. What tools might users define so that their programming problems, in particular that of portability, could be solved better than by the means described above? No doubt, the answer to this question will consist mostly of stating desirable language characteristics, in particular language extension possibilities. Any language to be accepted in place of FORTRAN will have to present a solution for the investments already made in libraries, and it will have to be an overall order of magnitude better in the areas below, without being worse than FORTRAN in any single one of them. 5.1. Efficiency
Average FORTRAN programs with a minimum of machine language constituents execute in about 10 to 20% more time than competently written machine language programs. FORTRAN compilers are of tolerable size and on most machines compilation time is reasonable which is surprising given the necessity —
of context identification for key words.
228
R.K. BOck/Program portability in high-energy physics
5.2. Simplicity The accumulation of “facilities” as is done in PL/l is probably the very opposite of what a language should provide in order to be the vehicle for portable pro-
grams. The aim should rather be a universal l1ost language at a basic level. This should niake compiler
mentation, bring a relevant improvement over FORTRAN, which does not prevent but cannot enforce this way of expressing problems. 5.5. Extensibility
5.3. Rigour and directness
As has been shown for the environment of highenergy physics, large user groups develop a certain number of concepts and related procedures winch constitute, in that problem area, a “language” of higher level, In FORTRAN the embedding of such
FORTRAN is reasonably well defined in the ANSI document, but its success is based not only on that definition, but on common practice. Compilers could be (and have been) written which obey the letter but not the spirit of the FORTRAN definition, and which make serious overhauls of programs necessary when
“languages” is possible only by external linkage. The supported program explicitly uses code details which are defined in correspondence with a back-up library of “primitives”. High-level languages later than FORTRAN attempt to anticipate such additional concepts, generalise them and offer them as part of the language, like PL/l and PASCAL. Tins makes
writing easy and hence an introduction of the lan-
guage attractive even on resource-limited systems.
going to a new computer. The major reason for this incompleteness of definition is the desire to slueld language definitions, ironically under the heading portability, from conputer components. A famous example is the “call by value” versus “call by address” argument. It is our considered opinion, that many computer users would
them more useful for some applications, at the ex-
have a lot to gain from introducing “directness” into the language. In other words, the most common no-
e.g. the usage of additional keyword “libraries” which define sequences of instructions of the basic
tions of computer hardware should be used in the definition of the language. Only in writing very simple and casual programs may one get away with using
language, that can be invoked by new keywords. Extensions of the basic constituents of the language and hence of the compiler code as proposed
computers without learning the concepts of “word”,
by Newey [8] are certainly superior; but they en-
“address”, “memory” or “random access”; the rela-
tail the danger of proliferation of compiler versions,
tion of these concepts with those of the language, like “variable”, “static storage”, “external identifier”
unless such extensions come in a rigorously packaged form.
determines the way in which programs are written, and many of the latter are meaningless without the first.
5.6. Handiness
5.4. Readability Post-FORTRAN high-level languages have developed special ways of expressing branching and looping instructions, and for decomposing local problems
into procedures. Those constructs educate the programmer in writing clear and easy-to-read algorithms. None of these beauties of structural programming are in contradiction with directness, and they would certainly, in the sense of readibiity and easier docu-
pense of simplicity and efficiency for all others.
Much harm can been done by attempting such global solutions. A much more acceptable approach might be to define the basic language only such that all basic problems can be expressed, and to permit growth of the language inside the language’s rules;
Under the headings “aesthetics” or ‘‘correctness checking” much ink has been spent already to defend verbosity of code, complete declaration lists — or the contrary. In all this there is rarely a reference to the fact that the prime number finder of a student, and a piece of code for nuclear reactor calculations written by a computer physicist might not have the same de-
mands on the language. Clearly the conciseness of instructions with no superfluous redundancy in many circumstances reduces human errors, whereas in a different context the 100% complete problem definitior
R.K. BOck/Program portability in high-energy physics
229
may have the same effect. A language using a minimum of typed characters, hence default definitions and ad-hoc conventions,
[31 CERN 6600 Comp.19.11.1964. Document.: CERN FORTRAN, Internal Document,
sounds attractive to many users. Not accidentally
[41J.M.
“pre-compilers” have already been used to attain this goal, like the Language Independent Macro Processor of Waite [9] which has been used to allow a shorthand ALGOL. There is no reason, though, to impose
programming shorthand on everyone. For instance, language keywords might be defined to start with a “keyword character”, be recognised by their first
three characters only, and terminated by a blank or other terminator, leaving as much room as desired to verbosity: DEC, DECLARE or DECLARATION then
all have the same meaning, and nobody is punished even when typing DECLARTAION.
References [11 P.C.Poole and W.M. Waite, Lect. Notes in Economics and Mathem. Systems 81(1973)183.
[21 USA Standard FORTRAN USAS X3.9 — 1966, USA Standards Inst. (now ANSI). Stewart et al., Techn. Rep. TR-192, Univ. Mary-
land, Comp. Sc. Centre (June 1972). 151 HYDRA System Manual, CERN, TC Division, Internal Document; Initiation to HYDRA; CERN/DPhII/Prog 74—4, Internal Report. 161 R.K. BOck, E. Pagiola and J. Zoll, Computer Phys. Commun. 5 (1973) 400. [71 CERN Computer Library, PATCHY, Long Write-up (L400). Internal Document; CERN Library, SUMX Long Write-up (Y200). InternalComputer Document. 181 M.C. Newey, AFIPS Proc., FJJC 33 (1968) 1339. [91 W.M. Waite, Comm. ACM 10 (1967) 433. [101 J. Weizenbaum, Comm. ACM 6 (1963) 524. [11] D. Roos, AFIPS Proc. FJCC 27 (1965) 151. 1121 W.P. Schirikow, JINR Dubna, Preprint 10-4242 (1968); and BESM-FORTRAN, Zentrum für Rechentechnik der Akademie der Wissenschaften, Zeuthen 1969. [131 S. Moriguti et al., in: First USA—Japan Comp. Conf. Proc. AFIPS and IPSJ, October 1972, Tokyo.