1. C++ / Говнокод #12419

    +13

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    void SetInterruptHandler(int id, unsigned int offset) {
            __asm cli;
            unsigned int *idt = (unsigned int*)0;
            idt[id*2+0] = 0x00080000 | (offset & 0x0000FFFF);
            idt[id*2+1] = 0x00008E00 | (offset & 0xFFFF0000);
            __asm sti;
    }

    Как и обещал в http://govnokod.ru/12413#comment166763, выкладываю исходник говнолоадера, запускающего 32-х битный сишный код с дискетки: https://github.com/bormand/tryos, хотя судя по всему никому это не интересно...

    Если кому-то все-таки придет в голову странное желание это собрать - нужна вижуалка (к сожалению код написан лет 5 назад, когда я юзал вижуалку) и nasm. Путь к nasm прописываем в Makefile, запускаем nmake, полученный floppy.dsk можно скормить виртуалбоксу, или же зарезать на дискету, если удастся вспомнить как она выглядит...

    UPD: Скрин http://rghost.ru/43035733.view

    Запостил: bormand, 14 Января 2013

    Комментарии (23) RSS

    • А что такая странная IDT с побитовыми операциями?
      Ответить
      • По-хорошему надо было флаги расписать константами, или в виде структурки с битфилдами, но я тогда походу торопился, и захардкодил их.

        А почему офсет так распилен - х.з. Интелу так захотелось. В GDT/LDT с офсетами еще хуже, емнип, они на три части напилены.

        P.S. IDT - interrupt descriptor table, если вопрос был об этом.
        Ответить
        • Хех, а я думал IDT в защищенном режиме такая же как и в реальном.
          По мне так говно не у тебя в коде, а в проектировании начиная с 286.
          Ответить
          • >а в проектировании начиная с 286.
            Может @bormand и туда руку приложил
            Ответить
            • И тут оказалось, что Борманд - инженер Интел
              Ответить
              • То-то он мне показался странным: mod R/M в уме декодирует...
                Ответить
          • > говно не у тебя в коде, а в проектировании
            Ну что поделать, обратная совместимость всегда тяготит и превращает код в говно... а тут тем более процессор, и терять все старые наработки под старые процы было бы очень необдуманно.

            Вон они начали с нуля, запилили IA-64, и где он сейчас? А amd64, добавивший режимы совместимости по самый 8086 напротив был успешен, и даже интел теперь клепает процы с такой (правда немного допиленной) архитектурой.
            Ответить
            • > IA-64
              если бы они его на десктопы позиционировали, то, может, толк бы вышел
              а так это был изначально нишевый продукт для узкого круга ограниченных людей
              Ответить
            • > IA-64, и где он сейчас?
              В серверах он.

              Действительно, жаль, что на десктопы не дошел...
              Ответить
              • >Действительно, жаль, что на десктопы не дошел...
                Нечего тут жалеть. Всё произошло очень предсказуемо. Athlon64 разбирали как горячие пирожки. Патчи под винду и луникс сделали за год, в 2005 уже появились x64 ОС, с поддержкой всего 32-разрядного кода.

                Именно поэтому x86 до сих пор жива. Обратная совместимость - это даже хорошо. А AMD кстати дропнула поддержку 3DNow в новых процах, ибо никому нахер не нужно - так что там тоже не догматики сидят.
                И даже Стив Жопс выбросил свой илитный PowerPC и перевёл макбуки на x86 (Core2).
                Ответить
                • > дропнула поддержку 3DNow
                  Плять, а как же мой софтварный рендер, который я когда-то писал? Они ухуели. Тогда мой проц поддерживал только MMX и 3DNow!. У меня просто не было выбора. А теперь дропнули. Между тем 3дноуп всегда работал быстрее ссе. И для операционной системы он всегда был легким и совместимым, так как сохранять его регистры было не нужно при переключении задач. А для ссе нужно. ссеГовно! У меня нет слов просто.
                  Ответить
                  • > сохранять его регистры было не нужно при переключении задач
                    Почему?
                    Ответить
                    • Потому что регистры 3DNow! в регистрах FPU лежали
                      Ответить
                    • Наверное потому что как и MMX физически регистры всё тот же FPU и ОС сама сейвила.
                      Сомнительное преимущество.
                      Ответить
                      • нет, если ос не знала про ссе, то она переключала задачи не сохранив регистры

                        если же ос поддерживала ссе, то она их сохраняла только в том случае, если они поменялись, что удлиняло переключение задач весьма прилично, тк там ни одна линейка кеша

                        а 3дноуп не замедляло переключение потоков, тк все равно фпу регистры сохранять приходилось
                        Ответить
                  • Ты мечтал, что однажды появится проц, на котором твой софтварный рендер будет не тормозить?:)
                    Ответить
                  • Use GPU, Luke!

                    Сейчас даже самые дохлые видюхи в десятки раз мощнее топовых процов. Правда не всегда удастся распараллелить алгоритм так, чтобы удалось засунуть его на GPU...
                    Ответить

    Добавить комментарий