CERN Accelerating science

This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern/ for current CERN information.

CERN home pageCERN home pageDocuments by ReferenceDocuments by ReferenceCNLsCNLsYear 2001Year 2001Help, Info about this page

Contents

Editorial Information
Editorial
If you need help
Announcements Physics Computing Desktop Computing Internet Services and Network Scientific Applications and Software Engineering Desktop Publishing The Learning Zone User Documentation Just For Fun ...
Previous:Scientific Applications and Software Engineering
Next:A Brief History of Cernlib (1966-???)
 (See printing version)



Programming Languages over the Years

Julian Blake , IT/PDP


Abstract

This is a personal tour of programming languages which I have encountered since I first learnt to program a computer in 1959.


Assembly codes

Assembly languages have changed over the years, starting very simple (binary or decimal instruction codes and operands), growing to accept mnemonic operation codes and operands in place of numeric ones, and adding macro and conditional assembly features. Nowadays programming in assembly language is rarer than it used to be, and rather simple mnemonic assemblers, sufficient to process the output of a compiler, are used.

The English Electric DEUCE was programmed in binary (one 32-bit word to each row of a punched card). Each instruction had to specify the location of the next instruction to be obeyed, and the way to get a fast program was to place instructions in the mercury delay lines such that there was no unnecessary waiting between instructions. An interesting technical challenge was to write a bootstrap program of twelve instructions on a single punched card. During my time as a pre-university student at the English Electric Company, a staff member was in the process of writing an assembler which would, inter alia, look after instruction placement.

The EDSAC 2 and Titan (ATLAS 2) computers at Cambridge University had decimal assemblers. Both operation codes and operands were specified by decimal numbers. Both computers had built-in firmware to perform common tasks, for example conversion between binary and decimal. The order code of the Titan was designed so that it would be relatively easy to remember the decimal operation codes (the regularities in the order code showed most clearly in decimal).

The most powerful assembler with which I have worked was Control Data's COMPASS macro assembler for the CDC 6000 and 7000 Series central (CP) and peripheral (PP) processors. Operations and register operands were specified by mnemonics. CP instructions were written in a particularly user-friendly form: "SA1 A0+B1" denoted "set address register A1 to the sum of address register A0 and index register B1" (this initiated a read from central memory address A1, as reading was the function of registers A1 to A5). COMPASS was a classical two-pass assembler with macro and conditional assembly features, and generated a full listing showing both the source assembly code and the generated machine code (in octal). CDC's operating systems were written almost entirely in COMPASS assembly language. So too, at CERN, was the software for the Remote Input/Output Stations (RIOS, running on Modular 1 computers) and for SUPERMUX (terminal concentrators running on HP 2100 computers); the technique was to define a set of COMPASS macros for the target computer's order code, and to post-process the output of COMPASS to shorten 60-bit words to the word length of the target.

Several cross assemblers were written at CERN:

  • in BCPL for the ModComp computers of the CERNET packet switching network, and for the I8080, M6800 and TMS9900 microprocessors;
  • in Pascal for the M6800/6801/6809 and M68000/68020/68030+68881 microprocessors.
This list is not exhaustive. There were certainly others, for example the cross assemblers for the ESOP and XOP bit slice processors.

Structured assembly languages

Structured assembly languages provide a mixture of access to machine specific features such as registers and addressing modes, and high level language constructs such as begin-end blocks, procedures, if and case statements, and for and while loop constructs. The first such language was Niklaus Wirth's PL/360. At CERN, Robert Russell created PL-11 (for PDP-11) and later PL-VAX.

I had brief contact with PL-VAX, and with the PL/M language for Intel microprocessors.

Autocodes

My first programming language was DEUCE Alphacode. The language provided a set of floating point variables (X1, X2, ..., X2200) and a smaller number of counting (integer) variables (N1, N2, ..., N63). One line of code could perform a single operation, for example "X1 = X2 + X3" or "X4 = ROOT X5". The statements of Alphacode were usually interpreted, not compiled. Writing and using an Alphacode program was an improvement on performing pre-specified calculations on an electro-mechanical calculating machine, my previous activity at English Electric.

EDSAC 2 and Titan Autocode at Cambridge University supported operations on a fixed set of integer variables (I, J, ...) and of floating point arrays (A[5], B[7], ...). Autocode was a compiled language. Since I was interested in algorithms for syntactic analysis of programming languages at that time, the lack of arrays of integers ruled out the use of Autocode during my doctoral studies.

Algol 60

I was introduced to Algol 60 while working as a summer student at Elliott Automation, using the Elliott 803 computer. I remember being amazed when shown a recursive algorithm for the travelling salesman problem, and discovering that Algol did indeed allow a function to call itself.

FORTRAN

I first encountered FORTRAN IV when I arrived at CERN. How could a computer programmer live to the age of 26 years before using FORTRAN? The answer lies in the traditions of Cambridge University's Mathematical Laboratory, now renamed the Computer Laboratory. Shortly after I left Cambridge, the University bought an IBM computer for its computing service, thereby introducing FORTRAN.

FORTRAN was the most important computer language at CERN, so much so that people used to say, only half jokingly, that whatever computer language physicists were using in five, ten or fifteen years time, it would be called FORTRAN. Only when CERN decided to move to C++ instead of making the transition from FORTRAN 77 to Fortran 90, did the use of FORTRAN decline.

Although Pascal and C were the most frequently used high level languages on microprocessors at CERN, FORTRAN was used too. An extreme example was Hans von der Schmitt's RTF/68K (Real Time Fortran 77 for 68K Processors), whose compiler was written in a compiler description language which was translated into FORTRAN by a compiler generator, also written in FORTRAN.

SYMPL

SYMPL was an Algol-like systems implementation language created by Control Data for its 6000 and 7000 Series computers. I used it to write the CP (central processor) part of the 6000 Series software for CERNET; the PP (peripheral processor) part was written in COMPASS assembly language. Dietrich Wiegandt, writing CERNET software for the IBM System 370, had to write it all in assembly language. I was the more fortunate person.

BCPL

Martin Richards' BCPL is known as an ancestor of the C programming language. BCPL was used at CERN to write CERNET node software for ModComp II computers, and CERNET host software for PDP-11 and Nord 10. The BCPL compiler was written in BCPL. It ran at CERN as a native compiler for CDC 6000, IBM 370, VAX, PDP-11, Nord 10, HP 2100; and as a cross compiler for ModComp II and TMS9900. Cross assemblers, a linker, a librarian and pre-loaders ("pushers") were written in BCPL for ModComp, I8080, M6800 and TMS9900.

Ada

Ada 83 was tried at CERN by an ad hoc evaluation group, but never went much further. It was however used to write the error message module of the MODEL data acquisition system. One Ada critic felt that the inter-task rendezvous mechanism was unsuitable for real-time data acquisition systems. My own experience was that type checking was so strict that even carefully constructed code could be rejected by the compiler for no understandable reason.

Pascal

The second generation of CERN cross software for microprocessors was written in Pascal. This included cross assemblers for M6800/6801/6809 and M68K (M68000/68020/68030+68881), and M68K cross compilers for Pascal, Modula-2, FORTRAN 77 and C (unfinished). The FORTRAN cross compiler was little used as there were well established UNIX-derived f77 and C cross compilers. MoniCa, a debugging monitor for M68K, was written in Pascal and assembly language. MoniCa was used in the ALEPH event builder, in VALET-Plus test systems, and elsewhere. The Pascal cross compiler, which originated in Siemens research laboratories and was extended at CERN to become a multi-language compiler, was sufficiently good to see off competition from some commercial Pascal compilers. A few years later, however, DD divisional management decided that the time had come to stop developing microprocessor cross software.

At the height of its use at CERN, Pascal was considered a safe language in which to write programs, whereas C and BCPL were considered dangerous.

Modula-2

Modula-2, Niklaus Wirth's successor to Pascal, was used on M68K hardware in the LEP control system.

At about the same time, Robert Cailliau in PS division was promoting the use of his enhanced Pascal, P+.

In both cases, necessary Pascal extensions included facilities for separate compilation and for bit operations.

Modula-2 was capable of running on a microprocessor without operating system, since its SYSTEM module provided the minimum necessary for accepting interrupts and switching context.

C

C came to CERN with UNIX (on PDP-11 and then on VAX), and with the OS-9/68K operating system (on M68K) which was used in LEP experiments' data acquisition systems. It is now the dominant language for control and data acquisition systems. Much code which used to be written in assembly language is today written in C.

The introduction into C of function prototypes, and the existence of instrumentation and debugging tools such as Purify and Insure++, has made programming in C less hazardous than it used to be.

The GNU C compiler has set a high standard, below which no commercial C compiler is viable.

C is the programming language with which I work most often today.

C++

C++ has taken over the role of FORTRAN as CERN's scientific data processing language. I have followed the development of C++ with interest, have helped to solve some problems with the use of C++, but have not become a practising C++ programmer. So take my views with a pinch of salt.

The definition of C++ and its run time library has taken a long time to stabilize. Early users will have discovered how much the language and library have changed over the years. Some of the newer features are still not correctly implemented by current compilers. C++ is so powerful that a programmer can write programs which his colleagues, and perhaps he himself, cannot understand. So select the C++ features which you use with care, look at some of the generated code (it may be more than you expect), and use a good debugging tool (such as Insure++).

Java

I admire Java and its class libraries, have been to a Java programming course and read the nutshell book, but do not actually write Java programs today. So my views on Java may be worth even less than my views on C++. Let's simply say that I like Java better than C++, and I think its use will spread well beyond its current application area of Web-based human interfaces.

Acknowledgments

In this article I have touched on the work of too many CERN colleagues to mention every one of them by name. Ian Willers was the driving force behind the use of BCPL at CERN. Horst von Eicken drove the second generation of microprocessor support software. Jean Montuelle, David Foster and Jonathan Caves made major contributions to the microprocessor cross software.


About the author(s): Julian Blake was the leader of the DD/SW/LM (languages and microprocessor support) section before it was dissolved.


For matters related to this article please contact the author.
Cnl.Editor@cern.ch


CERN-CNL-2001-001
Vol. XXXVI, issue no 1


Last Updated on Thu Apr 05 15:28:10 CEST 2001.
Copyright © CERN 2001 -- European Organization for Nuclear Research