Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Sat, 3 Oct 1992 06:15:19 GMT
Organization: Computer Science Dept. University of Auckland

lithgow@usl.com (Malcolm Lithgow) writes:

>The berkeley gateway seems slow, so this may appear out of context a
>little.

>[In message "Re: Oh no ! More .....", TMOTA writes:]
>>Gosh. Another flame war involving JK. Surprise surprise.

>So let's jump in!! ;-)

>[Talking about re-compilation for a new architecture or implementation
>of the same architecture...]
>>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.

>Urk. Well, remind me to avoid any programs of yours on new
>architectures!

>C is not particularly portable, and writing fully portable C is
>bordering on the impossible! Anyone fool enough to neglect testing on a
>recompile of a C program when *anything* has changed (program, OS, or
>hardware) obviously has no idea of Quality Assurance techniques.

I said "debug". I do not consider TESTING the same as debugging.
Debugging is what I do *after* I test it and find a problem.
Obviously you would be stupid to recompile a million lines of C source
on a new compiler and expect absolutely everything to work.
("porting" DSEdit onto RISC OS 3.10 I have discovered two compatability
problems. Both extremely minor and easy to fix, but still 'bugs' to be
found and fixed. However, I don't need to *debug* ALL the DSEdit code to
make it run on RISC OS 3.10: I just need to test it thorughly and then
fix/debug any sections of the code which no longer work 100% as expected.
Although moving to a new OS is different from a new compiler, it has much
the same effect: A few unexpected little incompatibilities)

Also, I feel that 'porting' C code from desktop C version 4 to desktop C
version 5 (with Arm-700 support) is not quite in the same league of
difficulty/incompatability as porting C code onto a DECstation with a
*totally* differnt compiler.
You don't need to port the code so much as check that everything still
compiles to good, runnable code that still meets the design spec.s

>When you recompile your C app on new hardware, you *must* re-test *all
>of it*. This should not be too bad, though, because you should have a
>test suite that you can simply run through. Of course, the same is true
>for an assembly language program.

Of course you must.
C program:                     Assembler program:
  type "amu" to recompile.       Programmer learns new instructions, tricks
  test code thoroughly <-\  /--> Programmer runs clever auto-serach & replace
  debug -----------------/  |      to modify some bits of code to use new
			    |      instructions/tricks.
			    /--> Programmer assembles code, fixing all the
			    |      places where the global search & replace
			    |      wasn't done quite right because of the
			    |      special case he overlooked.
			    /--> Programmer sifts through the code looking for
			    |      and replacing bits that can be improved.
			    /--> Programmer assembles code, fixing all the
			    |      new syntax errors and typos as he goes.
			    /--> Programmer tests code thoroughly, finding
			    |      all the mistakes he has made (humans are
			    |      far more fallible at repeated stuff...)
			    \--- debug

The way I see it, the assembler writer has to go to much more effort.


>Another portability point that people have severely distorted in their
>minds! If Impression were written in C, at least 50% of it would have
>to rewritten in it's entirety (because it's interface stuff), and the
>other 50% would have to be substantially changed, or at least gone over
>with a fine tooth comb. The final result would not be that impressive,
>either.

Yes, but there is a significant difference between converting an assembler
routine into some other assembler (or HLL), and copy/pasting a single
C function into the new program. Sure there is a *lot* of wimp-specific
code in both programs, but those deep-core C routines that simply process
the data can be included as they stand. The data structure definitions
can just be copied and pasted. Functions (e.g. "Hourglass_Start") can be
re-written with the same interface so that anything calling them will not
need to be changed.
However, the assembler ALL needs to be re-written.
You can't simply copy a chunk of code from one file into another!

>It would probably be cheaper, faster, and produce a better result to
>rewrite the whole app from scratch.

Probably... but my point is that a well-written C program WILL be EASIER
to convert onto a new machine than ASM, simply because it is a more
portable language. Whether it would be better to convert or rewrite is
a completely different question.

>If you don't believe me, have a read of the case study on Framemaker in
>"Tog on Interface". This is a real-world example, from a real company,
>using C, and writing for real machines.

>Of course, if the app is designed to be as modular as possible, then
>perhaps this may not be the best approach. However, it is just as easy
>to make assembler modular as it is to make C modular -- most of the
>effort is in the design, not the coding. In fact, if I was writing
>assembler, I would tend to make it even *more* modular than C, just so
>that I could understand and maintain it. ;-)

Well the fact remains that BOTH C and assembler can be written in a
modular fashion: This is not a feature of language so much as design.
But I still find "converting" a C function into C is easier than converting
an Arm-code function into 68000 code.
For a start, the compiler takes care of things like function calls and
register allocation and stack allocation etc. for you: In assembler you
have to do all the work yourself, and EVERY function will need to be
re-written to handle a different procedure calling system/stack frame layout
register set differences, and stack handling st=ystem.

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

>But we shouldn't limit things to just two languages. BBC BASIC is very
>good for certain applications, too. And it's always fun to write your
>own language. ;-)

Yes. But can you combine BASIC C and Assembler together easily? I was merely
trying to point out that neither C nor assembler is "BETTER". They should be
used together, as tools to the end of writing a good application.

>Most people involved in software development in the world today do not
>really know what they are doing! Look at the size of, say Word for

I'll give you that. But does this make any one language better than any
other? Just because they write big slow programs in C does not mean that
C is a bad language: It is a bad design. I could make big slow apps in
assembler if I wanted to... it's easy!

>This is even easier to do in assembler. Seperate source, seperate
>data-spaces, and a defined interface between modules is what makes
>modular source code. 

This is good programming practice, and again has nothing to do with which
language is better. I personally like the way that in C I can say:
  for (i = 1; i < 100; i++)
and let the compiler handle the problems of coping with the stack and
register allocation and branch-distance-limits and stuff like that.

If I write the same thing in assembler, I have to do a lot more work.
It's not beneficial work, just something that takes time, and which I
find exceedingly tedious. And when I find coding tedious, I make
mistakes...

I'm quite happy to spend time and energy on hand-coded assembler for
any operation that really needs the speed (or some other benefit of
assembler like bunging it on vectors is easier than C functions...).
But when it comes down to the boring stuff like "select this icon, then
wait for 1/3rd of a second (multitasking of course) then deselect it,
and add one to all the members of this array" I much prefer to write
about 4 lines of C code than x assembler instructions. I don't
*need* speed. I'm not overly worried about the fact that the compiler
might add a few more instructions than I could hand-code (within
reason of course). What I want, then, is a convenient and fast way of
programming the tedium parts of my code, and C is (to me) just that.
-- 
_________________  "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)
Xref: sparky comp.sys.acorn:8843 comp.sys.acorn.tech:224