.ll 72
.lt 72
.po 4
.nh
.na   \" No justification
.de HH
'tl /Multiple Modula2 Compilers//Page %/
'sp
..
.de FF
'sp 2
.tl /VLSIC Design Aids Group Working Paper//DRAFT: DO NOT CITE/
'bp
..
.de SH
.if \\n(nl-80 .sp
'ne 5
'ti0
'cu
\&\\$1
'cu
\&\\$2
\&\\$3
..
.de pp
.sp
.ti 3
..
.sp 6
.ce
.cu
MEMORANDUM
.sp 4
.nf
TO:    Jeff Tansley.

COPY:  To whom it may concern.       

FROM:  Lee Smith.

DATE:  16th August 1984.
.fi
.sp20
.cu
.ce
On the Acquisition of Modula2 Compilers by Acorn
.sp15
.ce
Printed \n(dy/\n(mo/19\n(yr
.nr % 0
.wh 0 HH
.bp
.wh -4 FF
.SH 0. Preamble
.pp
Laudably, Acorn has made a commitment that all software for future (32-bit)
systems should be written in a high-level programming language. Modula2 has
been chosen as this language and because Modula2 is technically adequate for
the task (in fact, for a wide range of tasks) this choice is not at issue.
Furthermore, there is no language in existence which shows any clear advantage
over Modula2 when evaluated over the wide range of applications in which
Acorn will be involved.

.SH 1. "Acquistion Issues"
.sp
.in+3
.ti-3
A. The present VAX and 3206 compilers developed by Mick Jordan are not
saleable (for more than 100 pounds) because of licence restrictions on the
use of the ETH compiler front-end.
.sp
.ti-3
B. The present 32016 compiler requires a minimum of 640Kb in which to run
so it is not suitable for sale on 'punter machines' anyway.
.sp
.ti-3
C. The extensions of Modula2 proposed by ARC may lead to Acorn-Modula2
becoming effectively incompatible with all other Modula2s.
.sp
.ti-3
D. Modula2 is to be the subject of an ISO standard next year.
.in-3
.sp
The first two observations make the acquisition of at least one more Modula2
compiler (per machine type) essential unless we are to duck out of selling
Modula2. I presume that this 'easy option' is unacceptable: Modula2 is
gaining popularity rapidly and to be without it could be as serious as
being without Pascal; and, if we write all of our systems software in Modula2
then refusing to make Modula2 available would be seen as being inconsistent,
obstructive and highly suspect.

.SH 2. "Compiler Compatibility Issues"
.sp
.in+3
.ti-3
E. Differences between the languages accepted by different compilers.
.sp
.ti-3
F. Differences between the run-time libraries used with different compilers.
.sp
.ti-3
G. Differences between the code-generation strategies used by different
compilers, particularly with respect to calling conventions and storage
allocation.
.sp
.ti-3
H. Differences in programming paradigms arising from 1 and 2.
.in-3
.sp
These points are now addressed in more detail.
.sp
.in+3
.ti-3
I. Modula2 is not 'well-defined'. The present definition gives considerable
lattitude to the implementor (for example, multi-word function returns, though
not implemented and not mandated appear not to be forbidden). Clearly, an
ISO standard will lop off some of the danglers but unless super-setting is
forbidden or carefully defined the standard will not even standardise the
language! If we extrapolate from the fiasco with Pascal then we must assume
that the standard will essentially cast 'the book' in stone, idiocies and
all, with the result that there WILL be widespread super-setting by
individual implementors. In short, the usual tower of Babel. ARC extensions
cause some problems here but these are minor compared with the other
effects that these extensions may have. I also consider it unlikely that the
standards committee will make much headway on standardising processes; if they
do then I consider it unlikely that implementors will agree (or will be able
to afford) to be bound by the decision (see also later discussion on likely
strategies for process implementation).
.sp
.ti-3
J. A program written in Modula2 depends not only on the language but on the
run-time library (e.g. for all input and output). Unless (at least a core of) 
the run-time library is the subject of an ISO standard, code will not be
portable between Modula2 compilers. Even if the functions the library
implements can be agreed (which is most unlikely) portability is not assured.
This is because the library embodies certain implementation-specific, 
machine-specific and operating-system-specific functions. These cannot
necessarily just be recompiled under another compiler: knowlege about the
internals of the compiler may be required (assuming, even, that the library
is written in Modula2 - our's is but this is not mandatory).
Unless each run-time library is carefully divided into an
implementation-specific section (the function of which MUST be standardised)
and an implementation-independant section (written in ISO-Modula2 to allow
re-compilation using other compilers), the different compilers (with their
different libraries) might as well be for different languages. Note also
that the tricky commercial issue of whether the source of the library will
be available for less than a King's ransom has not not even entered into
my present (technically based) gloom!
.sp
.ti-3
K. Modula2 has a logical TYPE system not a physical TYPE system. The
lementation of a logical TYPE (e.g. BOOLEAN or REAL) on a particular machine
is not defined. Furthermore, there are no clear choices, even for
relatively simple TYPEs. Code compiled by 2 different Modula2
compilers is not likely to be cross-callable - even if the compilers can be
made to obey the same procedure calling conventions and to use registers in
a compatible manner.
A good example of this type of incompatibility is given by comparing the
Darmstadt VAX/VMS Modula2 compiler with MJ's VAX/Unix Modula2 compiler.
They both use the same front-end and, hence, accept EXACTLY the same language.
They both produce VAX machine code. However, Cross-calling is completely
impossible as the TYPE representation conventions and argument passing
conventions are completely different (BOOLEANs don't even occupy the same
number of bytes in each implementation!).
.in-3
.pp
The language extensions proposed by ARC concerning lighweight processes and
exceptions, though syntactically minor, are really very fundamental.
Although 'standard' Modula2 will still be compilable, the effect of the 
extensions will be catastrophic to compatibility and portability.
.pp
Lightweight processes are revolutionary and largely untried. If we can figure
out how to use them then our programming practices will be altered radically.
A specific problem here is the emergence of a Modula2 Programming Support
Environment (MPSE) in which graphics, window management and data-base
interfaces are embedded. The development of a MPSE is essential if
software productivity is to be increased, software development times
are to be shortended and, in the long-term, if products acceptable to the
market are to be produced. If the MPSE uses (as it surely will) these
language extensions then it is not clear that applications can be written
in anything other than the extended Modula2, even if another cross-callable
Modula2 exists (which is highly unlikely). The argument goes as follows.
Language extensions can only be justified if they give significant leverage
against some hard problems. Lightweight processes and exceptions do just this
for PSEs. Applications cannot afford to throw away such advantages and it is
not obvious that the MPSE interface will (or can) allow the full benefit of
facilities built using the extended Modula2 to be made available to clients
written without recourse to the extensions.
.pp
By the way. There is no viable alternative to developing a MPSE: we cannot
afford to write every single application as a stand-alone program.
.pp
Other implementors of Modula2 bent on selling Modula2 compilers are not likely
to implement lightweight processes. rather, they are likely to integrate the
Modula2 process structure (whatever it may be!) with the already
mature 'heavyweight' process structure of the host operating system. Unix
would be a likely de-facto standard. This has major implications for the
interpretation of module data (is it program-own or process-own?) and is
likely to ruin the portability of any multi-threaded code between the
Acorn-Modula2 compiler and other Modula2 compilers.
.in-3

.SH 3. "Applications Areas"
.pp
Before continuing, we should distinguish possible target applications areas.
Obvious areas are:-
.sp
.in+3
.ti-3
L. Acorn internal use for R&D purposes.
.sp
.ti-3
M. Systems Implementation Language for professional level products
.sp0
-  under Unix/Xenix
.sp0
-  under Tiny Kernel or other Acorn OS (New Environment?)
.sp
.ti-3
N. Sale/release to punters, software houses, OEMs under Unix/Xenix/TK/NE.
.in-3
.sp
We should note the following.
.in+3
.sp
.ti-3
O. Punters, software houses and OEMs (workers, soldiers and students!) might
legitimately wish to extend or access 'low level' features of an Acorn
operating system. Access to the SIL compiler could not reasonably be denied.
If access were to be denied then it would be essential to have another
cross-callable Modula-2 compiler to make available.
.sp
.ti-3
P. Professionals will use 'engines'. No programming here. However, suppose we
marketed a program development engine. What then?
.sp
.ti-3
Q. Is import of forign software written in Modula2 likely to be an issue?
If we sub-contract the writing of a system to a software house, what will be
the effect of asking them to use an unfamiliar Modula2 which requires
quite different programming paradigms for its effective exploitation?
(chaos, that's what! I used to teach some of the buggers the software houses
use).
.sp
.ti-3
R. Management belief that standardising on one language solves any problems
is NAIVE and DANGEROUS. We must always refer to 'Acorn-Modula2' in order
to undermine this faith in one language. Only standardising on one compiler
will fix the kind of problems I have outlined.
.in-3

.SH 4. "Fire-Fighting Suggestions"
.in+3
.sp
.ti-3
S. Partition the applications space a-priori; accept that there will be
(radically) different Modula2s. Choose horses for courses. Drop belief
in 'one language'.
.sp
.ti-3
T. Commission or acquire ONLY Modula2 compilers compatible with Acorn-Modula.
This is probably impractical on the required timescales and would ignore the
ISO standard.
.sp
.ti-3
U. Drag ARC into line with ISO-Modula2; force MPSE development into
ISO-Modula2 This is probably impractical: an ISO standard is at least a
year away; the standard might be duff (caveat Pascal); the MPSE will be harder
(impossibly hard?) to implement without the extensions.
.sp
.ti-3
V. Force MPSE development to allow applications to be written in ISO-Modula2;
acquire only compilers which conform to the Acorn calling standard
or bend the Acorn calling standard as necessary. This option is superficially
attractive but has very little chance of succeeding because of the Trojan
Horses of logical to physical TYPE mapping and module data storage class
interpretation, which preclude cross-callability.
.in-3

.SH 5. "Personal Conclusions"
.sp
.in+3
.ti-3
1. The apparent adoption of one language (Modula2) has not solved any
portability or compatibility problems. However, is does reduce their frequency
and it does minimise training and support difficulties.
.sp
.ti-3
2. Senior management must be made aware that Acorn-Modula2 and ISO-Modula2
are effectively two different languages.
.sp
.ti-3
3. Of the alternatives outlined in section 4, only the first has any
viability. Common sense precludes the acquistion of many compilers for
the same language therefore we should accept that for each environment
(hardware + operating system + filing system + MSPE) there should be 2
AND ONLY 2 Modula2 compilers: one for Acorn-Modula2 and one for ISO-Modula2.
Note that this is still potentially a frightening total number and that
potentially a frightening number of Acorn-Modula2 compilers may be needed
unless a portable MPSE with good support for (cross-callable) ISO-Modula2
emerges. Who will write the Acorn-Modula2 compilers?
.sp
.ti-3
4. ARC should be asked to minimise the impact of MSPE developments on
applications written in ISO-Modula2. However, some impact will be inevitable
and that it would be better to accept this than to constrain the developments.
.in-3