mayton2019

Такой функции скорее всего не существует. Тут как в парадоксе про пудинг. Чтобы узнать хороший он или
нет - его надо сьесть. Вот чтобы узнать длину машинного кода нужно провести этот код по всем стадиям
компилляции. А судя по внешнему виду это не С++. Это DotNet поэтому здесь будет минимум 2 стадии.
DotNet => MSIL. И потом уже в машинный код. Подозреваю что длина машинного кода будет
зависеть от версии DotNet, от разрядности платформы 32/64 и от целевой железной архитектуры
Intel/ARM e.t.c.

Вот такое получается уравнение со многими неизвестными. И его решить можно только практически.
Компиллируем. Смотрим. Считаем. Если нудно считать - автоматизируем подсчет функции.

Если ты новичек - начни с простого. Когда я учился в универе - у меня был просто интерес написать
графическую библиотеку для SVGA/VGA режимов графики. На дворе стояли 90-е и тогда не было
никаких ускорителей и видяшки назывались S3/Trident. Вобщем сильно много я не написал.
Было просто рисование цветных трапеций на экране. И это чудовищно непроизводительно для
процесса разработки. Любой С++ ник заткнет тебя за пояс по скорости выкатки новых фич.
А качество кода на выходе у gcc вполне себе хорошее чтобы не найти вообще кейсов где
человек может лучше написать. Вообще в чем заключается оптимизация на асме? Держать
в голове карту регистров и помнить какой из них под чего использован. Еще неплохо-бы
помнить что у тебя в кешах лежит.

Что еще из простого. Попробуй реши квадратное уравнение на FPU и на SSE. Это разные
техно-стеки и будет познавательно сравнить какой способ лучше или удобнее.
FPU - это легаси но он еще поддерживается в железе. Я тоже хотел когда-то написать но бросил
в силу своей нетерпеливости. Мне было интересно понять насколько FPU близок к языку Forth.

По топику выше пишут интересные советы по брутфорсу но это задача на уровне алгоритмизации
сложная и я-бы на твоем месте все таки начал с квадратных уравнений. Заодно освоишь работу с вводом
выводом текста.

Вобщем брутфорсы и умноженя матриц это очень круто но ту просто попробуй это ПРАВИЛЬНО решить
на языке высокого уровня и проникнись с сложностью решения. И я думаю на этом этапе ты устанешь
и не пойдешь дальше. Вообще ассемблер - это язык очень узкого применения и какие-то языковые
фичи (ООП) в ассемблере уж точно не нужны. Ну по крайней мере они там не имеют какого-то явного
преимущества.

Тут еще такая тема что на эту задачу трудно написать acceptance criteria. Ну допустим пойдет автор на фриланс. Сделает заказ. Ему скажут готово. Переписал. Он скажет - не работает. А они скажут - пуговицы пришиты нормально.
Какие претензии? Скользкая это постановка. Вообще надо ставить новую задачу о разработке софта. Это знания из ДОС-овского исходника можно использовать а можно и выкинуть. Но упор здесь должен быть именно на разработку.

Вот тут пишут https://stackoverflow.com/questions/137038/how-do-...

Для копирования из временного буффера в видимый, я использовал инструкцию rep movsd, хоть и знаю, что до i286 включительно такой инструкции нет. Вопрос: как повысить число кадров в секунду?

Без тонкой диагностики нут - нельзя. Я не знаю как в геймдеве но в других отраслях при возникновении проблем самое первое что делают - меряют время. Можно мерять профайлером но это явно не твой вариант.

Найди себе сверх-точные часы которые меряют наносекунды (ты-же ассемблерщик?) Померяй сколько занимает rep movsd. Меряй не один раз а хотя-б много итераций и бери среднее. Может быть не в этом твоя проблема с fps, а где-то в другом коде.

Напоминает попытку построить свой кеш. А зачем топик тегирован Ассемблером? Какая тут нерешаемая
для ассемблера задача?

Код цифры - в сигналы 7 сегментного индикатора это классическая задача на системотехника.

Рисуют табличку. Потом минимизируют через карты Карно. Получается 7 булевых функций которые отображают номер в сегменты индикатора.

Но для нашего случая табличка из 10 цифр сойдёт.

Это красивое число. Вот так в хексах выглядит 0x40000000.
Скоре всего это какая-то константа из stdio.h, stdlib.h, time.h

Для проведения уроков хочу написать простенький симулятор процессора

Нужно делать тот минимум который нужен для уроков. Если например это арифметика - то
сойдет процессор без регистров. Можно считать что разрабатываем систему команд для
стековой машины. Как Java.

Движение по кругу задается параметрически. Задаешь параметр fi (фи) пробегающий от 0.0 до 2*Pi радиан.
Далее косинус фи дает тебе иксовую координату. А синус игрековую. Координаты нормированы от -1.0 до 1.0
и их еще надо умножить на пол поперечника окна и сдвинуть на центр координат окна.

Как это делается в WinGDI я не помню. Но тригонометрия - это хитрая штука для ассебмлера. И я тебе советую
сделать макет на языке С и сгенерировать ассемблерный выход и посмотреть что так и как.

А потом уже интересующие тебе функции перенести в твой исходник.

а в перспективе хочу научиться писать читы(ну и возможно вирусы, хихи)

На счет платформы, то в основном интересует Linux и Windows(но линукс все таки больше)

Я недавно смотрел статистику ОС Desktop по браузерам. Вобще получается что 75% windows, 15% macos, и только 7% - всякие Unknown + Linux. Вобщем если брать как асм как оружие массового поражения - то поражать особо некого. Кроме того владельцы линуксов - это такие себе ленивые кабанчики. Трояны твои они не откроют все равно. Экзешники не качают. Все сами собирают. Вобщем безсмысленное это дело.

А вот для пользы асм нужен там где есть performance issue и где С++ ник никак не может разобраться почему так.

Еще демки можно писать с 3d. Или игры наподобие MDK. Кто-то в 90х мне говорил что она на Асм написана. Хотя я не верю. Ну вряд-ли. Может какие-то мелкие куски.

Это проектировалось в 20-м веке. Тогда считалось что 1Мб памяти - это очень много. Вот и была сделана такая странная формула где любая комбинация сегмента + смещения всегда заворачивает вас в этот мегабайт.

Сегодня нет смысла изучать Intel 8086. Я не знаю что за преподаватель толкает вам такое старье. Это все равно что на уроках химии изучать философский камень или четыре стихии огонь-земля и так далее.