он всё, что ему скормишь, рассматривает по-символьно; скармливаешь ему формальные параметры макроса и потом уже парсишь посимвольно (на первом проходе ищещь четные/нечетные кавычки)

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

ну типа там mymacro r7 18+5 9 78

эквивалентно ну типа там mymacro r7,18+5,9,78

можно попробовать сочинить маймакро "ура за родину" — получишь три фактических параметра

это конечно не совсем полноценно, например, 12+7 внутри эрзац-строки скомпилируется в 19

Михаил, спасибо огромное ! такой вот вариант работает:

.macro TEST_STRING s .irpc p,"\s" .if \p == '"' .warning "OOOOOOOOOOOKKKKKKKKKKKKKKKK !!!!!!! \s\()" # определить внутреннюю переменную сигнализирующую ковычки .exitm .endif .endr .endm;

на здоровье )

время будет свободное, я всё таки попробую запилить директиву .ifquoted в AS, может что и получится ))

см. в сторону макроса .irpc

Михаил, директива .irpc в том макросе что я скидывал, отрабатывает один раз. Если вызвать макрос повторно выдаёт ошибку: "Ошибка: символ «.if» уже определён". Есть какие-нибудь соображения как вылечить ?

буду за компом, скину

буду за компом, скину

Михаил, уже не нужно, запилил макро директиву .ifquoted: https://sourceware.org/ml/binutils/2020-01/msg00292.html

драсте

Подскажите, как разрешить конфликт имён в Tasm? Есть импортируемая и экспортируемая функция с одинаковым именем: EXTRN sprintf:proc И PUBLICDLL sprintf. Tasm ругается, что имена совпадают и не дают откомпилировать программу. Пока решаю задачу так: эксортируемая функция идет под другим именем и далее приходится патчить исполняемый код.

щас тебе люди будут советовать не использовать сишные функции, пиши мол все сам

Подскажите, как разрешить конфликт имён в Tasm? Есть импортируемая и экспортируемая функция с одинаковым именем: EXTRN sprintf:proc И PUBLICDLL sprintf. Tasm ругается, что имена совпадают и не дают откомпилировать программу. Пока решаю задачу так: эксортируемая функция идет под другим именем и далее приходится патчить исполняемый код.

а попробуй экспортировать с другим именем

щас тебе люди будут советовать не использовать сишные функции, пиши мол все сам

Пишется интерцептор dll, а она импортирует и экспортирует одну и ту же функцию

Может, вместо tasm использовать другой компилятор?

Может, вместо tasm использовать другой компилятор?

Присоединяюсь. Но вообще, наверное, можно .def написать, и там в exports переименовать. Тасм ведь умеет .def?

Может, вместо tasm использовать другой компилятор?

кто-то ещё теребит старичка? я вот LLVM IR щупаю, немного непонятный, нет проблем с регистрами

кто-то ещё теребит старичка? я вот LLVM IR щупаю, немного непонятный, нет проблем с регистрами

Это же промежуточный код не для исполнения

Это же промежуточный код не для исполнения

ну да

он же потом в нативный переводится

он же потом в нативный переводится

Ну да, бекендом. А вот как туда асмовставки нативные пихаются?

Ну да, бекендом. А вот как туда асмовставки нативные пихаются?

ты имеешь в виду "пользовательские"?

ты имеешь в виду "пользовательские"?

Ну да, всякие __asm("mov %1,%%es"::"a") и т п

да, можно, сейчас

Ну да, всякие __asm("mov %1,%%es"::"a") и т п

https://llvm.org/docs/LangRef.html#module-level-inline-assembly

https://llvm.org/docs/LangRef.html#module-level-inline-assembly

Ну то есть вообще "живьем" пробрасываются

Побайтно, стало быть?

в виде строк

Неужели в откомпилированном виде строки будут?

я решил llvm ir попробовать, чтобы свой простенький компилятор написать

Неужели в откомпилированном виде строки будут?

В ассемблерном коде всегда строки, ассемблер пережует в бинарь

В ассемблерном коде всегда строки, ассемблер пережует в бинарь

Так а в LLVM-бинаре что будет?

я решил llvm ir попробовать, чтобы свой простенький компилятор написать

Все жду пока кто-нть наваяет бекенд к ebc. Один чувак пытался, но, походу забросил.

Так а в LLVM-бинаре что будет?

Судя по ссылке выше - строки.

Все жду пока кто-нть наваяет бекенд к ebc. Один чувак пытался, но, походу забросил.

ebc — это?

ebc — это?

EFI bytecode

аа

https://llvm.org/docs/LangRef.html#inline-assembler-expressions

EFI bytecode

Он помер же вроде

Кстати, radare2 умеет его дизасмить

чуваки, подскажите, пожалуйста, что здесь происходит? https://monosnap.com/file/9bd2MgMnN1KWxicbSRRnbsjR8v6KYz скомпилил nasm’ом обычный хелло_ворлд, слинковал и сделал дизасм. MacOS.

И может немного не по теме, но если кто знает, подскажите еще такой момент: как можно замерить влияние суперскалярности на производительность? Есть ли тулзятины, которые помогают как-то трекать prefetching, out of order, superscalar, branch prediction и т.п. штуки (если не все перечислил:))

И может немного не по теме, но если кто знает, подскажите еще такой момент: как можно замерить влияние суперскалярности на производительность? Есть ли тулзятины, которые помогают как-то трекать prefetching, out of order, superscalar, branch prediction и т.п. штуки (если не все перечислил:))

Самому написать?

Самому написать?

даже не знаю как подступиться. есть тематичские линки?

чуваки, подскажите, пожалуйста, что здесь происходит? https://monosnap.com/file/9bd2MgMnN1KWxicbSRRnbsjR8v6KYz скомпилил nasm’ом обычный хелло_ворлд, слинковал и сделал дизасм. MacOS.

у тя на этом участке памяти нули, дизасм расшифровывает эти опкоды так как ты и видишь

нули - это nop?

нули - это nop?

нули это 0000

а, понял спасибо

у nop код инстукции другой

И может немного не по теме, но если кто знает, подскажите еще такой момент: как можно замерить влияние суперскалярности на производительность? Есть ли тулзятины, которые помогают как-то трекать prefetching, out of order, superscalar, branch prediction и т.п. штуки (если не все перечислил:))

Читай об инструкции rdpmc. Я её не использовал, просто знаю, что она есть и позволяет получать счётчики производительности (в т.ч. last-level cache misses, branch misses и пр). Короче, 18-я глава 3-го тома интеловского мана + описание инструкции во 2-м томе. Но это нетривиальная задача. Инструкция привилегированная, а значит придётся юзать драйвер. В качестве примера использования можно взять PMCTest Агнера Фога: https://www.agner.org/optimize/#testp (драйвер в комплекте). Но разбираться придётся самому.

Читай об инструкции rdpmc. Я её не использовал, просто знаю, что она есть и позволяет получать счётчики производительности (в т.ч. last-level cache misses, branch misses и пр). Короче, 18-я глава 3-го тома интеловского мана + описание инструкции во 2-м томе. Но это нетривиальная задача. Инструкция привилегированная, а значит придётся юзать драйвер. В качестве примера использования можно взять PMCTest Агнера Фога: https://www.agner.org/optimize/#testp (драйвер в комплекте). Но разбираться придётся самому.

спасибо!

Но это если самому делать. А готовые "тулзятины" — это профайлеры, собственно. Intel VTune Amplifier, к примеру. Правда, вот не подскажу, может ли он давать такую подробную инфу. Не так много им пользовался, да и времени много прошло с последнего раза.

Есть ещё Intel Architecture Code Analyzer (IACA). Не знаю, насколько он будет по теме. Это статический анализатор кода. Как там branch misses протестить через него — х/з, но вероятно, что-то придумать можно :))

И может немного не по теме, но если кто знает, подскажите еще такой момент: как можно замерить влияние суперскалярности на производительность? Есть ли тулзятины, которые помогают как-то трекать prefetching, out of order, superscalar, branch prediction и т.п. штуки (если не все перечислил:))

Линукс и perf? Сделать perf list, посмотреть, что процессор умеет отдавать.

#book

Тяжело когда нету закладки с этим тегом. Приходится в поисковик каждый раз заходить.

нули это 0000

а может в курсе, почему он мне 4к этих нулей забомбил?

а может в курсе, почему он мне 4к этих нулей забомбил?

Как можно нормально ответить на этот вопрос просто по скриншоту куска кода с нулями? Вообще, страница памяти обычно имеет размер 4кб.

Как можно нормально ответить на этот вопрос просто по скриншоту куска кода с нулями? Вообще, страница памяти обычно имеет размер 4кб.

https://pastebin.com/SA1NrG9U если бы я знал как спросить, я бы спросил. у меня обычный “hello world” бинарь на ассемблере на диске. как это связано со страничной памятью? не понимаю. или это как-то связано с тем, что файлы в фс не хранятся размером меньше, чем 4кб?

а может в курсе, почему он мне 4к этих нулей забомбил?

винда при выделении памяти под секции программы (code data итд) видимо зануляет выделенные участки.

ещё возможно при вырпвнивании кода, данных компиль может нулями заполнить промнжуток

ещё возможно при вырпвнивании кода, данных компиль может нулями заполнить промнжуток

скорее всего это

но скорей всего то что ты показываешь это не код а данные, имхо

При выделении память обнуляется: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc

но скорей всего то что ты показываешь это не код а данные, имхо

Там с офсета 28 написано __PAGEZERO. Это неспроста 😁

Memory allocated by this function is automatically initialized to zero.

Пастбин не смотрел пока.

Пастбин не смотрел пока.

Там в пастебине бинарник для мака, дизассемблированный как raw.

https://pastebin.com/SA1NrG9U если бы я знал как спросить, я бы спросил. у меня обычный “hello world” бинарь на ассемблере на диске. как это связано со страничной памятью? не понимаю. или это как-то связано с тем, что файлы в фс не хранятся размером меньше, чем 4кб?

Лучше код всегда приводить, иначе не понять, что ты делаешь.

но скорей всего то что ты показываешь это не код а данные, имхо

меня смущает, что это лежит в бинаре

меня смущает, что это лежит в бинаре

и пока я пришел к выводу, что это относится к заголовку mach-o

меня смущает, что это лежит в бинаре

Это может лежать в бинаре, потому что, например, так код написан.

Оригинального исходника нет?

Оригинального исходника нет?

section .text global _start _start: mov rax, 0x02000004 mov rdi, 1 mov rsi, message mov rdx, 2 syscall mov rax, 0x02000001 xor rdi, rdi syscall section .data message: db "Hello, World", 10

в спеке mach-o 1. The static linker creates a __PAGEZERO segment as the first segment of an executable file. This segment is located at virtual memory location zero and has no protection rights assigned, the combination of which causes accesses to NULL, a common C programming error, to immediately crash. The __PAGEZERO segment is the size of one full VM page for the current CPU architecture (for x86 and PowerPC, this is 4096 bytes or 0x1000 in hexadecimal). Because there is no data in the __PAGEZERO segment, it occupies no space in the file (the file size in the segment command is zero). Field Descriptions 2. vmsize Indicates the number of bytes of virtual memory occupied by this segment. See also the description of filesize, below. 3. filesize Indicates the number of bytes occupied by this segment on disk. For segments that require more memory at runtime than they do at build time, vmsize can be larger than filesize. For example, the __PAGEZERO segment generated by the linker for MH_EXECUTABLE files has a vmsize of 0x1000 but a filesize of zero. Because __PAGEZERO contains no data, there is no need for it to occupy any space until runtime. Also, the static linker often allocates uninitialized data at the end of the __DATA segment; in this case, the vmsize is larger than the filesize. The loader guarantees that any memory of this sort is initialized with zeros. если сделать: otool -lv app, там можно найти: segname __PAGEZERO vmaddr 0x0000000000000000 vmsize 0x0000000100000000 fileoff 0 filesize 0 Все логично, подходит по спеке. Размер файла на диске 12кб (ок, 3 pagesize’а) Сам размер файла 8300+ байт, если открывать средствами не какого-нибудь hexdump, а средствами с++ или саблаймом тем же. это при чтении файла fs распознает формат и отдает лишние 0? Нелогичено для меня, почему тогда размер на диске учитывает эти 0

В любом случае спасибо; откуда это идёт разобрался. А если кто допрет, почему на диске лежит этот пэйджзеро и поделится, тоже буду благодарен