Каллисто Классик — релиз первого Форта для «Электроники МК-161».
Рад представить вам сегодня Каллисто Классик, входной язык для «Электроники МК-161». С момента задумки прошло 3 года, 2 месяца и 12 дней — и она успешно реализована. МК-161 обрела новый входной язык, день рождения которого сегодня — 7 ноября 2017 года.
Каллисто можно скачать отсюда: the-hacker.ru/2017/Callisto-1.zip (25 Мб)
Завершающее тестирование Каллисто перед публикацией заняло 1 год. Серьёзных проблем в коде транслятора не было обнаружено, поэтому версия 1.0 практически повторяет стабильную версию 1.0rc2, выпущенную год назад. Вместе с тем первые тестеры натыкались на некоторые проблемы, которые нашли своё отражение в документации. Новая глава 14 Руководства даже названа «Решение проблем».
Также была проведена оптимизация кода, включая глубокую оптимизацию межстраничных переходов. Всё это предоставило разработчикам 117 шагов памяти программ для расширения языка. Да, длина Каллисто 9883 шага, а её исходный код занимает 4173 строки на расширенном входном языке МК. Часть нового кода предназначена для облечения будущего перехода на Каллисто-2.
Важные изменения коснулись Руководства по языку (pdf, 9Мб). Все приведённые примеры не просто ещё раз проверены на работоспособность, теперь текст Руководства снабжён иллюстрациями на основе снимков экрана «железной» «Электроники МК-161». В Руководство добавлена страница с формальным описанием языка в РБНФ (18 правил). Описание не является исчерпывающим, но помогает ознакомиться с языком. Также у Руководства появилась красивая обложка. Не стоит забывать про файл words.txt, где каждое из 302 встроенных слов получило описание в одну строчку, включая стековую диаграмму.
Вики по ПМК и ЭКВМ начинает обновляться для полного соответствия с релизом.
Теперь путь для работы над Каллисто-2 расчищен. Работа над первой версией языка выявила узкие места и дала объективные цифры, помогающие улучшить его производительность.
UPDATE. По тесту «пустой цикл» Каллисто 1.0 медленнее заводского языка «Электроники МК-161» в 44,5 раз и быстрее советской «Электроники МК 56» в 18,9 раз.
- AtH's blog
- Log in or register to post comments
- 18819 просмотров
Комментарии
Не отображается правильно кодировка текста
Permalink
http://the-hacker.ru/2017/words.txt
в браузере FF
View → Text Encoding → Unicode
Permalink
Это обычный текстовый файл в кодировке UTF-8, автоматически сгенерированный из исходного текста Каллисто. Он не затачивался специально под браузеры. Его можно скачать и открыть в текстовом редакторе, можно взять из zip'а. В браузерах надо выбирать кодировку, например:
Firefox: View → Text Encoding → Unicode
Safari: View → Text Encoding → Unicode (UTF-8)
EDIT. Сейчас проверил. У меня помогает переключиться сперва на любую кодировку, потом обратно на UTF-8.
Полный список слов Каллисто Классик
Permalink
А какие требования по оперативке для Каллисто, если (+)
Permalink
его портировать на микроконтроллер?
На мой взгляд
Permalink
Судя по объёму микросхемы памяти в МК-161, то порядка 8кб переменные плюс 8кб программа. Прошивка вполне должна влезть в 128кб. Так что, есть смысл портировать только на ARM, вдобавок позволяющий выполнять программу из ОЗУ.
Сайт
Да, пожалуй только arm
Permalink
, вряд ли стоит даже пытаться на atmega368p
для атмега 368 есть отличный готовый AmForth
Permalink
Зачем там Каллисто? Разве что воспроизвести десятичные стеки МК
Да, десятичные вычисления
Permalink
Каллисто — успешный проект по развитию входного языка ПМК на основе Форта. Это язык калькулятора — и не целочисленного, как Форт, а десятичного («плавучка»). Структурные программы для советских ПМК пойдут на Каллисто с минимальными изменениями, см. примеры. В ядре предусмотрены как команды косвенной адресации, так и аналог цикла FL0. Ну и десятичный стек с привычным набором калькуляторных функций, конечно, важен для калькулятора.
Задумано так, чтобы владеющим и любящим советские ПМК было просто освоить и начать писать мощные программы на Каллисто. Просто же Форт найти нет особых проблем, вы правы. На него можно даже натянуть какую-либо библиотеку, превращающую его в компактный язык. Но в Каллисто компактность из коробки.
Но на иной от языка МК поатформе это всё может быттюь трудно реа
Permalink
А почему компактность в форте может быть проблемой? Он такой по проекту. Всякие примитивы привычные для калькуляторов можно и так добавить. По моему мнению Каллисто из коробки ещё слишком низкоуровневый для языка Юзеров, почти уровень SysRPL. ИМХО не помешало бы допилить до юзерского уровня, чтобы HP умер от зависти, у них, я считаю, UserRPL не получился внятным из-за тяжёлого наследия слабых 28s с 16Кб памяти.
Проблем нет
Permalink
Да, Форт очень хорошо лёг на задачу и проблем особых не возникло, как только было решено несколько фундаментальных вещей.
Самое заметное, уже с первых минут знакомства с Каллисто — использование ↑ и ↔ вместо длинных DUP и SWAP. Причём вводятся эти короткие слова теми же кнопками, что в МК-61 и МК-161. В Форте уже были короткие слова @ и ! для считывания и записи в переменные. Я их бросил на клавиши ИП и П, должно быть интуитивно и быстро для владельцев ПМК.
По уровню Каллисто чуть выше и даже проще, чем советские ПМК и Форт. Её потребуется развивать, конечно, в сторону СКМ. Но пока уже существующее хорошо улучшает ситуацию с входным языком МК-161. Я участвовал в дискуссиях по критике МК-161 и мне удалось успешно решить почти все высказанные претензии — кроме, разве что, доступа к ассемблеру МК51, по понятным причинам.
Не воспринимайте как критику самого Каллисто
Permalink
В рамках текущих возможностей МК-1XX Каллисто уже стремится к идеалу, конечно недурно было бы реализовать в голом железе. Я по крайней мере при таком быстродействии не могу с ним работать. Что касается компактности и вообще языков для некого калькулятора мечты, то эта компактность IMHO должна выражаться в размере программного кода, а не в длине отдельных инструкций. Пускай даже отдельные инструкции были бы длинные, но в итоге сама программа короче. Конечно не ценой превращения языка в Brainfuck. Я думаю Каллисто не стоит списывать в этом плане со счетов, ведь это метаязык и есть живой разработчик, такие высокоуровневые конструкции недурно натягивать поверх Форта. Короче не в Каллисто проблема получается, а в том что надо идти дальше, а нет ни платформы ни достаточно быстрой реализации :-(
Требования к памяти
Permalink
Сама Каллисто использует 9883b памяти программ + 7kb байтовая память (регистры и текст) + 8000b десятичные регистры = 25051 байт
К этому надо добавить всю роскошь, что предоставляет Новосибирская прошивка. Это шрифты, bcd-арифметика и функции, файловая система и низкоуровневой ввод-вывод. Оценим всё это в 32-64Кб ПЗУ + 1-2Кб ОЗУ.
Поскольку тысяча десятичных регистров (стек и десятичный словарь) избыточна, всю систему реально запихнуть в 64Кб (49±7Кб ПЗУ + 12±4Кб ОЗУ). Уже 90Кб (74Кб ПЗУ + 16Кб ОЗУ) хватит с запасом, вплоть до полной эмуляции МК-161. Сложная файловая система на данном этапе не нужна — блоки можно реализовать, как сектора. Математические функции и графика тоже важны лишь для разработчиков. Сама Каллисто пользуется только bcd-арифметикой, да и одного шрифта для начала достаточно.
Спасибо за инфо!
Permalink
esp32 (32-битный ЦПУ, 520 KB ОЗУ) вполне мог бы потянуть с большим запасом. Ввод-вывод - через serial консоль, дешевая и сердитая платформа.
Потянет
Permalink
Потянуть-то потянет. Но мне интересно готовое портативное устройство с индикатором и клавишами, под которое я выберу одежду с карманом нужного размера. :-) Клубок из проводов на столе, работающий по кабелю с компьютера, не так возбуждает.
Также в МК-161 остался неиспользованный запас для повышения быстродействия. Хотя и не такой большой, как в esp32. Надеюсь, что к моменту появления отечественной альтернативы МК-161 получится выпустить вполне практичную Каллисто-2.
это всё хорошо, но платка на проводе стоит около тыщи
Permalink
А не 15 тыщ. К тому же на esp32 можно изготовить штуку в корпусе с клавиатурой, и сомнительно что она обойдётся в 15 тыщ. В общем не тянет людей на МК-161, слишком он уже отстаёт от ожиданий типичного пользователя. На esp32 wifi из коробки, энергосбережение, два мощных ядра, что несомненно плюс для современного устройства.
Искренне завидую
Permalink
Искренне завидую наличию времени и сил. Мои серверы-трансляторы по работе отнимают до 10 часов в день, поэтому переписать Каллисто на нормальном переносимом Си не смогу при всем понимании такой потребности. Иначе это будет как в анекдоте: у человека - жена, любовница, а он еще и в туалете рукоблудит на досуге :)
Си не потребуется
Permalink
Спасибо. Но, может, оно и к лучшему. Теоретически Форт можно написать на Си, такие проекты известны. Но правильный путь развития таких языков — метакомпиляция. Когда Каллисто сможет компилировать саму себя (разумеется, не на МК-161), перенос её на другие платформы будет относительно простым делом.
А пока что можно просто заглядывать на обсуждение Каллисто-2 и помогать сократить пару байт здесь, ускорить на несколько тактов там. Это уже будет существенной помощью.
Скорее всего на ARM без Си будет трудно
Permalink
И какие то вставки на Си потом писаться будут гораздо проще и быстрее. Совместимость с Сишным миром - это IMHO великое дело. Но согласен, что сама реализация должна жить и без Си, т.е. всякие адресные интерпретаторы и т.п. неплохо бы вклячить как можно ближе к железу.
Тест эффективности компилятора
Permalink
Здесь вполне обнадёживающие результаты опытной оценки по эффективности сишного компилятора для ARM Cortex-M3, ориентировочно 67-83% эффективности кода по сравнению с голым ассемблером. Я думаю, смысла нет в повышении быстродействия в полтора раза ценой существенно большей трудоёмкости программирования.
Сайт
В Форте обратная ситуация
Permalink
Форт на ассемблере менее трудоёмок, чем Форт на Си. Он компактней и по быстродействию не уступает.
Дело в том, что сам Форт архитектурно рассчитан на то, что его примитивы пишутся на ассемблере. При желании меньшей трудоёмкости этих примитивов может быть несколько десятков. А дальше уже их расширяют определения, написанные на самом Форте. Втыкать туда инородный Си — корёжить довольно красивую теорию и не получить преимущество хорошего высокого уровня Форта, из-за недостаточной гибкости Си. Обычно «Форт на Си» делается теми, кто только приступает к изучению Форта — чтобы упаковать в своей голове принципиально новый подход Форта, опираясь на сишный опыт. С годами такие авторы переходят на более традиционные подходы.
Здесь уместней предусмотреть «переходники» для вызова из Каллисто модулей, написанных на Си и других языках. Тогда народ, кому ближе другие подходы, смогут запускать программы, написанные на их любимых языках, или даже расширять ими систему.
Ещё один из подходов — написать на Си виртуальную машину МК-161, на которой уже пойдёт общий код Каллисто.
Увы, не думаю, что человек может на Форте
Permalink
вручную оптимизировать код также как сишный компилятор
Может помочь улучшить
Permalink
алгоритм оптимизации кода (даже как пример прослойки макрооптимизации в SPF4)
cущественно приближаясь по результатам к производительности Си компиляторов,
но меньшими средствами. И да Форт и Си существенно разные языки с разными аппаратными возможностями
для прямой конкуренции между собой.
P.S. Даже GForth-fast на Си со своими способами ускорения не конкурентен SPF4. IForth, VFX Forth.
Сишный код быстрее ассемблера
Permalink
Сишный код в общем случае быстрее ассемблера, если не делать оптимизацию руками, причем алгоритмическую, а не техническую. Оверхед по размеру исполняемого модуля небольшой. Пример уже был на сайте - тест "Счастливые билеты".
Оптимизация
Permalink
Смотря что сравнивать. Если цель — машинный код, имеет смысл сравнивать оптимизирующие компиляторы. SP-Форт, например, вряд ли уступает оптимизирующим компиляторам Си. При этом примитивы SP-Форта написаны на форт-ассемблере.
Если же цель — шитый код, не совсем понятно, как сишный оптимизатор может оказаться полезным. В самом же Форте есть способы оптимизации шитого кода. Например, при ручной компиляции Каллисто я использовал оптимизированную хвостовую рекурсию и ввёл 8-битные литералы для целых от 0 до 255, которых оказалось не так уж мало.
Самый ад же был ручная оптимизация межстраничных переходов. БП занимает 2 шага, а Р БП три. И пока не откомпилируешь — не узнаешь, можно ли делать просто БП. Перед релизом пришлось выполнить десятки, если не сотни промежуточных компиляций — вычисляя все места, где можно использовать двухшаговые переходы и циклы. Был бы рад возможности автоматизировать это дело, но пока таких оптимизаторов для МК-161 не разработано. Форт-ассемблер Каллисто-2 будет оптимизировать как минимум переходы назад — то, что MK.EXE почему-то делать ещё не умеет.
Что сравнивать
Permalink
Что сравнивать - написано: сишный код оптимизирующего компилятора и его аналог, написанный руками. Без алгоритмической оптимизации ассемблерной программы сишный код почти всегда будет быстрее. Соответственно, транслятор Форта на Си будет быстрее ассемблерного. По виртуальной машине могут быть варианты.
За одним исключением:-)
Permalink
Если сравнивать оптимизированный код (компилятора) и без машинной оптимизации (сразу от программиста) — понятно, что выиграет. Например, оптимизацию переходов хорошо написанная программа лучше и быстрей выполнит, чем я ручками.
Но в случае с оптимизирующим Фортом есть нюанс. Дело в том, что SP-Форт проводит оптимизацию уже после подстановок ассемблерного кода, написанного вручную. Поэтому и результат получается впечатляющим — и не факт, что Си (где человеческой оптимизации нет, только машинная) его обгонит.
Есть и другие тонкости, делающие Си не лучшим выбором конкретно для этой задачи. Начнём с того, что прологи и эпилоги функций в Си и Форте принципиально разные, а исполняемый код должен быть частью структуры данных (словаря). На ассемблере и Форте это всё получается естественно, а Си добавит сложностей и мусора в код.
Например, если каждый примитив + MAX ↑ ↔ и т.п. реализовать функцией на Си, то огромное количество времени (да и памяти) будет уходить на лишние операции «вызвать сишную функцию» и «завершить сишную функцию» — которых ассемблерный вариант избежит.
ежели надо колбасить массивы многоэтажные то соснёт форт
Permalink
Именно жля этого предлагается подумать о сохранении совместимости с Си
Это не исключение
Permalink
Это не исключение, это разные подходы к реализации, и язык реализации тут ни при чем. Если реализовать примитивы в виде вызовов ассемблерных подпрограмм, то все будет точно так же.
А зачем?
Permalink
Зачем реализовывать примитивы на ассемблере в виде подпрограмм, себе во вред? Просто на ассемблере косвенный шитый код (применённый в Каллисто и его предшественниках) реализуется легко и естественно, а на Си неизбежны дополнительные накладные расходы.
Си не обладает гибкостью, нужной для Форта. Поэтому этот язык реализации навязывает свой подход к реализации, далёкий от оптимального. Это как изготавливать наручные часы с помощью топора и кувалды, вместо прецизионных инструментов.
Затем
Permalink
Затем, чтобы не переходить из инженерной практики в плоскость религиозных дискуссий.
"...разновидности шитого кода предлагают широкий диапазон характеристик по скорости исполнения и требованиям к памяти. Поскольку все они логически эквивалентны, то выбор конкретного варианта определяется конкретными требованиями. В реализациях языка Форт встречаются все эти варианты."
Баранов, Ноздрунов. Язык Форт и его реализации. Машиностроение, 1988
Инженерная практика
Permalink
В реализациях языка Форт, разумеется, есть и версии на языке Си. Но они проигрывают по многим показателям традиционной модели, когда Форт пишется на Форте с использованием форт-ассемблера. Так делал и автор монографии, которую вы цитируете.
Даже версии с принципиально другой (отличной от Каллисто) «разновидностью шитого кода», тот же SPF, написаны в таком же стиле. Переносимость Форта достигается не зависимостью от чужеродного переносимого языка (Си), а переводом примитивов на язык ассемблера целевой системы.
Более того, исторически именно Форт стал первой переносимой системой. Си и Юникс появились позже, де факто повторив подвиг Чака Мура в условиях корпорации. Скрещивать эти два независимых подхода к решению одной и той же задачи приведёт лишь к недоразумениям — каждый из них прекрасно справляется своими силами.
Только Си как язык гораздо выше уровнем, чем базовый Форт
Permalink
Чтобы фортом было приятно пользоваться на слепить высокий уровень аля RPL. Вот почему я не в восторге от языка МК, после него ничего не было придумано, а сам подходит только для простейших задач и то, чего греха таить, с непомерными затратами времени и усилий.
И на данный момент ещё проблема
Permalink
Опьимизирующего компилятора Форта для встраиваемых платформ вроде бы не реализовано.То есть придётся собирать на компе, что для Си оправдано массивными расчётами внутри библиотечных модулей чтоб их целиком дёргать из форта). А набортный Форт должен компиляться без всякого ПэЦэ!
Пару байт
Permalink
"Пару байт сократить" пока вряд ли, а вот распечатать корпус для макета ПМК могу при наличии эскиза. Хотя по первому опыту могу сказать, что создавать трехмерные модели не менее трудоемко (возможно еще и FreeCAD - инструмент не самый удобный).
3D
Permalink
Сергей, так Onshape не пробовал?
Пока нет
Permalink
Пока нет, не до этого.
Да, дело не простое, но реальное
Permalink
Я тут несколько пробных заходов слелал, результат в полне в рамках ожидаемого. Только это были макеты корпусов с массивами прорезей для кнопок просто равномерно расставленных. Если всё продумать и спроектировать как надо пол существующую плату, то получится хороший корпус, пригодный для изготовления формы для отливки из жидкого пластика или производства под давлением.Форма эта будет стоит недорого, а копий с одной модно нашлёпать до тысячи если аккуратно.
Здесь проект RPN Forth калькулятора
Permalink
на Javе по моему (чьё расширение файлов pde?)
https://forum.processing.org/two/discussion/24669/forth-calculator-rpn-f...
Нехилого дизайна :)
AmrForth v7 для Sylabs 8051
Permalink
опубликовали на github
https://github.com/wa1tnr/amrforth-v7-F330
FORTH on HP-71b? (Видео)
Permalink
https://novom.ru/en/watch/YGTw5SCwbbM