[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES sources for FreeMiNT 1.16.3



Paul Wratt wrote:
As for the ASM stuff, I thing Coldfire dev's have raised this issue
regarding EmuTOS and is amount of ASM, but I would say it is more
because current AS use some instructions by default that "break" on
Coldfire.

I don't know what "current AS" is. If it is the GNU assembler, it uses the instructions written in the program.

Any hand-written assembly code targets one CPU. Such code can't work on incompatible CPUs, such as ColdFire. It can't even use the new features of compatible processors. So (it is not new) direct usage of assembly language is a portability killer.

The C language can be extremely portable if some care is taken. Most of the time, if the algorithms are good, the generated assembly code will be very efficient with a good compiler and all optimizations options turned on.

I do believe the C language can be very efficient for any task, including drivers.

However, there are some rare areas where the C will never produce efficient assembly.
- assembler instructions with no equivalent in C: rol, movep...
- bit manipulation
- ...

Drawing on a screen with bitplanes like the ST one is a complicated task. It requires a lot of bit manipulation, it is often difficult to express such operations in C, that leads to inefficient generated code. Such routines (present in the VDI) will certainly get better performance when written in assembly.

In any case:
- A reference implementation must be written in C. When the software has to be ported to another CPU, this implementation can be used, and it will work fine. - Performance issues has to be measured. Not guessed. There are tools for that, named profilers. Sometimes surprises happens. Slowdowns often come from unoptimal small parts of code being called extremely often. These parts have to be optimized. First in C. If it is not enough, the smallest possible part has to be manually optimized in assembly, and the benefit has to be measured again with the profiler.

I remember that long ago, when I still was in the wrong optic "do everything in assembler", I read an article about ID Software. They said that in their games (Doom, etc...) there was only 1 or 2 small routines written in assembly, for drawing a line or something like this. The main part of the code is in C. And the result is fast and portable.
I really often think to this.

About the ColdFire, every "C only" application I have recompiled have worked immediately. And fast. Applications using assembly routines will require manual porting, this will take more or less time.

So writing big parts of code in assembly is a design choice for speed (if it is well done) versus portability.

--
Vincent Rivière