Почему старые игры были запрограммированы на ассемблере, когда существовали языки более высокого уровня? - PullRequest
12 голосов
/ 05 февраля 2011

Я заметил, что большинство, если не все игры Nes / Atari и т. Д. Были написаны на ассемблере, однако в то время существовали C, COBOL и FORTRAN, которые, я думаю, облегчили бы правильное кодирование? Так почему же они выбрали сборку вместо этих доступных языков более высокого уровня?

Ответы [ 8 ]

27 голосов
/ 05 февраля 2011

В этих играх были 8-битные процессорные чипы и микроскопическая память около 2 КБ. Этот ответ займет более половины оперативной памяти.

Скомпилированный код не может быть и речи. Даже на 8-битных процессорах с «большой» памятью, как, например, скомпилированный код «64 КБ», было сложно использовать; Обычно его не видели, пока не появились 16-битные микропроцессоры.

Кроме того, единственным потенциально полезным языком был C, и он еще не завоевал мир. В то время было очень мало компиляторов Си для 8-битных микросхем.

Но С не очень помог бы. В этих играх были ужасно дешевые хаки, которые в значительной степени требовали циклов инструкций, зависящих от времени ... например, Y-координата спрайта могла зависеть от КОГДА (при сканировании видео) был записан его управляющий регистр. (Shudder ...)

Теперь был хорошим языком интерпретируемых байт-кодов в то время или, возможно, чуть позже: UCSD Pascal , работающий в P-системе UCSD. Хотя я не большой поклонник Pascal, он был намного впереди всех тех ранних процессоров. Впрочем, он не подходит для игры или не запускается достаточно быстро для игры.

4 голосов
/ 05 февраля 2011

Производительность, производительность, производительность.Игры всегда были направлены на получение максимальной отдачи от оборудования.Даже лучшие компиляторы C, COBOL или FORTRAN сегодня не могут конкурировать с умело созданным кодом сборки.

Как указал DigitalRoss, были также серьезные ограничения памяти, и сборка была единственным инструментом, который позволял получить мелкозернистый элемент управления.

То же самое применяется сегодня, хотястарый ассемблер был более или менее заменен на C ++.Несмотря на то, что существуют языки программирования, такие как Python (которые очень просты в использовании), низкоуровневые языки программирования по-прежнему предпочтительнее для самых требовательных приложений.

3 голосов
/ 05 февраля 2011

Я бы предположил, что был гораздо больший процент программистов, которые оба знают ассемблер и не будут дважды думать о программировании на ассемблере. И даже во времена IBM-PC и AT люди, которые никогда не программировали ничего, кроме ассемблера, все еще были вокруг и могли легко программировать круги вокруг программистов на C и Pascal.

Pascal и C были великолепны (для настольных компьютеров), когда они закрепились, и вы могли позволить себе компилятор, вы были счастливы просто программировать на каком-то новом языке и никогда не слышали об оптимизаторе, вы просто предполагали, что высокий язык уровня превращается в машинный код одинаково с каждым компилятором. Вы по-прежнему легко помещаете свои программы на 5,25-дюймовую дискету. И у вас было достаточно этих 640K, чтобы сэкономить.

Я думаю, нам нужно вернуть или провести больше 4K конкурсов по программированию. Напишите игру для GBA или NDS, но двоичный файл, данные, код и все остальное не может быть больше 4K. Или, возможно, заново изобрести игровой процесс с астероидами, камнями, кораблями, плохими парнями, ракетами, не беспокойтесь о пикселях видео, потому что, во-первых, это не так, а во-вторых, что обрабатывается вторым процессором (хорошо, аппаратный конечный автомат) , просто сгенерируйте команды векторного рисования. Сейчас есть бесплатные компиляторы 6502 C и паскаль-компиляторы, основанные на p-коде, чтобы было легко запустить вывод на 6502 и посмотреть, сможете ли вы получить частоту кадров в реальном времени до 1,5 МГц или что бы то ни было Бег. И вписался в выпускной. Я думаю, что упражнение ответит на ваш вопрос. ИЛИ ... просто создайте интерпретатор p-кода во время выполнения и посмотрите, подходит ли он. (standardpascal.org, ищите компилятор p5).

Горстка Кбайт - это тысяча строк кода или меньше. В программе не было ничего особенного, и ассемблер совсем не сложен, конечно, не на 6502 или других подобных системах. У вас не было кешей, mmus, виртуализации и многоядерности, по крайней мере, тех головных болей, которые мы испытываем сегодня. У вас была свобода выбора любого резистора, который вы хотели, каждая подпрограмма могла использовать свое собственное соглашение о вызовах, вы не выбрасывали огромное количество команд, которые занимались жонглированием регистров, стека или памяти, просто чтобы вы могли вызывать функции стандартным способом. У вас было только одно прерывание, и вы использовали его для опроса и управления оборудованием (обновления видео, равномерно синхронизированный опрос кнопок и другой ввод данных пользователем, опрос детектора четверти слота даже во время игры).

Астероиды выглядят как приблизительно 3000 линий ассемблера. С эффективностью компиляторов сейчас или потом я бы сказал, что вам нужно написать целую игру примерно в 500 строк кода на C, чтобы превзойти это, паскаль с использованием p-кода, я дам вам 100 строк кода, ладно, 200 (не p -код, но оптимизирован для цели, я дам вам больше строк, чем C).

Atari VCS (a.k.a 2600) даже не имел памяти для буфера кадров для видео. Программа должна была генерировать пиксели как раз вовремя, а также выполнять все игровые задачи. Конечно, не много пикселей, но подумайте о задаче программирования и ограниченных размерах и скорости. Для чего-то подобного вы начинаете понимать, сколько инструкций на пиксель, а мы говорим небольшое число. Скомпилированный код высокого уровня будет работать с перебоями и не будет достаточно плавным, чтобы гарантировать время.

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

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

3 голосов
/ 05 февраля 2011

"сделать код проще"

Не имеет значения.

Важна высокая производительность, минимальное использование памяти.

Легкочтобы код не имел значения.

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

2 голосов
/ 05 февраля 2011

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

1 голос
/ 16 мая 2018

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

Чем больше изменений вы сделали в положении, цветили данные в строке сканирования, тем более критичным будет время.В некоторых случаях вам приходилось выполнять запись в регистр определенное количество циклов ЦП после начала строки.Если бы вы были на 1 цикл ЦП раньше или на 1 ЦП позже, результат был бы неверным.

Такая точность синхронизации нецелесообразна при использовании языка высокого уровня.

1 голос
/ 05 февраля 2011

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

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

1 голос
/ 05 февраля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...