BAS(ID:5463/bas001)Symbolic assembler for the ATLASfor Binary and Arbitrarily Symbolic symbolic assembler for the ATLAS computer Related languages
References: Introduction A compiler which treats a whole program as a unit can obviously produce its output in the form of binary words exactly as they are to be stored for execution. There is no need in this case for any intermediate form of storage. However, experience in using automatic programming languages has shown the enormous advantage of allowing the programmer to split up his program into more-or-less independent routines, to limit the scope of certain identifiers. There is a considerable difference between the processing which has to be carried out inside each routine and that which links routines together. We emphasize this difference by using the word compiler or assembler to designate the processor for individual routines, and loader for that which links them together before initiating execution. We thus distinguish compile time, load time, and execute time. An appreciable part of the work of a compiler consists of the treatment of cross-references of one sort or another: identifiers and statement numbers, both of which play a very important part in automatic programming languages. The processing of cross-references is roughly proportional to the square of the size of the program or routine being compiled, and so it is advantageous to keep the routines small. If a large program can be broken up into ten routines of one-tenth the size, compiling time will be considerably reduced. In general, a loader does not need to be such a sophisticated processor as a compiler, and cross-references between routines can be dealt with in a simpler way, giving a net gain. With the technique of independently compiled routines, alterations to a program do not require the whole program to be re-compiled: only the relevant routines. Consequently, programmers are not discouraged from making corrections in source language, rather than in binary. in The Computer Journal 5(2) July 1962 view details Extensive, well-written discussion is given of the detailed BAS loading process and implementation procedure being used. Nevertheless, it is indicative that the newer loading systems being designed such as for the ATLAS system and for the FORTRAN IV system (which has a subprogram form somewhat intermediate to BSS and BAS) are becoming increasingly sophisticated, so that it is no longer a simple task to evaluate factors such as loading speed or debugging convenience. in ACM Computing Reviews 4(03) May-June 1963 view details Many features in the BAS language, the output for translators on Atlas, resemble features of the LSS form as described in the preliminary report, of the work which was issued as a SHARE Secretary Distribution. A key feature of the LSS form, the grouping idea, has not been included in the BAS language form. in [ACM] CACM 6(07) July 1963 view details IN 1960, when the purchase of Atlas was being discussed with the manufacturers, the programming language Fortran was already widely used in America but much less used in England. This is probably because it had been implemented mainly on the larger IBM computers - the language was produced by IBM - and not many organisations here owned or had access to one of these machines at that time. It was clear to all the people concerned with the Atlas project that a good Fortran compiler would be essential, and the need was made particularly great by the expectation that the Atomic Energy Authority, which was probably the biggest user of Fortran in England, would want to use a large amount of time on Atlas. Nowadays, of course, no manufacturer would sell a big computer without a Fortran compiler, but the situation was different in England in 1960; and it was arranged that the Computing Group in A.E.R.E. Harwell would undertake the production of a Fortran system for Atlas, with assistance from Ferranti. The original ideas on which the system was based were produced by A. R. Curtis and I. C. Pyle of Harwell. After the Atlas Laboratory had been formally set up in December 1961, several of the system programmers transferred from Harwell to this, new people joined and then the centre of gravity of the project gradually moved over to the Atlas Laboratory until finally all the work was being done there, with the present authors in charge. The object was to write an operating system - called Hartran, to convey the idea of a Harwell version of Fortran - which would give the user plenty of flexibility in presenting work to the machine and getting results from it. It was to comprise a compiler for a form of Fortran which would be essentially IBM Fortran II, with some extensions and the removal of some restrictions; an assembler for a mnemonic form of Atlas machine code, to be called ASP - Atlas Symbolic Programming; and a loader for a language BAS - Binary and Arbitrarily Symbolic - into which Fortran and ASP would be compiled. It would allow options like compile-and-run, production of binary cards, production of program listings and use of either IBM or Ampex tape as Input/Output streams, and fairly extensive diagnostics were to be provided. All this was achieved and the system is running substantially as was planned. in [ACM] CACM 6(07) July 1963 view details |