A
скорость доступа - это к памяти относится, скорость работы - к инструкциям
Size: a a a
2021 March 30
SZ
вопрос про скорость работы, а не скорость доступа
Скорость работы человека с регистром %rax на 25% меньше, чем с %r8, потому что требуется ввести на 1 символ больше
SZ
скорость доступа - это к памяти относится, скорость работы - к инструкциям
Регистры чем не память? Регистровая память, таки
A
Регистры чем не память? Регистровая память, таки
я тебе о чем и говорю, он задал вопрос неправильно. скорость работы относится к инструкциям, скорость доступа к памяти
A
он же спрасил про скорость РАБОТЫ памяти
AM
Как-то все сразу в терминологию углубились. Я имел в виду следующее: допустим надо скопировать нечто в rax/eax/ax. Будет-ли одинаковым время выполнения операции для rbx/ebx/bx, rcx/ecx/cx, rdx/edx/dx и т.д.
SZ
Как-то все сразу в терминологию углубились. Я имел в виду следующее: допустим надо скопировать нечто в rax/eax/ax. Будет-ли одинаковым время выполнения операции для rbx/ebx/bx, rcx/ecx/cx, rdx/edx/dx и т.д.
Да
A
Как-то все сразу в терминологию углубились. Я имел в виду следующее: допустим надо скопировать нечто в rax/eax/ax. Будет-ли одинаковым время выполнения операции для rbx/ebx/bx, rcx/ecx/cx, rdx/edx/dx и т.д.
нет
A
Я когда-то давно заглядывал в справочник по 80386+/-, так там например было описано что пары регистров выполняют операции с разным количеством тактов... Например: [bx+si] и [bp+di] быстрее нежели если делать [bx+di] и [bp+si]... А как на современных, не знаю...
пример привели
SZ
Ну ты сейчас ещё скажи, что из-за квантовых эффектов у двух любых различных событий не может быть одинакового времени выполнения
A
Как-то все сразу в терминологию углубились. Я имел в виду следующее: допустим надо скопировать нечто в rax/eax/ax. Будет-ли одинаковым время выполнения операции для rbx/ebx/bx, rcx/ecx/cx, rdx/edx/dx и т.д.
если приводишь пример приводи его не эфимерно, а сконкретикой
EK
Парни! Я, наконец, допилил первую версию "Floating-point Instruction Bytecode Generator & Recompiler" (и сделал более или менее внятное описание) и готов показать его вам ✌️
Модуль и демо лежат здесь: https://www.pouet.net/prod.php?which=88492
Описание по ссылке. Более развёрнутое — внутри модуля.
Ориентировано, в первую очередь, на сайзкодинг (экономию пространства).
Вкратце:
Модуль и демо лежат здесь: https://www.pouet.net/prod.php?which=88492
Описание по ссылке. Более развёрнутое — внутри модуля.
Ориентировано, в первую очередь, на сайзкодинг (экономию пространства).
Вкратце:
>>> WHAT IS THIS? <<<
In fact, this is a packer of x86 FPU instructions with ≈ 3-4x efficiency (not taking into account recompiler code and constants).
All you need is just define some symbolic constants, include this file in your fasm project, use a few macros and perform a call to recompiled function.
>>> FEATURES <<<
• Definition of FPU operations in easy to read format of Reverse Polish Notation (RPN).
• Flexibly customizable recompiler which creates native x86 function from bytecode (that is, fast for execution).
• Native code copier (so you can mix FPU instructions with native x86 code inside bytecode block).
• Declaration of up to 11-13 bytecode instructions associated with 2-byte FPU (...or not only FPU?...) instructions (this number is sufficient for most purposes).
• Definition of up to 17 2-byte integer and floating-point constants.
• Definition of up to 16 4-byte floating-point variables.
• Declaration of unlimited subfunctions with custom names inside bytecode block.
• Possibility to override some predefined bytecode instructions associated with native x86 instructions.
• The size of recompiler is ≈ 50..74 bytes (for 1..13 types of bytecode instructions, with no support of native code copier, variables and subfunctions) to ≈ 65..85 / 76..96 bytes (for 1..11 types of bytecode instructions, with max functionality) including writting of input stream offset to register. This size can vary depending on used options of macro 'fpb_recompile!'.
>>> NOTES <<<
Brief statistics of HerbaKaif intro:
- bytecode contains 244 nibbles (= 122 bytes = 169 opcodes; average length of 1 bytecode instruction ≈ 1.44 nibbles ≈ 0.72 bytes);
- size of recompiled function = 413 bytes (compression ratio ≈ 3.39x; average length of 1 unpacked native x86 instruction ≈ 2.44 bytes);
- size of recompiler = 74 bytes (including writting of input stream offset to register, although this is partly part of another code);
- compression ratio including bytecode recompiler = 413/(122+74) ≈ 2.11x.d
Кстати вопрос возник. А с точки зрения скорости работы регистры rax/eax/ax, rbx/ebx/bx, rcx/ecx/cx, rdx/edx/dx, r8, ..., r15 одинаковы или имеется конструктивно обусловленная разница?
Не думай об он достаточно быстры
EK
Я когда-то давно заглядывал в справочник по 80386+/-, так там например было описано что пары регистров выполняют операции с разным количеством тактов... Например: [bx+si] и [bp+di] быстрее нежели если делать [bx+di] и [bp+si]... А как на современных, не знаю...
На 8086 было такое, и работа с al/ax была быстрее, насколько я помню. А сейчас это только псевдонимы. Реальных (физических) регистров гораздо больше. И тот же rax может быть привязан к разным регистрам в разные моменты времени. Скажем:
Здесь все 3 регистра eax скорее всего будут привязаны к разным физ регистрам, чтобы не создавать зависимости и не останавливать выполнение.
mov eax,[ecx]
cdq
idiv ebx
mov eax,[ecx+4]
add [esi],eax
xor eax,eax
Здесь все 3 регистра eax скорее всего будут привязаны к разным физ регистрам, чтобы не создавать зависимости и не останавливать выполнение.
A
Книга хороша когда у тебя есть цель. Когда цели нету - мало чего впитаешь. Вот я тебе цель и придумал 😉
у тя как дела обстоят с fasmg?
𝐦
у тя как дела обстоят с fasmg?
Я сейчас немного в другую область капаю ))
𝐦
Как-нибудь расскажу
A
Как-нибудь расскажу
VM?
𝐦
В какой то степени.