使用C语言，要不要了解汇编？

OwnWaterloo

是用你的代码。不过不要cltd，把edx和eax一起返回来。
需要双倍字长的结果。
yulihua49 发表于 2011-11-08 16:34

不要cltd就改为unsigned。
是因为你原帖提到imul，所以我才用的signed类型。

OwnWaterloo

    再给你个128位/64位=64位 余64位的汇编，看你用C怎么玩，不慢几十倍有鬼。
在64位机上，long是64位的。
真正的指令就是8-13行。
yulihua49 发表于 2011-11-08 16:55

我这里没有x64，所以无法验证你的说法。
但根据以往的经验，你的话的可信度并不怎样。 需要我举例吗？

AD8018

再给你个128位/64位=64位 余64位的汇编，看你用C怎么玩，不慢几十倍有鬼。
在64位机上，long是6 ...

unsigned long diva(unsigned long a[2],unsigned long c,unsigned long *rem);
yulihua49 发表于 2011-11-08 16:55

C直接调用 diva 就是了。
diva的实现交给编译器，编译器用C还是用asm, 随它的便。
话说，这个diva，本来就是编译器使用的库的代码。

这种例子太多、太多。。。

因为这本身就是编译器帮你做的事情，
所以 ---
这个汇编能写的比C好的例子，
并非证明了 “使用C，要了解汇编”，
而是恰恰相反。

yulihua49

我这里没有x64，所以无法验证你的说法。
但根据以往的经验，你的话的可信度并不怎样。 需要我举例吗？
OwnWaterloo 发表于 2011-11-09 20:15

何以如此评价？我说话可是很谨慎的呀，哪些不对，请明示。

你理解我的程序了吗？那是双字长的除法，并非编译器的代码。
它是为多字长除的准备。

你可以在32位上用C做一个，答案是能够实现，但速度。。。。。。。。

yulihua49

C直接调用 diva 就是了。
diva的实现交给编译器，编译器用C还是用asm, 随它的便。
话说，这个diva，本 ...
AD8018 发表于 2011-11-10 18:03

    哪个编译器给你双字除法了？
在64位编译器上，只提供了64bit/64bit商64bit，哪有128bit的？你告诉我，不胜感激。

你们（包括楼上的那一位）都没看明白就议论，坏习惯。
8行和10行构建了双字被除数，哪个编译器如此？diva也是这里的函数，系统哪有？

yulihua49

不要cltd就改为unsigned。
是因为你原帖提到imul，所以我才用的signed类型。
OwnWaterloo 发表于 2011-11-09 20:13

   应该是用mul。我有点忘了哪个是unsigned的，好多年前的事了。

cltd是清方向，无所谓的。关键是不能清edx，那是积的高位，我们需要它。

yulihua49

C直接调用 diva 就是了。
diva的实现交给编译器，编译器用C还是用asm, 随它的便。
话说，这个diva，本 ...
AD8018 发表于 2011-11-10 18:03

    带进位循环移位，加减法的进位和溢出判断，汇编就是一条指令，C就玩大了。
测试并复位，测试并置位，原子操作。C呢？得mutex_lock了吧？

狗蛋

哦，汇编啊……

我举个例子，保证让那些想用C玩的闭嘴：

做图像色彩空间转换，可以通过C写，但也可以用MMX并行计算（SIMD并行）。

但是MMX并行的话，只能计算整形数字，并且数据溢出会被自动截断，不会报错。
好在图像色彩上面有些误差，人眼并不能看出来。所以我们大可不理这点，并利用浮点数的一些特性（如预先对齐）用整形做近似计算——哪个c编译器敢把我们的算法用优化后的近似算法替换掉?

再者，CPU从普通状态到MMX方式之间的切换是需要消耗不少时钟周期的，预取队列里的指令也会作废。这个代价是很大的。


于是，了解基本汇编的，可以探测CPU类型，然后下一条指令让CPU切换到MMX或SSE或3D now状态，以至少8倍（MMX）的速度完成工作。

用C的话，我敢保证没有任何编译器敢自动替你优化个基于MMX的近似算法；甚至都很难找到什么编译器敢支持自动切换到MMX状态。


再如，GPU计算，写GPU SDK的老兄，恐怕不光要了解x86汇编，连机器码恐怕都得拿来用上一用了。


不过，另一方面，这种东西都已经被封装到图形库了。不是做特定领域的底层支持的程序员，显然不需要了解MMX，更不需要了解GPU指令。

yulihua49

哦，汇编啊……

我举个例子，保证让那些想用C玩的闭嘴：

做图像色彩空间转换，可以通过C写，但也可以 ...
狗蛋 发表于 2011-11-11 13:30

    对，这就是我的观点，有些功能C实现效率太低。你可以写一个汇编函数入到库里，其他人引用这个模块就可以了。
这就回到楼主的题目，玩C的可以不懂汇编，但懂汇编的可以做的工作，是不能用 不懂汇编的人 的工作 取代的。

上边的双字乘除，如果是32比特，还可以用long long过渡一下，现在就是这么办的，效率低一点而已。
如果是64比特的整型数组对象的大乘除，除了汇编，没别的办法（如果用32位组接，失去了64位的意义）。当然，不是整个算法，仅仅是核心算法mula、diva用asm实现。上层还是用C调用这两个核心函数。
现在的RSA算法，就是一些长乘除的算法，在ssl里都是按BYTE计算的，我认为太慢，所以写了按32比特整数计算，为了可移植性，没用汇编。
如果要更快，用到64比特，就必须汇编，可移植性就。。。。。。。。

OwnWaterloo

回复 105# yulihua49

我并不是想反驳"关键代码汇编比C快"，"有用汇编的必要"。

但同时请注意，这并不是需要了解汇编的理由。
看104楼 AD8018 的回复。

对楼上提到mmx/sse的同学， 可以去看看mscrt里的memcpy是怎么实现的。
又有多少程序员，多少代码，是使用sse而不是直接使用memcpy的。


我想反驳的恰好就是你的"不谨慎" —— 比如， 你还没回复我们O(log2(n))的二叉树排序算法是怎么回事呢。

    性能。
比如大数乘法。32bit × 32bit ＝ 64比特，汇编一条指令够了：
eax × edx ＝ edx（高32bit） ，eax( 低32bit）
imul
C呢？也行，好多指令啊，慢十几倍。
yulihua49 发表于 2011-05-29 21:22

自己看看楼下的回复里， 是不是eax*edx， 是不是 (i)mul。  好多指令是哪来的， 慢十几倍从何说起？
后续回复更是夸张到"不慢几十倍有鬼"。
啧啧……