From: kortink@cs.utwente.nl (John Kortink)
Subject: Re: Oh no ! More .....
Organization: University of Twente, Dept. of Computer Science
Date: Fri, 2 Oct 1992 12:52:10 GMT

jwil1@cs.aukuni.ac.nz (TMOTA) writes :

>Gosh. Another flame war involving JK. Surprise surprise.

Gosh, another long winding boring reaction by TMOTA. Suprise, surprise.

>[...]
>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?

What are you on about ? We were discussing changes to both ARM and C
source codes to take advantage of the new features. A lot of these will
be speed-wise and transparent to both. Again, the ARM code will be the
easiest to adapt because it's practically the same language. What is this
'we change to an 68000' attitude ? An ARM is an ARM and will be largely
backwards compatible.

>And remember that the output of a c compiler is actually arm code, so
>your argument is *exactly* the same for compiled code...

It is not. In ARM code it is 100% possible to use new features. In C it
is obviously much less as you have no low-level control over the code
produced. This is *exactly* why people program in ARM code, TMOTA.

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

We will just have to wait and see, won't we. Given the arrival of the ARM700
at a certain point in time, the ARM code sources will be updated *immediately*,
possibly also the C compiler, and the C sources only after this new compiler
arrives on your doormat. Nevertheless, I don't see the point in arguing over
which sources will be the first to be updated. The core argument was how
easy it would be and to what extent new features could be exploited. C loses
big here.

>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 gets a bulky bunch of three-times-too-large-and-equally-slow code that
will, here and there, use some of the new features.

Because of the sheer simplicity of RISC code, TMOTA, learning even a large
amount of new tricks, loopholes, side-effects, will be a doddle. And I
*seriously* doubt there will be so much to learn. If anything, when we
grant the ARM coder and compiler builder an equal intelligence in this,
they will both have learned all this stuff equally fast, and *you'll* still
be waiting for the compiler builder to wrap up and send it to you so you can
'amu' your way out.

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

Oh right, the C-compiler is bug-free ? And what do you do once you discover
a bug in your compiler ? Rewrite it ? The ARM coder does, on the spot.

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

Why on earth would they want to do that ? Do you have any examples of major
native code that was ported to a PC ? God you C freaks are a thick lot !
IT DOES NOT HAPPEN !

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

It's the *should* that's bollocks. Again, CC have proven this.

>  * Most people involved in software development in the world today do not
>    use assembler as their main language. They usually use a compiled
>    language.

And everybody in the world uses a PC. Does that make it a good computer ?

>   Code size and a few percent more performance are not
>   very big problems with the size of memories and the speed of modern
>   chips.

WHAT ??? You seriously think that's true ? You really want to spend 30Mb
of HD and 12Mb of memory for something like OS2 ?

And here's the 'few percent' again. Get real, TMOTA. It's easily a factor
of two to three that can be gained. Remember the speed difference of
ArtWorks to Corel Draw ? Remember the speed difference of my LZW code to
Spark's ? Can you imagine arcade games in ARM code being written in C
instead ? Have you looked at PipeDream's size compared to Impression ?

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

What a load of rubbish. What makes you assume Impression's code is not
modular ? And *they* can fix their redraw code on the spot.

Why can't you accept that high level languages are here to hide some of
the underlying complexities and do this at a *price* ? You can never have
the optimum flexibility of ARM coding.

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

How thick can you be ? You can't accept reality ?

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

Or the extreme slooooooowness of the beast. That's why I'm writing
ImageShop in ARM code. It will take longer, but it will kick the shit out
of PhotoShop in the end.

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

Great language isn't it ?


John Kortink

Student of Informatics at the University of Twente, The Netherlands
(God, will I ever stop doing things 'on the side' and get it done?)
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
Newsgroups: comp.sys.acorn