Re: Asm or C (was: Re: New Web browser for MiNT)

[Johan Klockars <rand@cd.chalmers.se>]

> > > Well, I disagree. Having an example of myself here, I can say, that
> > > assembler people probably don't code in asm just because it is considered
> > > cool. They usually prefer assembler for its advantages over C or another
> > > high level language. 

I guess this thread doesn't really belong on this mailing list, but I still
want to add a few things.
First I guess I should say that I've written many thousands of lines of
assembly (including lots of graphics code and a real time kernel) and
tens of thousands of lines of C code for the Atari machines.

> Yes, right. Slight speed gain that breaks portability is quite bad usage
> of assembler. But if you have a portable C program and a non-portable
> assembly based equivalent is say 5-6 times faster on a particular machine

5-6 times faster?
I can't see that happening for _anything_, assuming a good C compiler.
Even a factor of two is not common, IME.

> (Atari), I am totally for the assembler. At the other hand, when things go
> to Atari and MiNT, a GEM based browser may be written in assembler quite
> safely, because in current circumstances a GEM application is not portable

As has been said, it shouldn't be overly difficult to convert the AES/VDI
stuff to some other API.

> > > coding the same in C is a pain for you. Though I haven't been ever on the
> > > scene, I think that scene programming experience is useful here, because
> > > you also know most of optimal structures for data processing by heart.
>
> > This is definitely true. Naturally I'm a great friend of scene stuff and

Demo programmers knowing the 'optimal structures for data processing'?
In what reality?

I'm not picking on the demo programmers, but I can assure you that they
would never have any need for most of the algorithms/structures you'd find
in a normal textbook on such things.

> You're definitely right. But it does not make sense to force people to
> write stuff in a language unknown for them just because C exists. If a

Of course not, but the probability of finding enough people to finish
any kind of major program in 100% assembly isn't very high.

> program is planned to work on a particular machine with a particular
> operating system (Atari/m68k/MiNT/GEM) and it is intented to be optimal
> for such a configuration and nothing else, I don;'t think writing it
> totally in assembler would be a bad idea. Even if written in C, it would

Apart from the rather large probability that it would never be finished...

> be practically not portable to anywhere, but slow/big/unefficient for

Everything but a few input/output functions should be relatively portable.
While C code will of course produce a larger executable than assembly, the
difference decreases when the program is large enough that the library
code is no longer a significant part.
With a few small assembly routines you wouldn't notice much slowness.

> For larger programs I noticed that the time of development for asm
> programs is really much longer than for C programs. But I also noticed,
> that the most of this time is spent on optimization, which part is mostly
> missing for C development.

Something like GCC would not be much worse for most optimizing tasks and
it would optimize _all_ the code rather than just a few select routines.
(At least I hope noone would optimize non-critical assembly routines.)

> Yes. There are two points of view. From one hand, if you want to deal with
> complex data structures, a high level language may be easier for you to
> code ideas. At the other hand, no compiler has an ability to do miracles
> and a code based on an abstract data structure won't be fast. Even worse,

Compilers have no more problems with complicated data structures than with
simple ones. If you mean that you would use a less complicated scheme in
assembly, there's nothing stopping you from doing the same in C.

> problem to this (compilers usually do the same, but according to your own
> words, they can't optimize optimally, so they don't do it perfectly),

No human does either, for anything except very simple things.

> assembler programming gets easy.

I'd like to see you write the compiler (compiling a lazy functional language
into m68k assembly) I wrote recently in assembly instead of C...  ;-)
(C++ would have been much better, not to mention something like Standard ML.)

> > > - assembler programs are short. A simple GEM application (cleanly written)
> > >   takes few kilobytes including Devpac AES & VDI data structures.

There's really no need for the C program to be much larger. Without extra
options etc you would usually get a lot of standard library stuff etc
linked, but that's not really necessary. Anyway, once the program gets
larger the overhead percentage falls.

> > > - assembler programs are fast. If you have an intensive task which uses
...
> > I am quite aware of these points. The second point was slightly vague,
> > however: why on earth would a C compiler only use 2 registers???
> 
> I always wondered the same. A register is an important resource, and it

Have you ever tried a C compiler?

I have never used one on the Atari machines that didn't use all the
available registers. GCC, Lattice C and TurboC/PureC certainly do.

Before you complain about C compilers, try GCC with something like:
  -S -O2 -fomit-frame-pointer
TurboC/PureC is not a good example of what C compilers can do.

> seems you're not able to use this resource in a big extent while
> programming in C on Atari. That's very bad.

If it was true, but it most definitely isn't.

> > > Also it is much easier (at least for me) to develop programs written
> > > totally in assembler instead of mixed C & asm. Just because interfacing
> > > the code from C to asm is pure pain and wastes the CPU time (you have to
> > > push variables to the stack, then call teh assembler module with jsr, then

If you find it so difficult to push a few values on the stack, why don't
you write a macro for it?

If the function in question does anything useful, the few cycles spent
pushing/popping parameters should not hurt much. In any case, both
TurboC/PureC and Lattice C can easily use register parameters if you want.

> See above, this is a question of data structures you are used to think of.

I'd say it's a question of what kind of software you write.

> If you reduce abstraction to reality, assembler gets easy. If one is used

Try writing that compiler.  ;-)

> deadly useful anymore. And the price you have to pay for the abstraction
> suddenly starts to seem too high.

There's no price for the abstraction. The compiler knows exactly how
things look in memory and if you're talking about stuff like class member
functions in C++, you can have those inlined.

> > Another point that should be noticed is that it makes a lot of sense
> > teaching C in schools. Teaching just m68k assembler would be ridiculous.

I've had experience with that, unfortunately.
People without previous programming experience of some kind generally
had _very_ large problems getting anything reasonably complex working.

> I didn't say that teaching C in schools is a bad thing. I only said that
> it is one of reasons why it seems easier. Just because people usually get

The main problem with assembly, as I see it, is that there are so many
things you must keep track of yourself all the time that the compiler
would take care of if you used a high level language.
There's also a lot more code to write and no good way to structure it.

I would not recommend C as a first programming language either, by the way.
It's far too easy to write things that will compile but cause major problems.
At the University I went to, the first language encountered by the
computer science and engineering students was Standard ML. I don't really
like it myself, but functional languages like that are IMHO much better
for beginners.

Perhaps I should release CLFL (compiled lazy (or C-like) functional language,
the one I mentioned above) so that the Atari people can see the light.  ;-)
Unfortunately, the current implementation of CLFL is untyped and has no
garbage collection, so it's still possible to run into serious trouble.  :-(

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)