Чтобы проверить архитектуру на практике, пусть и виртуальной, решил написать то что доступно — эмулятор машины Simpleton 3.x, текущий исходник, если вдруг кому интересно, что конечно вряд ли, можно качнуть тут: yadi.sk/d/-PGx1pEBf_O6kw
Сейчас довёл его до уже нормально исполняющего простые инструкции ассемблера, так вот такой код на C++:
m.parseStart();
int line = 0;
m.parseLine( line++, "start R0 = $FFFF" ); // в R0 грузим константу $FFFF
m.parseLine( line++, " R1 = $CCCC" ); // в R1 грузим константу $CCCC
m.parseLine( line++, " R0 -= R1" ); // из R0 вычитаем R1 и заносим результат в R0
m.parseLine( line++, " [ first ] = R0" ); // в ячейку памяти по адресу first заносим R0
m.parseLine( line++, " [ second ] =+1 [ first ]" ); // в ячейку памяти по адресу second заносим инкремент ячейки first
m.parseLine( line++, " R0 = R0" ); // NOP и ноль - эмулятор останавливается на команде NOP
m.parseLine( line++, "first R0 = R0" ); // метка first ячейки с данными 0
m.parseLine( line++, "second R0 = R0" ); // метка second ячейки с данными тоже 0 (DW пока не делал)
m.parseEnd();
m.show();
while ( m.mem[ m.reg[ REG_PC ] ] != 0 ) // nop as stop
m.step();
m.show();
генерирует и исполняет следующий очищенный от C++ код на ассемблере Simpleton 3.x:
start R0 = $FFFF // в R0 грузим константу $FFFF
R1 = $CCCC // в R1 грузим константу $CCCC
R0 -= R1 // из R0 вычитаем R1 и заносим результат в R0
[ first ] = R0 // в ячейку памяти по адресу first заносим R0
[ second ] =+1 [ first ] // в ячейку памяти по адресу second заносим инкремент ячейки first
R0 = R0 // NOP и ноль - эмулятор останавливается на команде NOP
first R0 = R0 // метка first ячейки с данными 0
second R0 = R0 // метка second ячейки с данными тоже 0 (DW пока не делал)
Как видно синтаксис этого ассемблера строго подчиняется С-подобному обозначенному в статье синтаксису.
Код сей собирается, успешно исполняется и даёт после выполнения всех команд такую карту регистров и памяти:
Здесь видно что PC дошёл до 000A и остановился — это где первый искуственный NOP (R0 = R0) — check.
В R0 разница между FFFF и CCCC = 3333 — check.
В R1 — CCCC — check.
По адресу 000B хранится 3333 — это метка first — check.
По следующему адресу — метке second хранится увеличенное на 1 значение в first — 3334 — check!
Можно посмотреть в коды инструкций — адреса (а это между прочим forward reference для которых надо было запоминать адреса которые надо поправить после конца парсинга) 000B и 000C явно видно в ячейках с инструкциями по адресам 0006 и 0008-0009.
Забавное ощущение когда свой ассемблер делаешь виртуальной несуществующей машины. :D
Парсер и генератор кода конечно примитивный — лишь бы откровенных ошибок с подстановкой совсем уж неверных типов лексем не на свои места не было. Например косвенная адресация просто как флаг взводится и сбрасывается при встрече символов [ и ] поэтому такой код будет валидным: [ R0 = R1 ] и эквивалентен [ R0 ] = [ R1 ] (строго говоря валидно и [ R0 = R1
Но тем не менее в мнемониках кодировать весьма удобно становится. :)
Когда еще будет время реализую условия и попробую делать циклы.
byuu конечно расстроится, узнав, что он так и не смог понять SA-1.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.
Автокод, простой язык программирования; система команд некоторой условной машины, способной в качестве элементарных выполнять значительно более сложные операции, чем данная конкретная ЭВМ. Наиболее распространены А. типа 1:1, в которых основной элемент языка (оператор, строка) при переводе на языке цифровой вычислительной машины (ЦВМ) преобразуется в одну команду. С помощью А. типа 1:1 можно составить любую программу, которая возможна в системе команд вычислительной машины. Программирование на А. типа 1:1 эквивалентно программированию на языке ЦВМ, однако более удобно для человека и ускоряет работу примерно в 3 раза. А., отличные от А. типа 1:1, ориентируются не на систему команд ЦВМ, а на класс решаемых задач, значительно ускоряют работу по программированию, но не дают возможности получить программу такого же высокого качества, какое в принципе достижимо при программировании на языке ЦВМ или на А. типа 1:1. В А. (не типа 1:1) основной элемент языка (оператор) при переводе в код ЦВМ преобразуется, как правило, в совокупность нескольких команд. Указать резкую границу между А. и другими (более сложными) языками программирования невозможно. Примерами А. типа 1:1 могут служить А., разработанные в СССР для ЦВМ БЭСМ-6 и «Урал». Пример более сложного А. — А. типа «Инженер» для ЦВМ «Минск».
Алгоритм, заданный на А., перерабатывается в программу ЦВМ с помощью т. н. программы-транслятора, которая может по заданию программиста производить также простейшее распределение памяти, автоматическую компоновку программ из отдельных частей с использованием библиотеки подпрограмм и другие операции.
Во многих системах автоматического программирования А. служит промежуточным языком при переводе с другого языка программирования в код ЦВМ.
Кстати, если вспоминать о бейсике в частности и ЯВУ в целом, то для Manchester Mark I/II было разработано несколько ЯВУ с общим названием Autocode: en.wikipedia.org/wiki/Autocode
Но забавным мне показался второй — Mark 1 Autocode, причём он довольно широко использовался, судя по википедии.
Пример программы:
Что можно интересного сказать:
— одна операция — одна строка
— 18 целочисленных переменных с именами от n1 до n18
— столько вещественных переменных сколько было доступно прочей памяти с именами вида v1..v999
— оператор j7 переходит на строку пронумерованную как 7, после запятой пишется условие
— если нужно обращаться с ячейками памяти как с массивом, то используется конструкция vnx, например vn10 которая означает переменную v… с номером который хранится в переменной n10
Конечно это было прямо несколько шагов вперёд по сравнению с программирование в символах телетайпа.
Замечание об оставлении пустого места между строками много лет спустя повторилось в рекомендации нумеровать строки бейсик-программ числами, кратными 10 — при необходимости можно будет вставить новые строчки. :-)
Ну про инженеров — это я вообще ко всему коллективу работавшему над машиной обращался, там всё-таки согласно википедии 300000 человеко-часов было затрачено даже на предыдущую итерацию Mark I (Manchester Baby) у которого было всего 7 машинных команд (практически эзотерическая машина!) из которых арифметико-логические только вычитание и смена знака числа. Но вообще да, мозговой центр там был сплошь из профессоров и кандидатов наук.
я уже не понимаю зачем там вам нужно что-то перечитывать. что вы собираетесь найти? всё просто так как я констатировал и всё. двойных смыслов в тех фразах нет, это не афоризмы.
Лучше приводить конкретные цитаты, выдержки из текста.
Желательно привести «точные координаты» утверждений, как я просил. Страницу (по нумерации источника), абзац, текст. Связано это с тем что я не могу вычитывать все документы в поиске утверждаемого, весьма лимитировано время...
Назвать Алана Тьюринга британским инженером — это, конечно, пять.
Но если учесть что Тьюринг — один из людей, сформировавший парадигму компьютерных вычислений вообще, я не уверен, что стоит сильно удивляться тому что мышление для современных компьютеров не особенно то и изменилось. Для смены парадигмы нужен ещё один Тьюринг.
P.S.
Раскопал, что такая странная кодировка на самом деле не странная, а просто повторяет кодировку британского телеграфного кода тех лет — вставил картинку в статью.
Я кстати тоже подумал про LTE, но т.к. я современный прог слушаю мало, подумал что м.б. просто у меня ассоциация по незнанию. Очень круто что ты подумал именно про них же.
Ожидал сначала услышать обычный псевдовосемьбит, и был приятно удивлен совершенно другим звучанием. Напомнило чем-то Liquid Tension Experiment по звучанию и настроению.
Сейчас довёл его до уже нормально исполняющего простые инструкции ассемблера, так вот такой код на C++:
генерирует и исполняет следующий очищенный от C++ код на ассемблере Simpleton 3.x:
Как видно синтаксис этого ассемблера строго подчиняется С-подобному обозначенному в статье синтаксису.
Код сей собирается, успешно исполняется и даёт после выполнения всех команд такую карту регистров и памяти:
Здесь видно что PC дошёл до 000A и остановился — это где первый искуственный NOP (R0 = R0) — check.
В R0 разница между FFFF и CCCC = 3333 — check.
В R1 — CCCC — check.
По адресу 000B хранится 3333 — это метка first — check.
По следующему адресу — метке second хранится увеличенное на 1 значение в first — 3334 — check!
Можно посмотреть в коды инструкций — адреса (а это между прочим forward reference для которых надо было запоминать адреса которые надо поправить после конца парсинга) 000B и 000C явно видно в ячейках с инструкциями по адресам 0006 и 0008-0009.
Забавное ощущение когда свой ассемблер делаешь виртуальной несуществующей машины. :D
Парсер и генератор кода конечно примитивный — лишь бы откровенных ошибок с подстановкой совсем уж неверных типов лексем не на свои места не было. Например косвенная адресация просто как флаг взводится и сбрасывается при встрече символов [ и ] поэтому такой код будет валидным: [ R0 = R1 ] и эквивалентен [ R0 ] = [ R1 ] (строго говоря валидно и [ R0 = R1
Но тем не менее в мнемониках кодировать весьма удобно становится. :)
Когда еще будет время реализую условия и попробую делать циклы.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.
(Your text to link...)
Но забавным мне показался второй — Mark 1 Autocode, причём он довольно широко использовался, судя по википедии.
Пример программы:
Что можно интересного сказать:
— одна операция — одна строка
— 18 целочисленных переменных с именами от n1 до n18
— столько вещественных переменных сколько было доступно прочей памяти с именами вида v1..v999
— оператор j7 переходит на строку пронумерованную как 7, после запятой пишется условие
— если нужно обращаться с ячейками памяти как с массивом, то используется конструкция vnx, например vn10 которая означает переменную v… с номером который хранится в переменной n10
Конечно это было прямо несколько шагов вперёд по сравнению с программирование в символах телетайпа.
Спасибо за предоставленный материал.
Но если прям интересно, то тут (документация по UNIVAC I от 59 года): www.bitsavers.org/pdf/univac/univac1/UNIVAC1_Programming_1959.pdf
Это страница 16 со слов: «The arithmetic registers are identical to memory cells except...»
Желательно привести «точные координаты» утверждений, как я просил. Страницу (по нумерации источника), абзац, текст. Связано это с тем что я не могу вычитывать все документы в поиске утверждаемого, весьма лимитировано время...
Но если учесть что Тьюринг — один из людей, сформировавший парадигму компьютерных вычислений вообще, я не уверен, что стоит сильно удивляться тому что мышление для современных компьютеров не особенно то и изменилось. Для смены парадигмы нужен ещё один Тьюринг.
Раскопал, что такая странная кодировка на самом деле не странная, а просто повторяет кодировку британского телеграфного кода тех лет — вставил картинку в статью.