S_T_A_S
> "Только нужно знать больше информации о входных числах"
> "Вот, например, числа складывают, а с форматом до сих пор не определились =)"

Как я понимаю, числа любые unsigned B > 0, A >= B. Поэтому алгоритм может завершиться и за 1-2 шага и за много шагов, и сложений может потребоваться от одного до фиг знает сколько. А по сему конкретных мыслей по оптимизации алгоритма у меня пока нет, а вот некоторый выигрыш по скорости вычислений по алгоритму сложения получить можно. Это просто пример того, какой "фигней" мы маемся по ссылочке, приведенной S_T_A_S_, когда замена 3-х инструкций на 10 может привести к выигрушу по скорости на десятки процентов. В данном случае, идея - в разворачивании внешнего цикла, которая заодно позволяет иcключить лишние регистровые пересылки и получить длинный, но симпатичный и быстрый код.

	mov ecx,B    
	mov eax,A

	sub ecx,eax  ;это подготовка для цикла @@rep
@@rep:
	add ecx,eax
@@eax1:
	sub eax, ecx
	ja @@eax1
	             ;дальше идут 3 одинаковых цикла сложения с чередованием роли регистров eax и ecx
	jz @@end_c
	add eax,ecx  ;определяем остаток
@@ecx1:
	sub ecx,eax
	ja @@ecx1

	jz  @@end_a
	add ecx,eax
@@eax2:
	sub eax, ecx
	ja @@eax2

	jz @@end_c
	add eax,ecx
@@ecx2:
	sub ecx,eax
	ja @@ecx2
	jnz @@rep

@@end_a:
	mov ecx,eax
@@end_c:
	mov R,ecx

На P4 получается заметный выигрыш по скорости - проверил на нескольких комбинациях чисел с разным числом итераций и короткими и длинными циклами сложения.
Но вообще-то, этот пример приведен просто для развлечения. Настоящая оптимизация, видимо зарыта где-то в комбинации двоичного уравновешивания и сложений, поскольку прибавлять сотню раз единицу, чтобы получить 100, выглядит как-то не изящно.

PS: А основная проблема как выбрать или угадать, что будет для данных eax и ecx быстрее без лишних сравнений и и условных переходов (о варианте dmit10 с несколькими условиями на каждом шаге мне чего-то даже думать страшно). По-видимому в любом случае будут промахи и придется чем-то жертвовать. Кроме второго приближения с использованием удвоенного значения ecx пока ничего не вижу, да и то смутно.

итак, проделано еще немного копаний в сторону истиньі )

как и ожидалось, при большой разнице между числами результатьі не очень утешительньіе
посему бьіл создан симбиоз алгоритма S_T_A_S и Кнута )
просто добавилась проверка на четность и соответсвенньій здвиг

итого, все тот же GetTickCount (поправка на 210 милисекунд - само время вьіполнения пустого цикла),
все тот же Cel850

..числа...........S_T_A_S..........S_T_A_S + Knuth
.........................................
.777 - 629.........1292..............1562
...................1332..............1612
...................1321..............1633
...................1332..............1632
.........................................
..777 - 6..........6329..............1703
...................6499..............1692
...................6379..............1693
...................6389..............1672
.........................................
вот так вот, проигрьівая при небольшой разнице, имеем значительньій прирост при большой..

истинна где-то рядом

leo
результьі на скорую руку

З,І,

leo
777 - 6
6229
6669
6730
6340

777 - 629
1022
1012
1002
1012

пока біьстрее всех ) но жаль не всегда )
уже зреет коварньій план по написанию симбиоза leo + Knuth )

Вот ссылочка в тему: http://athena.vvsu.ru/docs/science/crypt/crypto/handbook/chap14.pdf Раздел 14.4 Binary gcd algorithm
Есть у меня ощущение, что инструкция PSADBW очень хорошо в этом алгоритме смотрится.