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

[Kristoffer Lawson <setok@fishpool.com>]

On Mon, 30 Mar 1998, Konrad Kokoszkiewicz wrote:

> (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
> by definition, whatever language is used.

Well like I've tried to point out, with good program structure the GEM
routines might not be too difficult to replace with X stuff. After all,
all the networking and parsin is pretty standard stuff that can easily
be ported to anything. If the browser is actually good, I don't see this
as being a terribly bad idea.
> 
> 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

OK, this is something I sortof agree with. I can't really force
programmers to learn C at least when they're creating free software.
That's their own business.

> sure. When things come to a browser, we already have one written in a
> "portable" language for more than one operating system and more than one
> TCP stack. Well, CAB is compact and lightspeed when compared to a
> Netscape, but I believe a browser may be even more compact and
> efficient, and this is the point.

Yeah, but the sources for cab aren't available for free so porting it to
UNIX is not really an option..
> 
> You may consider this horrible, but I wrote some very small utilities
> (like fastboot.prg) for MiNT and I wrote them in assembler. Of course, the

fastboost and stuff like that are OK in assembler. They're not terribly
large programs and very atari-specific (porting doesn't make any sense at
all). There are applications which asm is clearly suitable for.


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

Yeah, because we trust that to be done by the compiler ;-)
> 
> 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,

No the point is that whoever may have coded the datastructures has been
trusted to optimize to their capabilities. I am no longer interested in
how the details are implemented.. Yes, you would probably get more speed
with pure assembler, but my real point is it's a helluva lot more
difficult than having a more abstract view on what's happening. That's
where high-level languages come in.

> structures (bad example: my friend has once written a program in Pascal,
> that used a dynamical table of files of records of something-i-forgot or
> something terrible like this in order to access 9 data files on the disk;
> no wonder why the program was terribly slow even on his pentium 266), you
> loose an ability to write an optimal program for any computer.

No, then you are only interested in optimizing the algorithm (a more
theoretical, mathematical entity) and not optimizing the amount of moves
done. This is where the importance of high-level programming languages
come in. Compilers are nowadays fairly good at optimizing low-level stuff
so I'm not worried about that. About your friend's example, I don't really
understand how it can be so slow.. I'd say either the coder or compiler is
to blame (Pascal - bleugh). I seldom notice good C code being too slow for
something I'm doing.

> > > - assembler programs are short. A simple GEM application (cleanly written)
> > >   takes few kilobytes including Devpac AES & VDI data structures.
> > > - assembler programs are fast. If you have an intensive task which uses
> > >   several variables and pointers in a loop, the assembler gives you an
> > >   easy possibility to access 15 32-bit registers. If you put all your 
> > >   variables there, your code will be lightspeed when compared wit a C
> > >   compiled equivalent with 2 accessible registers and the rest of
> > >   variables stored in the memory.
> > 
> > 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
> seems you're not able to use this resource in a big extent while
> programming in C on Atari. That's very bad.

Well in C, obviously you don't want to know about the registers and stuff.
But do you mean that the compiler doesn't compile code optimally to use
all registers? Do you use proper optimization otions (-O9 or whatever)?
I'd be quite surprised if this was so - it means gcc for m68k would need a
bit of work ;-)

> Well, even some old processors (e.g. Intel) were quite hard to program in
> assembler. But really, that has nothing to do with a level of difficulty
> when you're using m68k...

Yeah, m68k is fairly simple but the C approach is even more so. Actually
the fun thing about C is that it actually resembles assembler in some
ways, but just has a more high-level approach to it. This is quite
different than the Lisp approach (f.ex) which is very high-level.


         -     ---------- = = ---------//--+
         |    /     Kristoffer Lawson      |    www.fishpool.com
         +-> |    setok@fishpool.com       |  - - --+
             |-- Fishpool Creations Ltd - /         |
             +-------- = - - - = ---------      /~setok/