1. Куча / Говнокод #24280

    −5

    1. 1
    Эмуляторы

    Объясните пожалуйста, почему пишут эмуляторы всяких там GBA, но нет ни одного транслятора в самодостаточную программу? И почему все заботься о том, что бы эмулятор работал с такой же скоростью, как и настоящий процессор?

    Запостил: dm_fomenok, 17 Мая 2018

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

    • Поумничай тут, блядь.
      Ответить
    • Во времена этих GBA любили патчить код на лету и завязывать логику на такты. Из-за этих хаков и нужна точность эмуляции.
      Ответить
      • не только у GBA, первые гоблины спрашивали какой у тебя проц ({286,286,486}) и использовали лупы вместо слипов, а еще так делал лодраннер
        Ответить
        • А в некоторых эмуляторах просчитывается даже ход луча ЭЛТ, потому что на это могут быть завязаны какие-то эффекты. Например, в ZX Spectrum можно менять цвет бордюра (каемки вокруг активной области экрана); если менять его несколько раз за кадр, синхронизируясь с разверткой, можно получить полосы.
          Ответить
          • А я вот думаю то, что во всех эмуляторах лишь жалкая пародия синхронизации. Невозможно заставить программу исполнять инструкции со скоростью настоящего процессора
            Ответить
            • а я думаю можно, если ты эмулируешь 4 мегагерцовый CPU на skylake
              Ответить
          • У PC тоже можно было.

            overscan или как-тотак
            Ответить
      • > Во времена этих GBA любили патчить код на лету и завязывать логику на такты. Из-за этих хаков и нужна точность эмуляции.

        И это правильно, ведь про конечную платформу известно абсолютно всё до последней железочки, + гейдев + проприетарщина. Все поводы хачить максимально грязно и при этом не заботиться о поддержке кода и уж тем более о будущих создателях эмуляторов через 30 лет.
        Ответить
    • показать все, что скрытоvanished
      Ответить
      • Наполнил твой анус липкой жижей, проверь.
        Ответить
    • > транслятора в самодостаточную программу

      А что транслировать, скомпилированный код?

      А как этот код будет рисовать на экране игру?
      А как этот код будеть играть звуки?
      А как этот код будет получать от пользователя инпут в виде нажатий на клавиши?
      А с какой скоростью этот код будет выполняться, чтобы правильно воспроизвести поведение игры?

      Добавляем прослойки для всего этого, и получаем тот самый эмуль, либо частный -- сросшийся с конкретной игрой, либо универсальный, для любой игры.
      Ответить
      • # А как этот код будет рисовать на экране игру?
        # А как этот код будеть играть звуки?
        # А как этот код будет получать от пользователя инпут в виде нажатий на клавиши?
        # А с какой скоростью этот код будет выполняться, чтобы правильно воспроизвести поведение игры?

        А в чём проблема?
        Ответить
        • показать все, что скрытоvanished
          Ответить
          • >>GB
            >>кинескопный монитор с аналоговым входом)

            ты видел gameboy?)
            Ответить
          • # 1. К компу будет подключено реальное железо, совместимое с оригинальным (древняя видеокарта и кинескопный монитор с аналоговым входом)?
            # 2. Программа будет работать в монопольном режиме с прямым доступом к железу (т. е. будет запускаться прямо из BIOS)?

            Зачем? Я же предлагаю транслировать, а не запускать родной образ
            Ответить
            • Ну напиши сам тогда транслятор. Все программисты ведь такие тупые, ничего лучше эмулятора не придумали.
              Ответить
              • Да, батенька, программисты такие. Один написал эмулятор - все пишут эмуляторы. Никто альтернативы, которые, возможно, даже лучше, не ищет.
                Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • > дизассемблировали, потом составляли эквивалентный код на языках программирования, частично переписывали и компилировали.
                    dm_fomenok, можешь написать программу, которая будет выполнять эти действия?
                    Ответить
                    • А смысла нет, когда есть 100500 эмуляторов, все ниши уже заняты. Народу не нужны заумные вещи
                      Ответить
                      • А ещё всё это предоставляет только теоретический интерес. Антинаучная фантастика
                        Ответить
              • > ничего лучше эмулятора не придумали
                Ну в тех же плоечных эмуляторах что-то типа JIT. Оно таки транслирует код в нативный, но кусками и в реалтайме.
                Ответить
                • Не всё можно оттранслировать. А dm_fomenok возмущается, что нет транслятора: бинарник_для_архитектуры_А --> бинарник_для_архитектуры_Б.
                  Ответить
                  • Дык всё просто — время разрабов не резиновое. И они его тратили на более полезные вещи, чем полная трансляция кода — эмуляцию железок и таймингов поточнее, хаки для конкретных игрушек если так будет дешевле, чем допиливать архитектуру и т.п.

                    Эмуляторы же не академики ради науки пилили, людям просто хотелось поиграть в игры с приставок.
                    Ответить
                  • Ну вообще, все. В общем случае, просто для каждой исходной инструкции генерируешь операции, выполняемые эмулятором. А там, где можешь, оптимизируешь и генерируешь код получше. Никто же не заставляет мапить инструкции одной платформы в другую 1 к 1. Хотя JIT тут наверное лучше, чем статический транслятор.
                    Ответить
            • показать все, что скрытоvanished
              Ответить
              • Зачем? Достаточно пропатчить in/out на обращение к API. И память всю правильно промапить.

                И вот это вот API всё равно не будет эмулятором.
                Ответить
                • показать все, что скрытоvanished
                  Ответить
                  • А разве для задержек не используется вывод в какой-нибудь пустой порт или прерывание (если такие есть)?
                    Ответить
                    • На старых процах для задержек использовали циклы с какой нибудь медленной операцией.
                      Ответить
                • Так там ведь не только in/out и обращение к памяти. Такой транслятор должен выделять цепочки команд, понимать, что они делают (а ведь раньше разработчики не брезговали самомодифицирующимся кодом), и транслировать в эквивалентные команды для другой архитектуры, знать все низкоуровневые хаки (например: зависимость от разрядности регистров при вычислениях, или как с развёрткой у спектрума, про которого говорили выше), уметь правильно расставлять слипы где надо. И это только на первый взгляд.
                  Если такой транслятор и возможен, то выдавать он будет лишь примерный аналог, а сам транслятор будет неебически сложной программой, и написать его не под силу даже богу тому кто прочел все тома "Искусства программирования" от корки до корки и выполнил все приведённые там задания.
                  Ответить
                  • А зачем анализ? Заменить обращение к памяти на обращение к API, который сразу поймёт, что кто-то гадит в исполняемый код и просто транслировать записываемое в нужный код целевой платформы
                    Ответить
                    • > зачем анализ
                      Переведи на ARM (какой хочешь):
                      segment modes use16
                      
                      ; ...
                      
                      switch_real32:
                      	pushfw
                      	push	eax
                      	push	word ds
                      	push	word es
                      	push	word fs
                      	push	word gs
                      	cli
                      	mov	eax,ss
                      	mov	cr3,eax
                      	lgdt	[cs:real32_GDTR]
                      	mov	eax,cr0 		; switch to protected mode
                      	or	al,1
                      	mov	cr0,eax
                      	jmp	1 shl 3:pm32_start
                          pm32_start:
                      	use32
                      	mov	ax,2 shl 3		; load 32-bit data descriptor
                      	mov	ds,ax			; to all data segment registers
                      	mov	es,ax
                      	mov	fs,ax
                      	mov	gs,ax
                      	mov	ss,ax
                      	mov	eax,cr0 		; switch back to real mode
                      	and	al,not 1
                      	mov	cr0,eax
                      	jmp	modes:pm32_end
                          pm32_end:
                      	mov	eax,cr3
                      	mov	ss,ax
                      	lidt	[cs:real32_IDTR]
                      	pop	word gs
                      	pop	word fs
                      	pop	word es
                      	pop	word ds
                      	pop	eax
                      	popfw
                      	retfw

                      (из исходников FASM под DOS)
                      Ответить
                      • Я ARM не знаю, только Intel

                        PS. В GBA нет всяких там IDT, GDT, LDT. Так что не умничай мне тут. GBA переводить проще
                        Ответить
                        • Это просто пример непереводимой хуйни.
                          Ты говоришь: "зачем анализ". Блять, на GBA, наверное своей НЁХ полно. Изучи архитектуру, и потом уже решай, можно транслировать или нет.
                          Ответить
                        • > Я ARM не знаю, только Intel
                          > GBA переводить проще
                          У GBA проц ARM7TDMI (этого я не знал, только щас посмотрел). У армов система команд конечно попроще, но как ты можешь говорить, что GBA переводить проще, если не знаешь архитектуры?
                          Ответить
                          • Традиционные ARM не знаю, а вот краткий обзор на процессор из GBA смотреть приходилось
                            Ответить
                            • ну и как там пиксел выводят?
                              есть-ли там разделение на память и IO как у интела?
                              Ответить
                    • показать все, что скрытоvanished
                      Ответить

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