![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Фортран для БЭСМ-6 это сила
Сижу в центре кремниевой долины и программирую на фортране для БЭСМ-6. На дворе 2016 год, а вот поди ж ты, возникла настоятельная потребность. Нужно извлечь с диска некий бинарный образ и преобразовать в текстовый HEX файл. Надо сказать, Фортран-ГДР отличный инструмент для подобных задач. Мониторная система Дубна, симулятор ОС Диспак, книжки Мазного и Салтыкова-Макаренко под рукой. Решение выглядит так: hexdump.b6
История вопроса следующая. Есть процессор микро-БЭСМ, и для него есть тест системы команд. Тест написан на языке ассемблера, а сам ассемблер имеется в исходных текстах для БЭСМ-6. К ассебмлеру также прилагается линкер. Всё это запускается под мониторной системой "Дубна" на симуляторе ОС Диспак. На самом деле написана эта кросс-система была под ОС Дубна, и пользуется некоторыми её особенностями, поэтому пришлось на скорую руку привинтить несколько дубненских экстракодов к симулятору Диспака. Но это всё мелочи. В конце концов ассемблер с линкером заработали и на диске получился двоичный образ теста, размером около 24 килобайт. Как его извлечь оттуда? Тем более, что хранится он под управлением некой "библиотеки виртуальной памяти", и формат хранения не описан. Но есть API, набор фортрановских вызовов. Не вопрос: пишем програмулину и получаем нужный результат. Теперь можно смело запускать тест на симуляторе Verilog.
История вопроса следующая. Есть процессор микро-БЭСМ, и для него есть тест системы команд. Тест написан на языке ассемблера, а сам ассемблер имеется в исходных текстах для БЭСМ-6. К ассебмлеру также прилагается линкер. Всё это запускается под мониторной системой "Дубна" на симуляторе ОС Диспак. На самом деле написана эта кросс-система была под ОС Дубна, и пользуется некоторыми её особенностями, поэтому пришлось на скорую руку привинтить несколько дубненских экстракодов к симулятору Диспака. Но это всё мелочи. В конце концов ассемблер с линкером заработали и на диске получился двоичный образ теста, размером около 24 килобайт. Как его извлечь оттуда? Тем более, что хранится он под управлением некой "библиотеки виртуальной памяти", и формат хранения не описан. Но есть API, набор фортрановских вызовов. Не вопрос: пишем програмулину и получаем нужный результат. Теперь можно смело запускать тест на симуляторе Verilog.
no subject
no subject
no subject
no subject
10 a=a+1
goto 100
100 a=a-1
goto 10
no subject
no subject
no subject
https://github.com/eatonphil/jsforth
Сейчас наверное имеет смысл реализовать Форт под asm.js.
no subject
Теперь эпоха WebAssembly (отгрузка официально в Q1 2017)
А внутри там очень даже
тортфорт!no subject
no subject
https://cdn.rawgit.com/WebAssembly/wabt/e528a622caa77702209bf0c3654ca78456c41a52/demo/index.html
Исходник в виде AST:
(module (func $addTwo (param i32 i32) (result i32) (i32.add (get_local 0) (get_local 1))) (export "addTwo" (func $addTwo)))Выхлоп:
Видно что в туловище: a b +
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Лет пять назад меня почему-то торкнуло вспомнить незабвенную CM4/CM1420 и RSX11M. Поставил эмулятор, пару месяцев поигрался, вспомнил тот ассемблер, даже начал зачем-то портировать TCP стэк на RSX11M, но потом занялся другими хобби-проектами и охладел.
no subject
no subject
Для RSX11M/M-PLUS я тоже собрал довольно полную коллекцию всяческого софта. К сожалению не смог найти все пакеты которыми когда-то пользовался, но процентов 80% нашел. Как ни странно не смог найти MIM (Микромир), а штука была очень неплохая. Но на западе MIM был не известен, а советских архивов очень мало.
P.S. Кстати, а не будет ли интересно сделать настоящий веб сайт о БЭСМ-6 работающий на Вашей микро-бэсм?
Я думал сделать нечто подобное под RSX11M (отсюда и идеи портировать TCP стэк), но гонять такую штуку внутри эмулятора как-то не айс, а собирать реальное железо было слишком муторно.
no subject
no subject
Микромир для PC - это все-таки совсем другая штука, да и не нужен он мне для PC.
no subject
Еще долгий путь предстоит: процессор, потом Си-компилятор, потом юникс, а дальше уже можно и веб сайт.
no subject
А можно и гораздо проще, без юникса и без С компилятора.
Можно сделать простой веб сервер для родной ОС бэсма, там обьем кода очень невелик. Можно и переписать его на любом нужном языке - хоть на фортране. Основная сложность - это TCP стэк, но тут есть несколько вариантов позволяющих слегка читнуть и упростить это дело :-)
Но юникс на бэсме это тоже интересная затея.
no subject
no subject
>>>Можно пойти аутентично - реализовать не стек TCP, а "аппаратуру сопряжения" в виде какого-гибудь микроконтролера, все-таки памяти маловато будет - только 8Мбайт официально.
Для TCP стека много памяти тоже не нужно - достаточно 32К под буферизацию + сам код. Т.е. все вместе будет меньше 100 килобайт.
Но да, есть возможность сделать нечто вроде "аппаратуры сопряжения" (это и есть тот чит о котором я говорил) - можно взять Ethernet контроллер от Ардуины, а там не просто контроллер сети а есть встроенный TCP стек. Интерфейс у этого контроллера - фактически сокеты, причем он поддерживает и TCP, и UDP, и одновременно может быть открыто 4 (или 8 - смотря какая версия) сокетов.
Именно на такой штуке спокойно делается WEB сервер на Ардуине - классика жанра.
Скорость у него кстати очень неплохая - веб сервер на ардуине выдает поток в пару сотен килобайт в секунду, для микробэсм должно получится нечто аналогичное.
no subject
Интересно, в микро-БЭСМ как устройства подключались?
no subject
Как были сделаны устройства в микро-БЭСМ к сожалению не знаю (думаю что хозяин блога знает), но в худшем случае наверное можно просто сделать библиотеку работающую напрямую с W5500. Для того чтобы гонять WEB сервер на БЭСМе этого достаточно.
В принципе поскольку W5500 предоставляет сокеты (у него и буферизация и все остальное внутри), то даже несколько процессов могут одновременно работать с сетью если договорятся кто какой сокет использует, только доступ к регистрам W5500 нужно будет как-то защищать от переключения процессов (может запрет прерываний использовать на время обмена или нечто подобное).
no subject
Если сделать КВУ для Arduino Ethernet, то можно "красиво" складывать и брать пакеты с данными прямо из памяти машины.
Я так понял что есть исходники ДИСПАКа для микро-БЭСМ, возможно придется сделать модуль для него для обработки сети, но это, конечно, если станет понятно как "генерировать ДИСПАК".
Так же смотрю, что есть достаточно недорогой модуль TFT cо слотом для microSD
А вообще напрашивается "толстая" атмега или pic, которая по аппаратному сбросу шьёт fpga прошивкой с sd карточки и потом выполняет роль КВУ.
no subject
+100
Я бы так и делал.
Вроде есть даже готовые платы где кроме FPGA стоит АРМ или еще какой-нибудь процессор.
Этот же процессор может эмулировать жесткие диски на основе файлов на SD карточке. И он же может эмулировать терминал.
Или если FPGA достаточно большая - то этот вспомогательный процессор можно засунуть в саму FPGA, вместе с микро-БЭСМ.
no subject
Первый вариант: возможность запускать имеющуюся операционку для микро-БЭСМ. Это не Диспак, нет, ничего общего. Генетически это сильно урезанный вариант ОС Дубна. Система обеспечивает примитивный диалог на консоли (через пультовый процессор) и возможность запуска пакетных файлов мониторной системы "Дубна". Файловый обмен обеспечивается пультовым процессором через общую память. В целом не бог весть что. Массовую публику пакетные файлы Дубны вряд ли заинтересуют. Сеть тут не очень понятно как приспособить. Многотерминальность имеется, но имеющиеся диалоговые системы от БЭСМ-6 не пойдут без переделок.
Второй вариант - перенос Unix на микро-БЭСМ. Собственно так и предполагалось в конце 80-х. В этом случае пультовый процессор не особо нужен. В хардвере надо добавить пару периферийных устройств: UART для консоли и SD карточку в качестве диска. Тегами можно пожертвовать. Получится вполне элегантная система.
no subject
А вот что делать с компилятором для unix'а непонятно... Все примеры заточены под современные процессоры где 2-3-х адресная система команд.
no subject
Ну, во-первых сохранился компилятор PCC для Эльбруса-Б. Не самый современный вариант, но сам себя и ядро Юникса он в то время компилировал. Можно его допилить небольшими усилиями.
Среди современных процессоров тоже существуют "странные" архитектуры, особенно в мире DSP, и тем не менее компиляторы справляются.
no subject
no subject
no subject
Или так было быстрее просто?
no subject
no subject
no subject
Грубо говоря, SIMH это аналог virtualbox, а dispak - аналог wine.
no subject
no subject
no subject
А как микро-бэсм по производительности, если например сравнить с ДВК3 или подобными аппаратами?
no subject
no subject
У старших моделей ДВК производительность была вполне ОК - где-то до 1 mips (на 16-битных операциях). Но в 4 раза большая разрядность - это существенно.
А операции с плавающей точкой на ДВК были очень медленные, там по-моему вообще только эмуляция была.
no subject
no subject
ДВК была вообще интересной машинкой. Если смотреть с высоты сегодняшнего дня и зная историю PC, то похоже что главной ошибкой DEC (которую повторили в союзе) - были попытки использовать архитектуру мини-компьютера в микро-компьютере. В том же ДВК была отдельная плата терминала (а то и две - если был КЦГД), вместо того чтобы просто поставить видеопамять с простым контроллером в адресное пространство машины.
Ну и естественно распад союза поставил крест на той линии, хотя в свое время ДВК были вполне ОК.
no subject
С архитектурой особых проблем не было. Если только не считать ограничения в адресации. Но это можно было обойти. В конце концов и Моторола сделала DEC'овский по духу процессор, под который можно и кросс компилировать софт и делать эмулятор. Можно было и самим сделать развитие PDP-11 архитектуры. Но не сделали. Нужно было продавать VAX'ы. Alpha вышли слишком поздно. При этом они сумели прокакать своих операционщиков. Команда, которая работала над RSX и VMS, сбежала в Microsoft. Дэйв Катлер и поныне работает над Осями в Microsoft. Ему за 70 лет, а он строчит код! :)
no subject
Но если смотреть только на технологический аспект, то что бросается в глаза - это упорные попытки тащить архитектуру мини-компьютера в микрокомпьютер. Они все еще не могли привыкнуть к идее что процессор стоит дешево, и его можно нагружать самыми разными вещами - нет необходимости в особо интеллектуальных контроллерах. Видеодисплей - это самый яркий пример, но и остальная периферия была сделана аналогично - очень сложные контроллеры по сравнению с PC.
Адресация была конечно проблемой, но не так чтобы гигантской. Как Вы сказали, вполне можно было обойти/развить процессор в том направлении (собственно - процессор VAX и был таким развитием, только уж очень переусложненным).
Но даже на старом процессоре можно было жить как минимум до начала 90х, когда ограничение в 4 мегабайта памяти машины стало слишком напряжным. А ограничение адресного пространства процесса обходилось - хоть и не элегантно но работало, была такая штука как "резидентные оверлеи". В каком-то смысле это было аналогично подходу сегментных регистров в 80286, но реализовано по-другому. Я когда-то пользовался оверлеями, ничего сложного там нет.
>>>Можно было и самим сделать развитие PDP-11 архитектуры. Но не сделали.
Если речь идет о совке - то там собственно развивали эту линию, и если бы совок не развалился то возможно это бы и продолжилось. Было довольно много игрушек и прочего написано под ДВК. Но совок почил в бозе, вместе со всем что там было.
>>>Alpha вышли слишком поздно. При этом они сумели прокакать своих операционщиков. Команда, которая работала над RSX и VMS, сбежала в Microsoft.
Там все было несколько сложней. Проблема была не с ОС, а с железом и бизнес-стратегией.
Пожалуй единственная существенная ошибка Катлера была в том что VMS была написана на ассемблере VAX, и ее перенос на другие архитектуры был крайне затруднен. Для Альфы они фактически компилировали ассемблер VAX как если бы он был языком высокого уровня, и адаптация для Альфы была весьма нетривиальна.
Если бы VMS была написана на C или чем-то подобном, и особенно если бы своевременно открыли его код, то у VMS были бы все шансы стать массовой workstation ОС вместо Unix. Долгое время VMS была на голову лучше чем Юниксы.
>>>Дэйв Катлер и поныне работает над Осями в Microsoft.
Дейв Катлер балду гоняет, уже лет 10, и вреда от него в последнее десятилетие было больше чем пользы.
no subject
По поводы архитектуры - я частично согласен. Согласен в плане того, что конструктив машин был опять же не оптимизирован под цену. Политика фирмы - делать все внутри компании, но вся внутренняя логистика не была ориентирована на оптимизацию по цене. Это не Commodore, а именно DEC. При этом, они не понимали, что рынок хочет. Младшие машины то у них делались либо как управляющие либо инженерные. Для массового потребителя не было софта, и никто не работал с разработчиками. RSX для своего времени была адекватной ОСью, но опять же, не для массовой культуры.
Я не думаю, что VMS мог захватить мир. Даже если бы они ее переписали на Сях. Для начала там надо было открыть сам проект для публики, как сделали Bell Labs и потом Berkeley. DEC зарабатывала деньги на продаже исходников. Раздавать бесплатно - не их конек.
Под развитием я понимал, что сама DEC могла сделать бюджетную серию процессоров на базе J11. Не сделали. В модульном подходе к архитектуре нет ничего страшного. Собственно, все машины были тогда модульными. И то, что видеоконтроллер, был отдельной платой, - в этом тоже ничего страшного. Также делались и большинство других машин, включая PC'юки. Контроллер только был ни то ни се. Он ведь медленный был, и софт для него не написали.
>Но даже на старом процессоре можно было жить как минимум до начала 90х
Не, процессор умер еще в 80-х. 80286 - та еще фигня была, толком ее никто так и не сумел использовать. В PDP-11 было сразу несколько проблем. Никак не решалась проблема с сегментацией исполняющего кода без оверлеев и извратов. 64К и все. Оверлей, может, и прост, но медленный. Усложняет компиляторы, к тому же. В защищенном режиме 80286 такого не было. MMU - это отдельная фиговина, приделанная к процессору и весьма примитивная. Нужно было простое решение, где адресация в процессоре жила вместе с MMU. Не Rocket Science, конечно. Но не сделали. Если бы они продолжали жить на PDP-11 дальше, то быстро бы сдались перед наступающей Моторолой (68x) и Интелом (80386 в первую очередь).
Если бы Ольсен знал прикуп в начале 90-х, то сделал бы что-то дешевое из железяк других компаний. Как это сделали Intel. Только у DEC это могло получиться более разумно. Инженерная машина - прородитель workstation еще в начале 80-х на 68000, граф адаптером, с поддержкой разные ОС'ей и поддержкой старого софта. На сайте Computer History Museum лежит интервью с разработчиками 68000. Они там говорили, что были вдохновлены PDP-11 и делали процессор по образу и подобию с ортогональной системой команд. Была надежда, что и DEC на них обратит внимание.
no subject
>>>Не, процессор умер еще в 80-х. 80286 - та еще фигня была, толком ее никто так и не сумел использовать.
Ну почему же?
Я помню как еще в конце 80х когда появились PC и была возможность сравнить напрямую CM1420, ДВК и PC - СМ1420 была вполне ОК, она была существенно быстрей XT, и приблизительно на уровне ранних PC AT (с 80286 процессором). ДВК теоретически была вполне ОК, там главная проблема была с мерзейшими винчестерами которые постоянно ломались, и вообще с низкой надежностью.
>>>В PDP-11 было сразу несколько проблем. Никак не решалась проблема с сегментацией исполняющего кода без оверлеев и извратов. 64К и все.
Оверлей - не такая уж большая проблема, это ненамного хуже чем сегментация памяти в 8086. И в принципе на основе этого же механизма (окон в память) можно было сделать схему вроде сегментов у 8086 - нужна была просто поддержка от компилятора. Но даже с простыми оверлеями все спокойно делалось.
Кстати, там поддерживалась такая штука как резидентный оверлей - это когда весь исполнимый код загружается в память, и переключение оверлеев происходит просто перенастройкой менеджера памяти. Работает это очень быстро.
С большой памятью для данных ситуация аналогичная - была поддержка регионов, т.е. можно было аллокировать большой обьем памяти но доступ получался страничным. Это чуть сложней и медленней сегментов, но тоже работает.
>>>Если бы они продолжали жить на PDP-11 дальше, то быстро бы сдались перед наступающей Моторолой (68x) и Интелом (80386 в первую очередь).
Так о том и речь - PDP11 процессор был бы ОК пока память персоналок была в пределах пары мегабайт - как у типичных DOS машин. Когда речь пошла о большей памяти - тогда конечно нужна полноценная виртуальная память и 32бит адресация.
>>>RSX для своего времени была адекватной ОСью, но опять же, не для массовой культуры.
Для персоналок самой подходящей была RT11 - ее собственно на ДВК обычно и использовали. По идеологии она очень похожа на MS DOS, но только сделана на порядок лучше.
А RSX - это был скорее ранний аналог NT. Собственно - WinNT и является дальним потомком RSX - VAX VMS был развитием идей RSX, а WinNT стала развитием идей VMS.
Но для профессионального использования RSX, и потом VMS были очень гут - на порядок лучше чем BSD тех лет.
>>>Они там говорили, что были вдохновлены PDP-11 и делали процессор по образу и подобию с ортогональной системой команд.
Да, 68000 сделан на идеологии PDP11, но только нового поколения. ИМХО 68000 во многом лучше чем VAX - более стройная система команд, без излишеств вакса, и умещался в одном небольшом кристалле.
Кстати, был и микропроцессорный МикроVAX - он собственно и должен был быть (по мнению Dec) рабочей станцией. Но цена была совсем не гуманная.
>>>DEC зарабатывала деньги на продаже исходников. Раздавать бесплатно - не их конек.
А раздавать ОС бесплатно и не требуется - как доказала Микрософт, на продаже ОС вполне можно жить - и жить хорошо. Проблема Dec была в том что они зарабатывали не на ОС, а на очень дорогом железе - как Эппл. И разрешать использовать свою ОС на стороннем железе Dec отказывался категорически.
Если бы у них была ОС для массового чипа (для того же Интела), и если бы Dec начал продавать ОС - то они вполне могли бы стать Микрософтом.
...
Но все это теперь история, которая как известно не имеет сослагательного наклонения. Хотя поразмышлять о том как оно могло бы быть по-другому - бывает интересно :-)
no subject
no subject