From: kortink@cs.utwente.nl (John Kortink)
Subject: Re: Oh no ! More .....
Organization: University of Twente, Dept. of Computer Science
Date: Thu, 1 Oct 1992 19:18:54 GMT

Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes :

>In article <1992Oct1.103327.26336@cs.utwente.nl> kortink@cs.utwente.nl
>(John Kortink) writes:
>[...]
>>God no, not *again* ! If anything the ARM code program could cope
>>*much* easier with this change because it is written in the same
>>language and the source can be updated in no-time.
>
>ARM assembly is the best assembler I've seen, and the most pleasurable
>to use, of the 4 I've actually coded in.  However, methinks that you
>are over stating the speed of change by a trifle.

The new ARMs are backward compatible. There can hardly be any argument
about how much time it would take to alter existing ARM source code to
run on a new ARM. Virtually nothing. It might even be a case of search
and replace, say a day or so. That's, again, because the source speaks
the same language.

>>For a C source, an entirely new C compiler would have to be written.
>
>The compiler would need modification, rather than an entirely new one
>produced.

What bollocks. What developer can go about making 'modifications' to an
entire compiler of which he doesn't even have the source ? We would all
have to wait for a new version of the Norcroft compiler to take advantage
of the new features.

>I thought this would have been obvious!  Do you *really*
>need a lesson in elementary compiler design?

No, I don't. I guess you are looking at things rather strangely.

Again, take two developers : developer A has an ARM source code, developer
B has a C source code and a C compiler. All work on 'old' ARM's. Now the
new generation of ARM's arrives. Code is backward compatible. New features
(new opcodes, addressing modes, 32-bit data).

A : Has to adjust his source code and assembler (latter is trivial compared
to a C compiler and can be done on the spot) to arrive at the same
functionality.

B : *Has* to wait for a new Norcroft C compiler taking advantage of (usually
*all*) the new features, which takes a lot of time. Only then, after a
considerable time, can he recompile his code. In the meantime he can't do
anything.

>>In the meantime, Gavin, Impression and ArtWorks are/will be probably
>>the best and most widely used applications on the Archimedes.
>
>It was never stated that "C", should, or would, always be used for
>major applications!

Yes it was. The original quotes were these. From the mag :

>>"It is generally accepted that C is the language to use if you intend to
>>write a serious application of any complexity"

And you :

>These are just some of the motivations for using "C" for "'Serious
>applications of any complexity' on the Arc".

These CC apps were part of the original argument. They prove that ARM code
reigns supreme over any C code, given the extra development time.

Developers just chicken out of ARM code because of the extra time taken and
end up with bulky and slower code. CC, which must be an intelligent bunch,
recognized that in the end they will have the last laugh and have a few,
but massively supreme applications which are much faster and smaller, of
which we all know the multiple advantages, direct or indirect.

I think it's a sad state of affairs that the low quality of a lot software
is so much the result of short-term economics.

And still people wonder why CC is so enormously succesful ?


John Kortink

Student of Informatics at the University of Twente, The Netherlands
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual