Информация об изменениях

Сообщение Re[18]: Новости C#12 от 18.04.2023 6:53

Изменено 18.04.2023 6:57 Философ

Старый текст
Новый текст
Разница

Re[18]: Новости C#12

Здравствуйте, ·, Вы писали:

·>...В общем, неважно, мой поинт в том, что очень часто необходимость выравнивать код по вертикали говорит о том, что code smells и его можно улучшить.

Давай начнём с того, что это не необходимость!? Адекватное форматирование кода просто улучшает читабельность, ВСЕГДА. Притом не важно, форматируешь ли ты код в соотвествии с корпоративным кодстайлом, либо даже вот такое, табличкой.

Далее, здесь ты читаешь оптимизированный код. Смотри: в интеловской документации команда описывается вот так:

if(OperandSize == 32) {
    //Instruction == POPAD
    EDI = Pop();
    ESI = Pop();
    EBP = Pop();
    ESP = ESP + 4; //skip next 4 bytes of stack
    EBX = Pop();
    EDX = Pop();
    ECX = Pop();
    EAX = Pop();
}
else {
    //OperandSize == 16, instruction == POPA
    DI = Pop();
    SI = Pop();
    BP = Pop();
    ESP = ESP + 2; //skip next 2 bytes of stack
    BX = Pop();
    DX = Pop();
    CX = Pop();
    AX = Pop();
}

Обрати внимание на скип 2-х и 4-х байт в зависимости от размера операнда. Можно было бы написать руками инкремент ESP, и описать функцию POP(). Но в конечном машинном коде тоже был бы инкремент, а в данном месте это КРИТИЧНОЕ замедление: вместо семи индексных с индексной адресацией в конечном коде было бы 7 операций с индексной адресацией + один лишний инкремент. Учитывая, что топовые современные камни едва тянут эмуляцию i486*, такие замедления неприемлимы.

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

Если не гнаться за каждой наносекундой, то можно было бы напихать регистры в список — кода было бы меньше, читалось бы замечательно. Однако эмулятор работал бы ещё медленнее.

Ф>>>> ((SP + 4) & 0xFFFF))
Ф>>·>Тут явно напрашивается что-то вроде "extract_something(SP + 4)", документации ради как минимум, и не потребуется вертикальное выравнивание.
Ф>>Зачем????? Посмотри на название функции — это opPOPA, т.е. команда, которая вычитывает регистры, используя ss и ESP. Что тут ещё документировать???!
·>Я имею в виду наложение маски "& 0xFFFF". Полагаю это извлечение значения для 16-битных команд. Ну так сделай метод с таким названием вроде use16bit.
·>Или сделать два метода readmeml16 и readmeml32 и там эту маску запрятать. В эту же пару методов можно и SP += 4 / ESP += 4 запрятать чтобы всю эту твою копи-паст арифметику не писать.

Ф>>А вот производительность эмулятора ты вот такими необдуманными действиями легко можешь просадить.
·>Если вы пишете на яп, который в тривиальнейшие оптимизации не умеет, вы явно выбрали неподходящий инструмент.

·>Я имею в виду наложение маски "& 0xFFFF". Полагаю это извлечение значения для 16-битных команд. Ну так сделай метод с таким названием вроде use16bit.

Попробуй. Код тут Инструкция по сборке здесь. Чтобы попробовать, тебе будут нужны ROM'ы, они тут.
Сабжевый код находится в src/cpu/x86_ops_stack.h
Покажи потом что получилось.

Ф>>необычно.
·>Какой необычный форматтер вы используете?

Лично я ничего не использую. В этом проекте я вообще код в FAR'е пишу, потому что так и не осилил настроить ни одну из сред разрабоки. Честное слово, крыл благим матом все IDE, которые пытался приспособить для этого проекта. А так — кто во что горазд.

Как запретить автоматическое форматирование в VS (не VS Code) не знаю.

Re[18]: Новости C#12

if(OperandSize == 32) {
    //Instruction == POPAD
    EDI = Pop();
    ESI = Pop();
    EBP = Pop();
    ESP = ESP + 4; //skip next 4 bytes of stack
    EBX = Pop();
    EDX = Pop();
    ECX = Pop();
    EAX = Pop();
}
else {
    //OperandSize == 16, instruction == POPA
    DI = Pop();
    SI = Pop();
    BP = Pop();
    ESP = ESP + 2; //skip next 2 bytes of stack
    BX = Pop();
    DX = Pop();
    CX = Pop();
    AX = Pop();
}

Обрати внимание на скип 2-х и 4-х байт в зависимости от размера операнда. Можно было бы написать руками инкремент ESP, и описать функцию POP(). Но в конечном машинном коде тоже был бы инкремент, а в данном месте это КРИТИЧНОЕ замедление: вместо семи операций с индексной адресацией в конечном коде было бы 7 операций с индексной адресацией + один лишний инкремент. Учитывая, что топовые современные камни едва тянут эмуляцию i486*, такие замедления неприемлимы.