Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Fri, 2 Oct 1992 00:44:42 GMT
Organization: Computer Science Dept. University of Auckland

Gosh. Another flame war involving JK. Surprise surprise.

kortink@cs.utwente.nl (John Kortink) writes:

>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.

No. That is a case of 'old code will run on...' rather than 'code that
will run *natively* on...'. Sure, old 26-bit address-mode code will
RUN on an ARM-700, but what is the point of getting an ARM-700 if the
code runs as slowly as on an Arm-3? And can't use more memory? Or any
of the other features of the new hardware?

And remember that the output of a c compiler is actually arm code, so
your argument is *exactly* the same for compiled code...
Please try and *think* of a reasonable argument before you bash the 'f'
key...

>>>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'm sorry? When I get an ARM-700, I'll just upgrade my compiler at the same
time to version 5, with support for the extra instructions and modes
available.
The C compiler itself is written in C (isn't it?). Running it on the
new chipset is easy, because of backwards compatability. Modifyig it
to output 32-bit clean code will not take long (compared to modifying
the equivalent assembler program or re-writing the compiler from scratch)
and once you have it outputting the new code, you can use it to recompile
ITSELF  to run on the new architecture.

>No, I don't. I guess you are looking at things rather strangely.
An interesting comment coming from somebody so completely unbiased, John.

>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.

Did you not consider that C (Manufacturer of said new chip) might have thought
of this, and have ALREADY spent the last year modifying the compiler to
handle the new instruction set, so that developers get upgrades at or
before the release of the chipset upgrade?

And I also feel that you have an over-simplified view of the simplicity
of re-writing your Assembler. Remember that the assembler-writer has to learn
new instructions, new tricks, new loopholes, new side-effects, while the
C programmer just types 'amu' and waits for 5 minutes.

And the C programmer doesn't have to debug the code he produces- that part
of the development cycle has been done; while the assembler programmer has
to test and debug every part of his code again to make sure that all the
new things added are correct, and that all the old things left in are still
working properly.

>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.

...until they decide to port Impression onto, say, a PC?

Face it, John and company. BOTH C and Assembler have their advantages AND
disadvatages. They are DIFFERENT. Personally, I find that C is a good, fast
development environment with nice high-level operations, with access to
low level functions (if you write some C code thinking in terms of ARM
instructions, you can usually make the compilee output exactly those
instructions anyway), and where it is not fast enough, I can write as much
assembler as I want to, and link it in.

The two languages should be used TOGETHER so that they AUGMENT each other.
Get the best of BOTH worlds, rather than arguing about them!

>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.

Well, my only comments here are:
  * Most people involved in software development in the world today do not
    use assembler as their main language. They usually use a compiled
    language. Code size and a few percent more performance are not
    very big problems with the size of memories and the speed of modern
    chips.

  * I have never seen a copy of Impression where the redraw hasn't been
    affected - Something is *always* broken.
    Now I know that in C I could make a separate redraw module with a
    defined interface and let the compiler do the work of ensuring that
    the interface is consistent across my whole (very large) application.
    I wrote the redraw code in DSEdit about 7 months ago, and it hasn;t
    been touched since. I *know* that it works. I *know* that if I don't
    change the "redraw.c" file, my redraw will not break.

    If this were possible with Assembler, then why has the redraw code in
    Impression been *broken* in a multitude of different ways since version 1?
    (I'm up to 2.17, and the old redraw bugs are gone: Now there are new ones)
    Sure, Impression's redraw is more complex than DSEdit's, but I can't
    help feeling that the better module-separation provided by C helps
    to insulate my redraw code from my other code.

>And still people wonder why CC is so enormously succesful ?

I don't wonder: They write damn good software. However, I fail to see why
you hold this up as proof that assembler is better than C: Has it not
occurred to you that CC's programmers are *good*, and that it's not purely
the choice of language which has made the products good?

Further examples:
Personally, I think that MacApp on the Macintosh is horrendous: It makes
applications large and ungainly, and more than a little slow, but I also
think that programs like Adobe Photoshop which are written using MacApp
are very very good. MacApp is not responsible for the quality.

DSEdit uses RISC OS Lib, but a lot of effort has been applied to nullify
all the awful things RISC OS Lib does (or doesn't). It's actually quite
nice to use (IMHO), despite the fact that it was based on the utterly
awful RISC OS Library.
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)