Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+129
product:
.LFB34:
.cfi_startproc
xor eax, eax
test esi, esi
je .L7
lea eax, [rsi-1]
mov edi, edi
add rax, 1
imul rax, rdi
.L7:
rep
ret
.cfi_endproc
Оптимизациия умножения через рекурсию. Сишный код:
inline unsigned long int product_0(const unsigned int a, const unsigned int b, const unsigned long int tmp)
{
if (b == 0) return tmp;
return product_0(a, b-1, tmp+a);
}
unsigned long int product(const unsigned int a, const unsigned int b)
{
return product_0(a, b, 0);
}
Запостил: 
j123123,
12 Октября 2013
Follow us!
> mov edi, edi
> add rax, 1
Что-то ему явно нечем было заняться ;)
Если хочешь общения - зарегай учетку, анальные гости здесь не в почете.
> нагенерировав при этом много лишнего говна.
кто-то написал на С "лишнего говна."
компилятор не богами писан. он всего лишь компилятор - а не говно-разгребатель. любой оптимизатор можно какой-нибудь глупой херней.
+1
Авторам компилятора зачет только за то, что он додуплил развернуть эту хвостовую срань в одну инструкцию умножения.
получается
Хотя можно было бы сделать
Но откуда они взялись, в коде ведь только esi и edi?
Товарищи, прошу прощенья, что не в тему. А как можно на асме поместить результат в переменную?
Схему Вашу сохраню, на всякий случай.
Ну в интелосинтаксисе так:
push variable
pop eax (или наоборот, это теперь уже не суть важно). Теперь буду делать так.
Спасибо!
:D
Клсссно на нем API дергать.
На мой взгляд Делфи неудобен. Попробуй другие языки. Из того, что я пробовал самый удобный руби.
не значит, что его нужно учить поверхностно. Халявы в изучении программирования
вообще нет. Ты очевидно имеешь именно поверхностные знания о Delphi,
поэтому судишь так. Между тем я тебя хорошо понимаю, я тоже раньше до
тошноты ненавидел паскальный синтаксис, меня бы никто не заставил
читать исходники. Но когда я ухлопал больше 2 лет на разработку проекта
на удобном и хваленом PureBasic и не получил ожидаемых результатов -
понял, что проиграл и изрядно свалял дурака, связавшись с этим языком и что он непригоден для разработки сколько-нибудь серьезных программ.
Пришлось срочно учить что-то более серьезное. Все остальные компиляторы
(сишный билдер, Autoit,purebasic и тп.) уже давно покрылись пылью, я их
даже не открываю.
Кем хваленым?) От него даже MS открестились) Pure C - язык для очень специфичных задач. Например мне он интересен чисто в академическом смысле, не думаю, что буду на нем писать. Плюсы излишне сложны - не то, что бы я не смог их выучить, просто я не вижу смысла убивать на них столько времени.
http://purebasic.com/
Ничего не путаешь?
-Хромой аналог Visual Basic на костялых.
Я тогда пропустил это мимо ушей. Зря, как оказалось.
И вообще, простота, как говорится, хуже гомосексуализма.
MS сами отказались от VB. Фактически Бейсик существует в .NET, но на самом деле это тот же шарп с синтаксисом бейсика. А бейсик мертв
Какая безвременная смерть. Всего-то сорок с лишним лет...
keep it short and simple!
sincerely yours, cap.
>xor esi,esi
Нет никакого смысла занулять регистры перед тем, как в них записывать какие-нибудь числа
А как занести в регистр указатель на строку??
Подобной фигней я в свое время занимался, когда захотел написать хелловорд на асмовставках под GNU/Linux
https://www.linux.org.ru/forum/development/8780935
Я скрыл все плюсы и минусы.
От меня теперь не ждите плюсов, буду благдарить на словах.
)
Да пребудет с тобой (асм + delphi - kegdan / (1024+1))
На ноль можно делить. Получится +∞ или -∞ в зависимости от знака ;)
Нельзя делить только 0 на 0.
Кегдан, ты не тролль, а просто детонатор флуда. Наказать онально, мой вердикт.
А вот в полях Галуа, насколько помню, делить на ноль как раз таки нельзя...
Используйте питательную смесь NaN.
Смесь NaN. И Ваша программа не падает!
P.S. А производители жёстких дисков-то не обманывают нас, когда умножают на 1000.
При десятибитном байте - да.
Ня! ^_^
Не поможет.
так сойдет?
Если оба числа переменные, он еще вставит проверку на ноль, так что неидеально
и скорость
Разницы на своем процессоре Intel Core2 Quad Q9300 я не заметил
А может быть совет про то, что стоит юзать полные инструкции вместо сокращенных inc, lodsb, jcxz и т.п. уже устарел, и они выполняются с той же скоростью...
P.S. А вот по поводу длины команд есть стопроцентная инфа: мельчить нельзя. Декодеры справляются только с фиксированным числом команд в блоке (что-то вроде 6 команд на 16 байт, и вроде были еще и ограничения на тип этих команд), и если не соблюдать это соотношение, то команды будут декодироваться медленнее из-за простоя декодеров.
Нужно по возможности брать крупные команды?
Правила про крупные команды я не нашел, наверное моя инфа устарела, или вообще была брехней... Но правил по подстройке кода под декодеры там куча (страница 147 и ниже).
Чук и ГекINC and DEC
instructions should be replaced with ADD or SUB instructions, because ADD and
SUB overwrite all flags, whereas INC and DEC do not, therefore creating false
dependencies on earlier instructions that set the flags.