для них не знаю, а мой любимый Metal Mutant, при попытке дизасемблирования содержит очень странный кодСообщение от Oleg N. Cher
для них не знаю, а мой любимый Metal Mutant, при попытке дизасемблирования содержит очень странный код
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну, Metal Mutant может быть написан на чём угодно :-) Это как однажды мне попался странный Арканоид для DOS, тоже очень интересный код после дизасма получился. Есть игра Abuse, так она на LISP'е.
Но если брать старые процы и альтернативные асму средства разработки, то нельзя сбрасывать со счетов язык PL/M. На нём были написаны многие утилиты ОС CP/M и вроде бы даже часть самой CP/M, и сам язык PL/M действительно несколько ушёл от асма, хотя и недалеко. Жаль, что сейчас его не используют для разработки игр под ретро.
Кстати, а что на счёт Фортрана и Лиспа? На сколько они (в соответствующей по времени редакции) подходят для разработки игр на (и для) старых платформ?
Ну, тут всё упирается в существующие компиляторы. Лисп язык интерпретируемый, и хотя и были попытки его компилировать в машкод, обычно результирующий код весьма тормозной и немалого размера - язык-то заточен под работу с динамическими структурами данных и сборку мусора. Я не вижу преимуществ Лиспа для разработки под ретро. Можно было бы накорябать какое-то языковое подмножество, и такие попытки уже были - точно был какой-то MicroLisp для Спектрума, но он остаётся на уровне игрушки даже в большей степени, чем Си или Паскаль.
Старинный Фортран смысла использовать в наше время не вижу. С тем же успехом можно использовать Бейсик. Более структурные версии Фортрана есть для больших машин (Fortress), но для старых их нема. Да и зачем юзать неструктурный ЯВУ, если есть структурные и модульные.
Так что PL/M, Cowgol (если хочется "без асма", и то не получится - нужны будут библиотеки, которых конечно же нет).
Я лично для себя выбрал SDCC. С позиций "асма", если использовать встроенный ассемблер, то он привносит некое подобие модульности и структурности, даёт возможность оформить машкодовые процедуры в библиотеку, из которой их можно использовать по мере необходимости, в то же время Си не особо оторван от железа. У самого SDCC по сравнению с другими компиляторами есть плюшки - регистровая модель вызова функций __z88dk_fastcall, стековая модель вызова __z88dk_callee, при которой аргументы из стека вынимает сама процедура. Это маленько эффективнее, чем убирать их вызывающим кодом. Также есть возможность для подпрограмм на асме задать набор использованных в асм-коде регистров __preserves_regs(b,c,d,e,h,iyl,iyh), что теоретически даёт компилятору хорошие возможности по оптимизации. Говорю теоретически, потому что не заметил особой пользы от этой директивы. Хотя душу конечно греет)
С позиций "ЯВУ и чтоб без асма" тут маленько посложнее, потому что всё-таки стековая модель вызова, передачи параметров и локальных переменных берут своё. Ну это традиционно в Си так всегда было. К тому же, работая на Си, постоянно тянет вставить вставочку на асме, ибо без этого никак. Поэтому программы для ретро вряд ли будут такие уж выверенные с позиций хорошей переносимости. Хотя я экспериментировал в этом направлении, и считаю, довольно успешно. Например, вот мой видео-доклад:
Практически "белое пятно" оптимизирующие кросс-системы для ретро-компьютеров, впрочем кросс-системы вообще тоже. А ведь нынешние реалии таковы, что вычислительная мощь современных компов даже для такой казалось бы не архи-сложной задачи почти никак не может быть использована. И все эти сказки, "что роботы делают роботов, а программы пишут программы" так и остаются пока что сказками. В этом плане и Lisp и Prolog, и Python и другие могли бы дать многое, но...кажется кому это надо? Ведь быстрой отдачи не будет! И все же, согласитесь, если нет программ, пишущих программы в автоматизированном( под контролем и вмешательством программиста) для относительно примитивных архитектур, то тем более не стоит их ожидать и для более сложных.
Последний раз редактировалось andrews; 26.10.2020 в 12:19.
Oleg N. Cher(26.10.2020)
Тут уже нужен философский, а не математический подход. Который я применяю при проектировании Языка Образов. Чтоб программа могла писать саму себя, она должна иметь представление о среде и её возможностях. Более того, с учётом что идеальной документации не существует, такая "умная" программа должна уметь учится, то есть исследовать среду и применять результаты исследований и экспериментов на практике...
Oleg N. Cher(26.10.2020)
Да, начинать с формализованного описания архитектуры, представления знаний о ней! Вот я сейчас заканчиваю описание первой версии L60. Вроде бы все учел. Нет, не все! Как смотреть содержимое указателя стека, если вывод на консоль идет через аккумулятор, а в системе команд нет инструкции пересылки содержимого указателя стека в аккумулятор. Значит такая инструкция нужна, и надо ее добавить в систему команд L60 - это "процессор конца 60-х" когда еще не было 8008. Но конечно так не получилось до конца. И в обещанные 2000 логических вентилей я явно не уложился.
Правда это уже даже не программирование программой, а синтез архитектуры программой. Все, что можно определить алгоритмически, можно и запрограммировать. Написание программ алгоритмизируется? Тогда давайте программы, пишущие программы и выдающие в выходной файл линии ассемблера. А человек проверит и оптимизирует, если нет программного оптимизатора ассемблерного кода. Но самое сложное, это конечно "постановка задачи". Какую программу пишем? С каким функционалом, интерфейсом, ограничениями? Где берем стандартные алгоритмы? Как изобретаем нестандартные? Вот последний пункт программе возможно пока что "не по зубам".
Последний раз редактировалось andrews; 26.10.2020 в 13:53.
Не знаю, можно ли это применить в данном случае... Любой алгоритм, это последовательность (хотя что-то можно делать параллельно тем более в FPGA) элементарных операций (действий) над операндами (объектами). Можно, на любом уровне абстракции, описать некие свойства объектов, а действия представить как модификаторы эти свойств. Результат выполнения алгоритма можно как-то оценить, по разным критериям, время выполнения, расходование ресурсов и прочее... Алгоритм генерировать случайным образом, с учётом применимости действия к объекту. При чём это можно делать как бы сверху вниз. К примеру, персонажу надо взять предмет, но он не досягаем в данный момент, значит, к нему надо подойти, походу огибая препятствия. Есть варианты поиска пути, надо будет заодно проверить, какие можно использовать в данный момент) Можно ли это как-то использовать на уровне аккумулятора и регистров CPU и имеющегося микрокода, я не задумывался пока что, но не вижу препятствий, на вскидку...
Самое умное, что я придумал "для практики" стараться описывать алгоритмически то, что я делаю сам.
Ну вот на примере разработки этой архитектуры L60.
1)От чего я отталкивался, с чего оно пошло? Ведь у всякого творческого процесса есть "точка старта" и "зерно кристаллизации" или "результат первого шага".
Содержательная история моей "хотелки". Полагаю, что для любой современной программы это неформализуемо и не подлежит алгоритмизации. Хоть пока придется людям и сформулировать это для программы.
В данном случае в 60-е годы в Ленинграде в КБ-2 Староса была создана новая технология, которые сами создатели назвали "куб памяти". Они придумали, как делать ферритовую память для компьютеров не на катушках с ферритовыми сердечниками, а просто просверливая отверстия в пластине феррита! И получилась на небольшой по размере пластине значительная по тем временам емкость энергонезависимой и относительно быстродействующей памяти. На триггерах память была конечно быстрее, но технология производства микросхем не позволяла тогда иметь много и относительно недорогой триггерной памяти. Пластины с усилителями собирали в пакет и получали "куб памяти" емеостью 1KW. На микросхемах же тогда можно было получить от силы 100-200 триггеров! Магнитофоны же были и во времена гитлера, в 60-е годы в Японии они уже тоже были на микросхемах, но в СССР из-за особого "лампового лобби" всюду господствовали эти чертовы электронные лампы, которые по идее должны были благополучно уйти в небытие в середине 50-х. Транзисторы и микросхемы были для электронных ламп типичной "закрывающей технологией". Между транзисторами и микросхемами нет такой пропасти, как между ними и лампами. А теперь представим, что за тем и этим стоят люди и деньги. Стоят специфически, совсем не так как в рыночной экономике. Поэтому никакие привычные аргументы для смены одним другого не действуют, и наоборот командно-административные механизмы действуют жестко и эффективно. Но ферритовые "кубы памяти" это такой замаскированный удар со стороны транзисторно-микросхемного по ламповому лобби. Ведь и ламповые компьютеры ее могут использовать. В общем в память об этой странной эпохе, которая не раскрыла многие таланты в поколениях 50 и 60-х в СССР, я этим занялся. Проект начался не с экскизной проработки "процессора", а с памяти. Я ее представил трехуровневой.
a) созу на триггерах ( регистры)
б) дозу ферритовая на кубах памяти
в) внешняя на магнитной ленте
и еще была цель создать максимально простую архитекуру, чтобы при реализации на vhdl уложиться в 2000 вентилей. Это бы означало, что в конце 60-х на МИС и СИС можно было бы реализовать ее в виде одной многоплатной корзины( из 8-10 плат).
Затем надо было выбрать устройство для интерфейса данного компа с человеком. Это была эпоха расцвета пишущих электрических машинок, которые могут быть и устройством ввода, и устройством вывода. Позже к этому пришел создатель Apple-I и многие последовали его примеру, включая меня. Но в конце 60-х, кто-то опережая создателя Apple-I мог поступить точно так же. Правда в 60-е вынести с работы электрическую пишущую машину в отличие от 80-х и 90-х было еще невозможно без тяжких последствий, но ее можно было привезти из Японии, если твой отец был капитаном дальнего плавания. А почему было нельзя сделать терминал? В СССР? В конце 80-х? О, об этом можно бы было снять драматический фантастический блокбастер. В общем понятно, что это было для некоторых граждан круче автомобилей "Волга" и "Победа", и даже дачи в Крыму! Чтобы описать все это для компьютера пришлось бы придумать формализацию для описания советского режима тех лет. В процессе разработки я вспомнил про самодельный плоттер из осциллографа. И вот на этом "сорвался"! К черту это поганое советское прошлое и мое убогое счастливое детство. На плоттере я отвел душу. Сделав его многоцветным с многоцветной бумагой. Ведь эмуляция нас никак не ограничивает. Вот это неформализуемая часть разработки. Люди ведут себя нецелесообразно и непредсказуемо.
Ничего принципиально нового в Лиспе или Питоне нет. Пролог может показаться более интеллектуальным, но это специфический пробег механизмом, ищущим выводы из заданных условий, по какой-то экспертной базе данных. Поначалу его работа кажется чудом, потом понимаешь, что тоже - дико неэффективно, грубо, как оценка ходов шахматной партии методом брутфорса. Только скорости и спасают, и вообще делают возможным.
В плане того, как смогли добиться серьёзных уровней оптимизации - я бы смотрел в сторону проекта LLVM. Но там тоже всё закодировано руками, и кабы не на Си. Никакой ИИ программы не пишет, и писать в обозримом будущем не будет. Будут огромные базы и брутфорс. И моделирование на основе этих данных по каким-то спискам критериев.
Истина.
andrews(29.08.2024)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
