а тебе это случаем не для того чтоб вычислять размер оставшегося места от 512 байт?

наткнулся на странную хрень: format ELF64 executable at 0xFFFFFFFFC0000000 segment readable executable entry _start _start: jmp _start fasm в этом случае генерирует не корректный бинарник, по какой-то причине в поле отвечающем за смещение таблицы сегментов попадает некорректное значение

Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) При любом значении at.

версия фасма?

1.73.30. Вон там в ченжлоге 1.73.24 "Upper bits of default entry point of ELF64 executable were not correctly stored in the header." Может как-то связано?

1.73.30. Вон там в ченжлоге 1.73.24 "Upper bits of default entry point of ELF64 executable were not correctly stored in the header." Может как-то связано?

Было приятно с вами посидеть 🥰

Привет Где пропадала, тебя почти год не было видно

Вопрос на засыпку... Чтоб собрать драйвер, обязательно нужен DDK?

Здесь можно нубские вопросы задавать? Вопрос такой - в чем причина низкой производительности инструкции loop (медленнее в 3 -5 раз по сравнению с реализацией цикла без loop). Ведь там и там есть некий счетчик и переход на метку при выполнении условия.

в трудах агнера фога об этом сказано почему

что то про оптимизацию наверное

Я тут просто проверить решил... Оказалось хватает для сборки ассемблера и линковщика...

А так... Вышло даже 64битный драйвер собрать... И работает приблуда...

Здесь можно нубские вопросы задавать? Вопрос такой - в чем причина низкой производительности инструкции loop (медленнее в 3 -5 раз по сравнению с реализацией цикла без loop). Ведь там и там есть некий счетчик и переход на метку при выполнении условия.

а есть намек на какой конкретно из его трудов? а то у него их 5 (если не путаю)

Посмотри тут, Кирилл: https://stackoverflow.com/questions/35742570/why-is-the-loop-instruction-slow-couldnt-intel-have-implemented-it-efficiently

Кстати, вы знаете о том, что bt/bts/btr/btc позволяют адресовать не только указанный адрес, но и соседние (на большое расстояние) в зависимости от счётчика? Скажем, bt word [eax],ecx при ecx=12345678h будет проверять слово по адресу [eax+1234567h] :)

да там какая то иструеция есть чтоб адресовать/проверять биты в памяти, но там ограничение вроде в 65кб

Возможно, а в 16 битах использовал только. Поэтому решил, что в 32 так же.

да там какая то иструеция есть чтоб адресовать/проверять биты в памяти, но там ограничение вроде в 65кб

Там немного другое ограничение. Там позиция бита со знаком. А в остальном ты ограничен только размером регистра: format pe gui at 0x0f000000 include 'win32ax.inc' start: mov edx,.target * 8 bts [0],edx ; 200 мегабайт от 0. xor eax,eax .target: jz .exit invoke MessageBox,0,'im alive','hello',0 .exit: invoke ExitProcess,0 .end start

Посмотрел доку. Не вижу ограничения на 64 Кб. Так что да, можно хоть плюс-минус гигабайт адресовать.

Или где про это почитать?

Лол, она отвечать умеет 😂

Всем доброго дня, можете, пожалуйста, подсказать зачем мы в цикле отдельно считаем количество флагов cf, командой adcl $0, -28(%ebp), а потом отнимаем это число из регистра eax командой sbbl -28(%ebp), %eax ??? Вот фрагмент кода: movl $0, -28(%ebp) jmp .L2 .L3: fldl -16(%ebp) faddl -24(%ebp) fstpl -16(%ebp) fldl -24(%ebp) fmull -40(%ebp) fildq -32(%ebp) fdivrp %st, %st(1) fstpl -24(%ebp) addl $1, -32(%ebp) adcl $0, -28(%ebp) .L2: movl $999999, %edx movl $0, %eax cmpl -32(%ebp), %edx sbbl -28(%ebp), %eax jge .L3

Народ, кто навскидку подскажет, как задетектить переключение контекста в блоке кода. Т.е. есть точка A и точка B. Нужно понять, было ли переключение контекста между ними. Вернее говоря, не только переключение, но и проваливание в планировщик. И второй момент: как свести его к минимуму. Я пробовал как-то делать SwitchToThread перед точкой A, чтобы обнулить квант времени потока, но ощущение, что это не даёт желаемого эффекта.

Я ничего не понял

Какую часть? 1. Есть код A............B. Внутри может быть переключение контекста (на другой поток или просто проваливание в планировщик винды и обратно). А может и не быть. Надо определить, было ли оно. Как вариант можно заюзать GetThreadTimes и сравнить lpKernelTime до и после (ну либо NtQueryInformationThread), но может, есть ещё какая-то функция (здесь важна скорость, а эти функции проваливаются в ядро). 2. Потоку дан квант времени X, в момент запуска кода A......z...B квант может подходить к концу и закончиться в момент z. Мне нужно обновить квант перед запуском кода, чтобы в момент z не проищошло переключение (если код A...B достаточно короткий).

1. NtQuerySystemInformation с SYSTEM_THREAD_INFORMATION, тупо прочитать количество переключений контекста. Не очень надёжно, но можно повторить пару раз (это ведь бенчмарк, да?). 2. Возможно Sleep(0) сработает лучше.

Почему не очень надёжно? По логике GetThreadTimes должен работать быстрее, ибо работает с одним тредом, а не со всей системой. Т.е. меньше проверок, обращений к внутренним таблицам и пр. Но надо тестить.

Да. Но всё равно надо нейтив дёргать. Так меньше шансов, что оно будет дёргать больше одного сисколла. Мало ли что там MS добавит в свежих Windows. А ненадёжно как раз потому, что никто не гарантирует ровно один сисколл на один вызов апи. Где-то что-то в своп улетит, вот тебе и лишнее переключение. В любом случае тестить надо, да.

2. Надо потестить оба варианта лучше. Но вроде SwitchToThread должен работать лучше.

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

Ну мы вызываем до, получаем n. Вызываем после, получаем n + 2. Это переключение посередине плюс вызов, или 2 за сам вызов?

Обрами в ```, плиз.

2. Надо потестить оба варианта лучше. Но вроде SwitchToThread должен работать лучше.

Всем доброго дня, можете, пожалуйста, подсказать зачем мы в цикле отдельно считаем количество флагов cf, командой adcl $0, -28(%ebp) , а потом отнимаем это число из регистра eax командой sbbl -28(%ebp), %eax ??? Вот фрагмент кода: movl $0, -28(%ebp) jmp .L2 .L3: fldl -16(%ebp) faddl -24(%ebp) fstpl -16(%ebp) fldl -24(%ebp) fmull -40(%ebp) fildq -32(%ebp) fdivrp %st, %st(1) fstpl -24(%ebp) addl $1, -32(%ebp) adcl $0, -28(%ebp) .L2: movl $999999, %edx movl $0, %eax cmpl -32(%ebp), %edx sbbl -28(%ebp), %eax jge .L3

Я потестил. В большинстве случаев (малозагруженная система) SwitchToThread вообще не хочет никуда переключаться и возвращает 0. Примерно то же происходит и с Sleep(0). У меня получается, что цепочка Sleep(1)/NtQuerySystemInformation()/Sleep(1)/короткий кусок кода/NtQuerySystemInformation() — самое надёжное, дельта между первым и вторым вызовом чаще всего 1.