On Apr 28, 9:34 pm, Mathias Gaunard <loufo...@[EMAIL PROTECTED]
> wrote:
> On 27 avr, 15:29, Le Chaud Lapin <jaibudu...@[EMAIL PROTECTED]
> wrote:
>
> > I tried:
>
> > #define MULTIPLY(A, B, lower_word, upper_word)\
> > {\
> > _asm mov eax, A;\
> > _asm mul B;\
> > _asm mov upper_word, edx;\
> > _asm mov lower_word, eax;\
>
> > }
>
> What's the point of using macros? Use functions
Functions would make things worse (slower). They would add prolog and
epilog code. At the very least, a CALL/RET pair would have to be
executed using straight C++ code. Trickery to get rid of the prolog/
epilog code would not help, nor would making the function inline,
because the problem is the C++ code itself. The part that does the
mathematical operations is too slow, and it is logically impossible
for the programmer to do anything about it, in C++.
For example, in a Big Integer class, on say, a 32-bit machine, for
optimal speed, one would necessarily have to multiply two 32-bit
numbers, A * B to yield a 64-bit result. It is impossible to achieve
the efficiency of a hardware-based 32-bit * 32-bit multipication using
****table C++ code.
Big integers are used as the basis of the RSA and DSA ciphers, and
asymmetric crytopsystems in general, for example, and such asymmetric
ciphers are used for packet signing in communications. Because
asymmetric crypto is often the bottleneck in secure communications,
their execution speed is paramount. It would be hard to ignore a 3x or
4x increase in speed by switching to assembly versus C++.
If the reasons for adding __asm to C++ were listed in order of
im****tance, I'd say speed up of critical operations would be in the
top 10. :)
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
