На вики можно логиниться, шифрование лишним не будет по современным меркам

@s54816 можно ли как то сделать чтоб используя fasm.exe в исходнике не надо было прописывать полные пути к инклудам, как это сделано в fasmW.exe

Собрать весь хлам в одном месте?

SET INCLUDE="C:\BLA;D:\BLABLA" в переменных окружения в винде?

И ещё я для себя сделал батник просто, который ко всем win32*.inc дописывает мои инклуды после установки нового фасма.

у тя как это сделано если ты используешь консольную версию?

У меня сделано fasm.bat, который лежит в WINDOWS\system32, который выставляет SET PATH=... и SET INCLUDE=... для фасма, а потом запускает fasm %*

там есть авторизация, как минимум

hex b + hex c = hex 17

Но я же уточнил кавычками, что это символы
Здесь можно непредвиденно ответить только если:
— Кодировка будет ASCII-несовместимая, или ASCII-совместимая, но позиции Latin-1 будут отличаться
— Будет иметься ввиду кириллица, а не латынь (В - в, С - с | B - b, C - c)

Если же это ASCII (ISO 646, или ASCII-совместимая, с сохранением позиций Latin-1), классическая латынь, тогда 'B' == 0x41 + 'C' == 0x42 = 0x83 = 131 dec

@efe17 зачем нужен esc?

В общем чего то я сдернул в компутере и в HT пропали функции просмотра чтение и редактирование MZ/PE секций, таблиц импорта экспорта, в общем все самое вкусное, полез смотреть что то еще аналогичное, скачал biew и там вот наткнулся на интересный бенчмарк, вот непонятно то ли бенч кривой то ли что? Как это mmx быстрее в 10 раз чем sse может быть то. Мож тогда лучше на mmx писать :) И еще странно что lahf sahf написаны как 64бит, я думал эти комманды все процессоры x86 поддерживают?

"Как это mmx быстрее в 10 раз чем sse может быть то. Мож тогда лучше на mmx писать :) "

Да, действительно быстрее для Yonah (Intel Core Duo), и да - лучше, для этого процессора. К тому же, он дошёл только до SSE3, а вот SSE 3.1, SSE 4, SSE4.1, SSE 4.2 уже не поддерживает.

Я всё ещё ищу причину того, почему именно SSE на этом процессоре - медленный, но я думаю, что это:
Из-за узкой шины памяти, или автор просто написал кривой код.
Однако, по подтверждённым тестам Агнера Фога, для процессора Yonah (в твоём случае) - MMX действительно намного быстрее, чем SSE.
Я отобрал по 5 инструкций из каждого:
movd r32, mm   = 1
movd mm, r32   = 1
movd mm, m32   = 1
movd m32, mm   = 1
movd r32, xmm  = 1

movaps/d xmm, xmm  = 1
movaps/d xmm, m128  = 2
movaps/d m128, xmm  = 3
movups/d xmm, m128  = 2
movups/d m128, xmm  = 3

MMX всегда занимает 1 такт для этого процессора. SSE - 2-3

P.S: Насчёт "в 10 раз" не уверен. Опять же - автор что-то напутал, но то, что быстрее - правда

А вот насчёт lahf и sahf бредятина какая-то
lahf поддерживается ещё с 8086, и до x86_64
Как и sahf

Да там была какая то история связаная с тем что шина памяти 64 бит а регистры sse 128 бит да еще когда 2 ядра фигачат получается 256 и шина за 4 такта а то и больше эти данные перекачивает, что то с этим связано было а в следущих поколениях толи шину расширили толи на каждое ядро отдельно по шине сделали и проблема ушла, типа такого

Да, верно
Но я не смог найти информацию по шине Intel Core Duo (Yonah). Но я уже уверен, что это из-за этого

Короче, узкая шина памяти у него, вот и медленный SSE.
Вот разбор его CPUID (и в принципе там же есть его тесты по шине): https://www.ixbt.com/cpu/rmma-yonah.shtml

Однако там есть метод оптимизации movaps, заменив его на MOVHPS/MOVLPS MOVLHPS/MOVHLPS
Они равны одному такту

всмысле узкая шина памяти.. процессор из памяти грузит сразу по кэшлинии

более того у контроллера памяти очередь и он может обрабатывать до 4х запросов одновременно

то есть условно ты можешь грузить с адресов выровненных на 8, 16, 24, 32 параллельно

а SSE данные почти всегда выровненны в реальных программах