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

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

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

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
    Здравствуйте, ·, Вы писали:

    ·>...В общем, неважно, мой поинт в том, что очень часто необходимость выравнивать код по вертикали говорит о том, что 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*, такие замедления неприемлимы.
  • без динамической рекомпиляции эмулятор едва ползает, а с ней почти невозможно соблюсти потактовую точной эмуляции.

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

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


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

    Ф>>необычно.

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

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

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