Первые и последующие шаги в ассемблере x86/x64

[Yadryara]

Dmitriy40 в сообщении #1626603 писал(а):

Надо было сразу сказать.

Ну так я был уверен, что Вы проверяете все эти советы. И полагал, что это именно я что-то делаю не так. Теперь иногда печатает, смотря откуда вызывать. Буду разбираться. И отладчик скачал, спасибо. Голова кругом идёт, очень много всего нового.

[Dmitriy40]

Yadryara в сообщении #1626617 писал(а):

очень много всего нового

К сожалению да. Могу только порадовать что это в сотню раз проще матана или квантовой механики (вот их бы я поизучал, о да ...).
Многое что говорю знать не так уж и необходимо (те же отступления в историю вопроса или "как принято" или даже что увидит процессор из вашего кода), но считаю без этого не будет понимания причин и внутренней логики тех или иных реализованных решений (например почему EBP обычно нельзя использовать для вычислений).

Задавайте вопросы что непонятно (особенно если не нашли ответ за 5 минут поиска гуглом/яндексом или не поняли его).

-- 20.01.2024, 21:14 --

Dmitriy40 в сообщении #1626603 писал(а):

При этом первая строка в окне кода с call GetTickCount должна подсвечиваться серым фоном, а левее синяя стрелка

У меня отладчик был от 2018г, обновил на всякий случай на последний, а там оказалось что предыдущие настройки не подхватились и до этой команды не доходит, тормозится ещё где-то внутри винды, даже не стал разбираться где - пошёл в Параметры - Параметры - вкладка События - снял галку Системной точке останова и проверил что стоит следующая Точке входа - и перезапустил отладчик (т.к. галка помечена звёздочкой). Перезагрузил файл и всё сработало правильно.
Цвета немного поменялись, но красный остался.

[Yadryara]

Dmitriy40 в сообщении #1626621 писал(а):

Могу только порадовать что это в сотню раз проще матана

Матан он разный бывает. Кстати, по поводу той короткой формулы для трибоначчи. Я же про неё сказал не для того, чтобы в оффтоп надолго уйти. А чтоб народ посмотрел кто автор.

[Yadryara]

Dmitriy40 в сообщении #1626453 писал(а):

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

Заменил

cmp      ESI, max_prime/2

на

lea     EAX,[ESI*2]           
mul     EAX
cmp     EAX,ECX 

Dmitriy40 в сообщении #1626453 писал(а):

Кстати интересный результат будет по времени. Думаю оптимизация ухудшит скорость!

Ускорилась в 17 раз ! Это для $\pi(10^7)$. 8.6 секунд против 152-x секунд.

[Dmitriy40]

Yadryara
Прекрасное решение.
А "забыв" добавить 1 к числу Вы красиво обошли одну из проблем.

А теперь обещанная засада.
Я ведь говорил проверять лучше? Говорил, точно помню.
Смотрите, вот правильный вывод (до Ваших изменений):

Используется синтаксис Text

C:\>prog3.exe 1000000 4293001441 4293001469 4294967279 4294967289 4294967291 4294967293
78498 primes up to 1000000
4293001441
4293001469 is prime
4294967279 is prime
4294967289
4294967291 is prime
4294967293
time: 10.063s

А вот после внесения изменений:

Используется синтаксис Text

C:\>prog3.exe 1000000 4293001441 4293001469 4294967279 4294967289 4294967291 4294967293
78498 primes up to 1000000
4293001441
4293001469 is prime

После чего программа вылетела в винду по ошибке.

Я говорил оставлять все работающие условия на местах и лишь добавлять свои? Говорил.
Как думаете, что будет в EAX после команды mul если ESI равен 0x7FFF (это последний элемент таблицы primes) и если 0x8000 (это прямо за таблицей, куда лазить уже нельзя!)? И сработает ли тогда не показанный jnc после cmp?

[Yadryara]

Dmitriy40 в сообщении #1626687 писал(а):

А "забыв" добавить 1 к числу Вы красиво обошли одну из проблем.

Да, теперь я более зрячий. Так что несколько вариантов попробовал.

Dmitriy40 в сообщении #1626687 писал(а):

Я говорил оставлять все работающие условия на местах и лишь добавлять свои? Говорил.

"Джентльмены удачи", да

То бишь не определяется простота только двух самых огромных чисел?

Надо аккуратнее с EAX ?

[Dmitriy40]

Yadryara в сообщении #1626689 писал(а):

То бишь не определяется простота только двух самых огромных чисел?

Далеко не только их. Просто это всё "интересные" числа (посмотрите на их факторизацию, тех что не простые, и список простых около конца таблицы с обеих сторон), специально подобранные. А так то вылет по ошибке будет думаю для всех нечётных простых чисел больше 4294705156 (посмотрите на корень из него, это тоже подсказка). Проблемы с корректным завершением циклов (а иногда и с запуском) - довольно обычное дело. Потому и говорил что их обязательно надо включать в тесты.

Заодно дам ещё совет по отладчику: кроме F7/F8 и F4 ещё полезна F9 - просто запустить программу. По любой ошибке она вылетит, но не молча в винду, а в отладчик и он покажет какая команда вызвала ошибку и главное какие при этом были регистры. У меня один из запусков с вылетом по ошибке показал что ESI=0x13871 (примерно, уже не помню точное значение, да оно и не важно), т.е. сильно больше размера таблицы primes, что как бы сразу намекает на причину вылета. А уж почему он такой стал - см. далее.

Yadryara в сообщении #1626689 писал(а):

Надо аккуратнее с EAX ?

Не совсем. Подумайте над вопросом:

Dmitriy40 в сообщении #1626687 писал(а):

Как думаете, что будет в EAX после команды mul если ESI равен 0x7FFF (это последний элемент таблицы primes) и если 0x8000 (это прямо за таблицей, куда лазить уже нельзя!)? И сработает ли тогда не показанный jnc после cmp?

Прогоните в голове куда пойдёт управление при ESI=0x7FFF (это составное число с 0 в primes и проверяемое например ECX=0xFFFFFFFD на него не делится). Я думаю снова придёт к inc ESI и вашей проверке. Что будет дальше?

[Yadryara]

Dmitriy40 в сообщении #1626691 писал(а):

А так то вылет по ошибке будет думаю для всех нечётных чисел больше 4294705156

Ошибка появляется ещё раньше. При $2^{31}$. Если взять $2^{31}-1$, то работает вроде нормально. То есть запуск

>prog3.exe 2147483648

уже даёт 0 простых чисел. Может это со знаковостью связано...

В Вашем варианте программы то же самое, кстати.

[Dmitriy40]

Yadryara
Прекрасно! Как же радует когда ученик находит ошибки у учителя. (Надеюсь не обидитесь.) Тем более не преднамеренные.
Да, это тоже моя ошибка, не нарочно, команда jle в основном файле именно что знаковая (ну вот не помню я всех имён команд переходов, написал по смыслу и ошибся). А запускать на много часов счёт до 2млрд поленился, тут уже я лоханулся с тестами. Так что до гуру мне ещё далеко. И кстати да, вот эти точки прохода через смену знака тоже частое место ошибок и нужно покрывать тестами.
Вместо знаковой jle .count должна быть беззнаковая jbe.

[Ende]

Выделена тема «Еще раз о пользе от ассемблера»

[Dmitriy40]

Yadryara
Вы проверили что это другая ошибка? Ту по прежнему надо искать/исправлять. Исправить кстати проще чем понять причину. Может отсюда и шуточки "глюк не нашёл, но работу поправил".

[Yadryara]

Dmitriy40, понятно что это разные ошибки. Найду время, буду разбираться.

Dmitriy40 в сообщении #1626691 писал(а):

А так то вылет по ошибке будет думаю для всех нечётных простых чисел больше 4294705156

Нет, определяет простоту вплоть до 4294827197. А на следующем простом (4294827209) уже вылетает.

[Yadryara]

Dmitriy40 в сообщении #1626691 писал(а):

Прогоните в голове куда пойдёт управление при ESI=0x7FFF (это составное число с 0 в primes и проверяемое например ECX=0xFFFFFFFD на него не делится).

Неудачная формулировка? Не делится не в том смысле, что не удаётся разделить нацело, а в том смысле, что попытка разделить не будет предпринята.

Dmitriy40 в сообщении #1626691 писал(а):

Я думаю снова придёт к inc ESI и вашей проверке. Что будет дальше?

inc ESI сработает, а вот результат mul EAX выйдет за пределы четырёх байт из-за чего в EDX запишется 1, а EAX обнулится.

Тогда cmp EAX,ECX уже не сработает как надо.

Dmitriy40 в сообщении #1626691 писал(а):

И сработает ли тогда не показанный jnc после cmp?

Тоже не сработает.

[Dmitriy40]

Yadryara в сообщении #1626777 писал(а):

Нет, определяет простоту вплоть до 4294827197.

И однако это тоже ошибка: в отладчике видно что при проверке этого числа ESI досчитывает до 0x1A887, чего быть никак не должно, это в 3.3 раза дальше конца primes. Просто повезло что там что-то есть (ещё какой-то наш массив) и взятие оттуда битов не обнаруживается как выход за пределы массива (с этим в асме очень тяжело, любые проверки на плечах программиста). Вот недостаток тестов, не все ошибки могут обнаружить.

Yadryara в сообщении #1626782 писал(а):

Неудачная формулировка?

Пожалуй. Хотел сказать что при таком ESI переход jz .ret после деления точно не сработает и обязательно попадём на inc ESI.

Yadryara в сообщении #1626782 писал(а):

inc ESI сработает, а вот результат mul EAX выйдет за пределы четырёх байт из-за чего в EDX запишется 1, а EAX обнулится.
Тогда cmp EAX,ECX уже не сработает как надо.

Ну вот и ошибка, да. Осталось придумать как её поправить. Способов несколько: можно вернуть мой cmp с jnc, можно проверить EDX на 0, можно после mul поставить jc (посмотрите в каком случае она выставляет флаг), ещё как-то. В данный момент мне нравится первый (хотя вообще последний) - и дидактически более правильный, и позволяет показать один момент оптимизации (почти не влияющий на скорость, но всё же). Понятны должны быть уже все три способа.

Думаю можно заканчивать с этой ошибкой, Вы уже разобрались, поправить её теперь совсем несложно.
Что дальше. Я бы хотел показать 3-4 (на сколько терпения хватит) забавных момента небольшой оптимизации, и в качестве небольшой паузы на усвоение (и тренировку, например с отладчиком), и как пример оптимизаций, не всегда дающих эффект, тем более ожидаемый.
А потом пожалуй перейти к тесту Ферма на простоту как практически полезному, особенно под x64, там четверть гига под primes откровенно жалко, да и перебираться оно будет страх как долго.

[Yadryara]

Dmitriy40 в сообщении #1626801 писал(а):

Осталось придумать как её поправить. Способов несколько: можно вернуть мой cmp с jnc,

Но jnc .yes я и не правил.

Dmitriy40 в сообщении #1626801 писал(а):

посмотрите в каком случае она выставляет флаг

В отладчике посмотреть? Я его боюсь Думаю, может мне к более простому коду вернуться, к Фибоначчи и его посмотреть в отладчике.

Dmitriy40 в сообщении #1626801 писал(а):

В данный момент мне нравится первый (хотя вообще последний) - и дидактически более правильный, и позволяет показать один момент оптимизации (почти не влияющий на скорость, но всё же).

Поскольку идёт битва за скорость, 1-й способ, видимо, в топку?

Dmitriy40 в сообщении #1626801 писал(а):

Я бы хотел показать 3-4 (на сколько терпения хватит) забавных момента небольшой оптимизации,

Как Вам будет угодно.