Куча говна / Говнокод #24280 Ссылка на оригинал

0

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

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

Запостил: dm_fomenok dm_fomenok, (Updated )

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

  • ava bormand # Ссылка на оригинал 0

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

    • ava roskomgovno # Ссылка на оригинал 0 ⇈

      не только у GBA, первые гоблины спрашивали какой у тебя проц ({286,286,486}) и использовали лупы вместо слипов, а еще так делал лодраннер
      Ответить

      • ava Steve_Brown # Ссылка на оригинал 0 ⇈

        А в некоторых эмуляторах просчитывается даже ход луча ЭЛТ, потому что на это могут быть завязаны какие-то эффекты. Например, в ZX Spectrum можно менять цвет бордюра (каемки вокруг активной области экрана); если менять его несколько раз за кадр, синхронизируясь с разверткой, можно получить полосы.
        Ответить

        • ava dm_fomenok # Ссылка на оригинал 0 ⇈

          А я вот думаю то, что во всех эмуляторах лишь жалкая пародия синхронизации. Невозможно заставить программу исполнять инструкции со скоростью настоящего процессора
          Ответить

    • ava vistefan # Ссылка на оригинал 0 ⇈

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

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

  • ava guest # 0

    Что за хуйню вы тут обсуждаете?

    P.S. думаю, ты - борманд
    Ответить

  • ava vistefan # Ссылка на оригинал 0

    > транслятора в самодостаточную программу

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

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

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

    • ava dm_fomenok # Ссылка на оригинал 0 ⇈

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

      А в чём проблема?
      Ответить

      • ava guest # 0 ⇈

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

        • ava roskomgovno # Ссылка на оригинал 0 ⇈

          >>GB
          >>кинескопный монитор с аналоговым входом)

          ты видел gameboy?)
          Ответить

          • ava guest # 0 ⇈

            Проморгал, с чего всё начиналось. Сбил с толку комментарий про рамку у Спектрума.
            Ответить

        • ava dm_fomenok # Ссылка на оригинал 0 ⇈

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

          Зачем? Я же предлагаю транслировать, а не запускать родной образ
          Ответить

          • ava shit_again # Ссылка на оригинал 0 ⇈

            Ну напиши сам тогда транслятор. Все программисты ведь такие тупые, ничего лучше эмулятора не придумали.
            Ответить

            • ava dm_fomenok # Ссылка на оригинал 0 ⇈

              Да, батенька, программисты такие. Один написал эмулятор - все пишут эмуляторы. Никто альтернативы, которые, возможно, даже лучше, не ищет.
              Ответить

              • ava guest # 0 ⇈

                На самом деле транслировать пытались, но не в полностью автоматическом режиме, а в полуручном: дизассемблировали, потом составляли эквивалентный код на языках программирования, частично переписывали и компилировали. Несколько игрушек таким способом портировано (но я сходу не вспомню их названия).
                Ответить

                • ava shit_again # Ссылка на оригинал 0 ⇈

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

                  • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                    А смысла нет, когда есть 100500 эмуляторов, все ниши уже заняты. Народу не нужны заумные вещи
                    Ответить

                    • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                      А ещё всё это предоставляет только теоретический интерес. Антинаучная фантастика
                      Ответить

            • ava bormand # Ссылка на оригинал 0 ⇈

              > ничего лучше эмулятора не придумали
              Ну в тех же плоечных эмуляторах что-то типа JIT. Оно таки транслирует код в нативный, но кусками и в реалтайме.
              Ответить

              • ava shit_again # Ссылка на оригинал 0 ⇈

                Не всё можно оттранслировать. А dm_fomenok возмущается, что нет транслятора: бинарник_для_архитектуры_А --> бинарник_для_архитектуры_Б.
                Ответить

                • ava bormand # Ссылка на оригинал 0 ⇈

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

                  Эмуляторы же не академики ради науки пилили, людям просто хотелось поиграть в игры с приставок.
                  Ответить

                • ava subaru # Ссылка на оригинал 0 ⇈

                  Ну вообще, все. В общем случае, просто для каждой исходной инструкции генерируешь операции, выполняемые эмулятором. А там, где можешь, оптимизируешь и генерируешь код получше. Никто же не заставляет мапить инструкции одной платформы в другую 1 к 1. Хотя JIT тут наверное лучше, чем статический транслятор.
                  Ответить

          • ava guest # 0 ⇈

            Если бы старые игрушки использовали только API операционной системы, было бы проще: транслируешь вызов setpixel() той игрушки в вызов setpixel() своей системы. Но зачастую в те древние времена программы напрямую писали в видеопамять и в порты ввода-вывода. Транслятор должен быть умным: он должен отслеживать всю цепочку обращений к видеопамяти и к внешним портам, чтобы заменить её на setpixel().
            Ответить

            • ava dm_fomenok # Ссылка на оригинал 0 ⇈

              Зачем? Достаточно пропатчить in/out на обращение к API. И память всю правильно промапить.

              И вот это вот API всё равно не будет эмулятором.
              Ответить

              • ava guest # 0 ⇈

                Кажется, понял. Если оттранслированный код будет напрямую исполняться на процессоре (т. е. будет вызов API из нативного кода вместо чтения опкодов эмулятором), то получим буст пирфоманса.

                Это круто для неинтерактивных программ. В игрушках же придётся ломать голову над тем, как соблюсти оригинальные задержки, иначе скорость перемещения объектов может повергнуть в шок.
                Ответить

                • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                  А разве для задержек не используется вывод в какой-нибудь пустой порт или прерывание (если такие есть)?
                  Ответить

                  • ava shit_again # Ссылка на оригинал 0 ⇈

                    На старых процах для задержек использовали циклы с какой нибудь медленной операцией.
                    Ответить

              • ava shit_again # Ссылка на оригинал 0 ⇈

                Так там ведь не только in/out и обращение к памяти. Такой транслятор должен выделять цепочки команд, понимать, что они делают (а ведь раньше разработчики не брезговали самомодифицирующимся кодом), и транслировать в эквивалентные команды для другой архитектуры, знать все низкоуровневые хаки (например: зависимость от разрядности регистров при вычислениях, или как с развёрткой у спектрума, про которого говорили выше), уметь правильно расставлять слипы где надо. И это только на первый взгляд.
                Если такой транслятор и возможен, то выдавать он будет лишь примерный аналог, а сам транслятор будет неебически сложной программой, и написать его не под силу даже богу тому кто прочел все тома "Искусства программирования" от корки до корки и выполнил все приведённые там задания.
                Ответить

                • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                  А зачем анализ? Заменить обращение к памяти на обращение к API, который сразу поймёт, что кто-то гадит в исполняемый код и просто транслировать записываемое в нужный код целевой платформы
                  Ответить

                  • ava shit_again # Ссылка на оригинал 0 ⇈

                    > зачем анализ
                    Переведи на 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)
                    Ответить

                    • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                      Я ARM не знаю, только Intel

                      PS. В GBA нет всяких там IDT, GDT, LDT. Так что не умничай мне тут. GBA переводить проще
                      Ответить

                      • ava shit_again # Ссылка на оригинал 0 ⇈

                        Это просто пример непереводимой хуйни.
                        Ты говоришь: "зачем анализ". Блять, на GBA, наверное своей НЁХ полно. Изучи архитектуру, и потом уже решай, можно транслировать или нет.
                        Ответить

                      • ava shit_again # Ссылка на оригинал 0 ⇈

                        > Я ARM не знаю, только Intel
                        > GBA переводить проще
                        У GBA проц ARM7TDMI (этого я не знал, только щас посмотрел). У армов система команд конечно попроще, но как ты можешь говорить, что GBA переводить проще, если не знаешь архитектуры?
                        Ответить

                        • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                          Традиционные ARM не знаю, а вот краткий обзор на процессор из GBA смотреть приходилось
                          Ответить

                          • ava roskomgovno # Ссылка на оригинал 0 ⇈

                            ну и как там пиксел выводят?
                            есть-ли там разделение на память и IO как у интела?
                            Ответить

                  • ava guest # 0 ⇈

                    Вот тебе пример из рахитектуры IBM PC: в режиме VGA 640x480, 16 цветов на сегмент памяти 0xA000 отображался не весь экран, а только один слой. Всего таких слоёв было четыре (красный, зелёный, синий, яркость) — каждый слой соответствовал одному биту цвета. Переключение между слоями осуществлялось отправкой команды в порт видеокарты.

                    Например, чтобы зажечь ярко-жёлтый пиксель, нужно отправить этот пиксель в четыре слоя (в красный, зелёный и яркий отправить единицу, в синий отправить ноль), для чего сначала дать инструкцию out, которая мапит на сегмент 0xA000 красный слой, потом установить соответствующий бит в видеопамяти (считать байт по адресу 0xA000 * 16 + (x + y*640) / 8, изменить в нём только бит x % 8, поскольку один байт хранит информацию о 8 смежных пикселях), потом повторить out и запись в видеопамять с оставшимися тремя слоями.

                    Эти инструкции могли следовать в произвольном порядке и вообще не подряд.
                    Ответить

                    • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                      # Эти инструкции могли следовать в произвольном порядке и вообще не подряд.

                      Всё равно не вижу проблему
                      Ответить

                      • ava guest # 0 ⇈

                        Если идёт отправка константы в константный порт, то это можно заменить на вызов функции API, выбирающей слой (она просто где-то в библиотеке пишет в переменную номер слоя). Потом если идёт запись в известный адрес, мы это опять меняем на вызов функции API (которая считывает из глобальной переменной номер текущего слоя и с учётом этого устанавливает пиксель).

                        А если у нас и номер порта, и команда, и адрес памяти вычисляются в реальном времени по жуткой формуле с логарифмами и прочей гадостью?
                        Ответить

                        • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                          Проблемы же нет. Вычислено значение через всякие логарифмы, а потом лежит в каком нибудь r0, нет же проблем.
                          Ответить

                          • ava guest # 0 ⇈

                            Ты хотя бы понимаешь, что для вычисления нужно либо трассировать программу (а это бессмысленно, ибо при каждом запуске могут вычисляться разные значения), либо... писать эмулятор. Оттранслированная программа будет состоять из вызовов mov() и out(), а прилинкованная к ней библиотека фактически будет содержать эмулятор оригинальной архитектуры.
                            Ответить

                              • ava guest # 0 ⇈

                                У тебя будет стоять видеокарта от эмулируемого девайса и маппинг памяти будет совпадать?
                                Ответить

                                • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                                  Замапать не проблема. А такая же видеокарта не нужна, вообще
                                  Ответить

                      • ava shit_again # Ссылка на оригинал 0 ⇈

                        > Всё равно не вижу проблему
                        У меня одного чувство, что ты издеваешься?

                        Пиши, пиши транслятор, раз считаешь, что ты один прав, а все остальные нет. Только дай ссылочку на гитхаб, я хочу видеть твои мучения.
                        Ответить

                        • ava dm_fomenok # Ссылка на оригинал 0 ⇈

                          Что с тобой говорить, если ты не понимаешь мои сообщения, и то, что проблемы, которые ты выдумываешь несущественны.
                          Ответить

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

Переведи на "PHP", guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓