Re: Assembler versus ANSI C

From: Thomas Pornin (pornin_at_nerim.net)
Date: 07/31/03 

Date: Thu, 31 Jul 2003 12:34:50 +0000 (UTC)

According to George Joseph <george.joseph@student.up.ac.za>:
> So must I write the PKC algos in C or assembler?

You must write them in whatever language which will allow you to
produce a _correct_ implementation (yielding the expected result and
not crashing when submitted a flawed input) with a cpu/power/whatever
consumption and a development time which are adequate for your needs.

If you are after correctness and a short development time, you should
use an existing "big integer" library, which will handle the grunt
work of modular exponentiation and other similar operations. Chances
are that such a library will include a fully hand-optimized assembly
implementation for the most often encountered architecture (the PC-x86),
with very good performance.

If you do wish to implement your own set of big integer functions,
then the choice between C and assembly depends upon the target
architecture, and your exact needs (development speed, computation
speed, maintainability of the implementation, provable correctness...).
What can be said is the following:

-- C will improve maintainability (it is possible and even easy to
write unreadable C code, but it is easier to write readable C code than
readable assembly code -- if you can write readable assembly, you could
have written readable C with less effort).

-- On RISC architectures (Sparc, Alpha, PowerPC,...), careful C code can
achieve almost the same efficiency than hand-optimized assembly. On those
platforms, C is the way to go (with regards to assembly).

-- On the PC (Intel x86 or compatible), the instruction set is too weird
for the C compiler to perform a really good job, so you can usually get
much better performance with assembly (especially if you fiddle with the
exotic units such as MMX or SSE); you might expect up to three times the
speed by using assembly. But it is not an easy task, and in a deployed
application, it is rarely worth the effort.

-- Assembly is not portable. The most optimized C implementations will
not be portable either (for instance, they will be tuned for some
specific integer length matching the register length on the target
architecture), but it is possible to write a decent and highly portable
big integer library in ANSI C. Performance will not be the highest
possible, but will still be more than enough for most applications.

        --Thomas Pornin

Relevant Pages

  • Re: Assembler syntax/instructions for different architecures and assemblers?
    ... Assembler, Netwide Assembler, TASM, etc.). ... written for ARM architecture with NASM? ... don't believe there is (nasm only really targeting x86 and variants). ...
    (alt.lang.asm)
  • Re: Moving from 8051 to AVR
    ... If you have sigificant amount of code written in assembler, ... you are locked into that architecture. ... porting it to an AVR was an even less smart thing to do. ... I would agree but the problem is you start with a nice small 8 bit MCU ...
    (comp.arch.embedded)
  • Re: Assembler syntax/instructions for different architecures and assemblers?
    ... The assembly code syntax is different for different assemblers (Gnu ... Assembler, Netwide Assembler, TASM, etc.). ... written for ARM architecture with NASM? ...
    (alt.lang.asm)
  • Re: Question on ProDOS SmartPort drive remapping
    ... assembler which generated two bytes of executable code: ... address on entry is stored in register 14. ... It was unavoidable for an architecture that introduced so many ... registers, long base registers with short instruction displacements, ...
    (comp.sys.apple2)
  • Re: GNU toolchain + ARM options
    ... My best guess at what is happening is that when you compile with no options ... the code generated by GCC itself is for ARMv4 or somesuch. ... assembler is allowing any version of the architecture. ...
    (comp.sys.arm)