Re: Assembler Language

[Al Hudson <nospam [at] york.ac.uk>]

On Fri, 25 Feb 2000, Jim Jackson wrote:

> > > Do you mean making system calls in assembly? Or are you talking
> > The O/S calls. I presume that the BIOS calls are the same for DOS 
> > and Linux. (Is that a false presumtion?)
> 
> Not sure about the BIOS calls - don't think the're generally available,
> except under kernel gynmastics. Anyone know for certain?

To be honest, you shouldn't be making even OS calls, let alone BIOS calls.
Firstly, there is NO reason to make calls to the BIOS - Linux ditches a
lot of BIOS calls for a number of reasons, i) they tend to be buggy, esp.
with more technical operations, ii) they're not reliable across platforms
and or motherboards.. leave the BIOS well alone.

OS calls - no, you should really be going through libc anyway. The reason
being, you don't want to have to keep updating your code every time the
kernel breaks or something. 

You might want to ask yourself why you want to go for assembly. The
assembly option is generally not a valid one. You may say to yourself that
you need that level of control and speed, and I wouldn't agree with you.
You lose control by programming in assembler - assembly programs gather
cruft far more easily than in higher level languages. Also, generally, the
speed increase is minimal, and often it actaully slows down a program to
re-code it in assembly language. gcc will perform some non-trivial
optimisations to your program, things you won't even dream about doing in
raw assembly, and if you ask most people (including myself) optimisation
should be done at compile and run time, not whilst programming. 

You lose a lot of advantages by programming in assembly. I would suggest
that if you want to try prorgamming assembly, try in-line first, with
specific C code. Speed critical regions, where the operation may be pruned
by hand to give a performance increase (typically, pixel plotting, BitBlt,
etc. in graphics demos) may be written in assembly and interfaced to C.
But still, even simple optimisations gcc will provide (such as
unroll_all_loops) will be beyond the means of an assembly programmer -
you'll have to think hard what optimisations can be made, where, and how
they will impact the program. I have to say, if a routine can be speeded
up by translating from C to ASM, it's generally because the C code was
flabby - judicious use of inline, register and  other such keywords will
improve performance no end. If you like, have a look at the assembly gcc
generates from a simple C program. I don't think you'll find that you can
do a great deal better, if at all.

Cheers,

Alex.


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.