Abstract There is now a good understanding of problems encountered in the design, implementation and use of a high‐level language converter. These general issues are illustrated in terms of an account of the design and implementation of one particular converter, which converts programs from Pascal‐SC (a Pascal dialect) to Ada. A specific aim of the presentation is to provide guidance for those contemplating future language conversion projects.

Ada supports two different schemes for floating-point arithmetic portability - one based on the use of the underlying machine arithmetic and the other based on the 'model arithmetic' that the underlying machine supports. Features of both schemes are explained in the context of their suitability as bases for the production of portable numerical software.

We describe a Fortran to Ada converter that uses a standard intermediate tree representation of the program being converted. Points of some general interest include overall comments on high level language conversion and the selection of an intermediate representation as well as the way the design of this system was influenced by that of the interactive improvement system for which it is ultimately to provide components. Finally, the existing system and the conversions applied to some selected Fortran constructs are described in detail.

Programming even in a fully standardized high-level language requires great care if portable programs are to result. We review two recent attempts at producing guidelines for portable programming in high-level languages. Areas of particular difficulty, software aids to monitor compliance with projected guidelines, the prospects for enhanced portability of future languages and the form of published guidelines are separately discussed.

Abstract We describe the transfer of a BCPL compiler installed on a PDP‐11 to a hobbyist's home Z80 microcomputer. The design of the Z80 support software needed is explained in some detail. The development of a debugging Ocode interpreter and of an Ocode loader featuring code compression proved particularly helpful.

Abstract A discussion of the handling of type information by the translator for the Portable Programming Language is broadened to include some related details of the PPL design and the way in which type information is used during storage management. No knowledge of PPL is assumed and the presentation is sufficiently broad‐based to provide insight into the compiling actions needed for more complicated languages such as Algol 68 and Ada; some design details of the three languages are contrasted. The implemented type‐handling in the PPL translator takes many details from a denotational semantics for a forerunner of the language.

Abstract Continuing the work presented in an earlier paper, we explain the design of the runtime storage management scheme for the Portable Programming Language (PPL). The design method uses three basic ideas‐the use of reduced type‐expressions, the classification of the components of an object according to the way their sizes vary, and the handling of stored objects as tree structures. It is illustrated by using it to derive a storage management scheme for the Portable Programming Language, and storage management schemes appropriate to Algol 68 and Ada that compare favourably with those already described in the literature.

The portable programming language (PPL) is one of a number of recently designed programming languages that enable the user to define new types by giving their representations and operations in terms of those of previously available types. Such provisions for the construction of objects of user-defined type have been discussed elsewhere; this work concerns the related problem of the external representations of such objects, both on input-output media and as written constants within the program text. We introduce an enhancement to the PPL design allowing specification of the external representations of objects of user-defined type. This extension to the PPL design means that objects of user-defined type can be read, written, and used as constants exactly as if their representations had been selected by the writer of the PPL compiler. The implementation and use of the added facilities are also discussed.

Simulation of the liver show more than one component, and so are more like the normal experimental curves.As yet we can only claim that the simulations do produce curves in qualitative agreement with typical experimental ones.It is hoped to publish more detailed physiological results elsewhere. ReferencesWe wish to acknowledge the assistance of Miss G. Almond who wrote some of the preliminary trial programs for the computer, and also supervised the running of the simulation program.We also wish to thank Dr. T. G. Richards for his assistance with points of physiological detail.