Brian A. Wichmann

A synthetic benchmark

A simple method of measuring performance is by means of a benchmark program. Unless such a program is carefully constructed it is unlikely to be typical of the many thousands of programs run at an installation. An example benchmark for measuring the processor power of scientific computers is presente d: this is compared with other methods of assessing computer power. (Received December 1974) An important characteristic of computers used for scientifi c work is the speed of the central processor unit. A simple technique for comparing this speed for a variety of machines is to time some clearly defined task on each one. Un fortunately the ratio of speeds obtained varies enormously with the nature of the task being performed. If the task is defined informally in words, large variations c an be caused by small differences in the tasks actually performed on the machines. These variations can be largely overcome by using a high level language to specify the task. An additional advantage of this method is that the efficiency of the compile r and the differences in machine architecture are automatically taken into account. In any case, most scientific programming is performed in high level languages, so these measurements will be a better guide to the machine’s capabilities than measuremen ts based on use of low level languages. An example of the use of machine-independent languages to measure processing speed appears in Wichmann [7] which gives the times taken in microseconds to execute 42 basic statements in ALGOL 60 on some 50 machines. The times were measured by placing each statement in a loop executed sufficiently often to give a reasonable interval to measure. The time for the statement is found by taking from this interval the same measurement with a dummy statement and dividing by the number of repetitions. The two thousand or so time measurements provide a lot of information about the various implementations of ALGOL 60 but do not directly give a performance measure. With basic statement times for only two machines, the average of the 42 ratios between the times provides a simple comparative measure. This technique can be generalised by assuming that the times Tij for a statement i (i = 1 to n) on machine j (j = 1 to m) satisfies

The choice of computer languages for use in safety critical systems

The paper reviews the choice of computer language for use in safety-critical systems. The advice given reflects both civil and military requirements. A comparison is made between assembly-level languages, the language C, CORAL 66, Pascal, Modula-2 and Ada. It is concluded that a well defined sub-language is essential for use in safety-critical projects, and a guide is provided for project managers and designers on the characteristics which such a subset should possess. >

Generating good pseudo-random numbers

A widely used pseudo-random number generator has been shown to be inadequate by todays standards. In producing a revised generator, extensive use has been made of a test package TestU01 for random number generators. Using this, criteria have been devised for the revised generator-also other high-quality generators have been identified. Facilities have been devised to allow the new generator to be used in a highly parallel environment, which is likely to be a feature of many future applications.

Is Ada too big? A designer answers the critics

Many have criticized the Department of Defenses new computer language, Ada, saying it is too large, too complicated, or too difficult to use. Are they right? And are there some simplifications that could be made to Ada without destroying its usefulness?

A draft description of Pascal

This paper provides a description of the programming language Pascal. It has been published to enable those without easy access to the official BSI ‘draft for comment’ to comment on the description.

An algol-like assembly language for a small computer

In a classic paper1 Wirth describes a language which combines the readability of ALGOL 60 with the flexibility and degree of control of a conventional assembly language. This paper gives an outline of a similar language for a small 16‐bit computer—the Honeywell DDP‐516. Implementing the compiler in its own language by recoding an ALGOL version of the compiler has shown that the language is suitable for large systems. With the compiler written in a high‐level language, many enhancements have been possible even though these were not envisaged in the original coding

How to call procedures, or second thoughts on Ackermann's function

Various problems have been encountered in using Ackermanns function to measure the efficiency of procedure calls in System Implementation Languages. Although measurements have been made of some 60 systems, the ones presented here are included only when comparisons are possible. For conventional machine design, it is possible to draw some conclusions on desirable instruction set features. A surprising result from the analysis is that implementation quality is far more important than the overheads implied by language design.

Run-time detection of undefined variables considered essential

Access to an undefined variable—one which has never been assigned a value—can be detected by automatic means. However, todays compilers do not detect undefined variables comprehensively, and the environment dependence of these errors often allows them to evade normal testing procedures. Language standards for Pascal, Modula‐2 and Ada specify the circumstances in which the undefined variable access should cause an error trap. The logic of undefined in these standards is compared, revealing problems in security, implementation effort and consistency with accepted programming practice. An alternative logic, ‘undefined if totally‐undefined’ is proposed.

Testing ALGOL 60 compilers

This paper describes some programs used to test ALGOL 60 compilers. The results of the tests on six compilers are given together with some comments on their likely effectiveness in locating bugs in other compilers.

Five ALGOL Compilers

A detailed comparison of the times taken to perform elementary statements in ALGOL 60 has revealed wide differences in performance. An examination of the machine code produced by five compilers (Atlas, KDF9 (Kidsgrove), 1900 (XALT), BS500 and 1108 (Trondheim compiler)) has been undertaken to find the reasons for the disparities. The large range of machine architecture means that very different techniques have been used for code generation. This enables one to give guide lines for a suitable architecture for good ALGOL 60 code generation to be possible. (Received September 1971)