Самопишущийся код

(Перенесено из ветки обсуждения)

Каллисто Классик (2017 год) — уже «самопишущийся код». Да, классический косвенный шитый код из учебников советских времён, но он успешно генерирует такой же код и всё доведено до релиза, как свободное ПО.

В Каллисто-2 будет более гибкий и быстрый шитый код, в том числе подпрограммный. На пути к этому верстовому столбу уже опубликована бета-версия eForth, где я исправил многие тормоза Каллисто Классик и опробовал некоторые современные зарубежные подходы.

Пока генерация родного кода на языке МК в черновиках Каллисто-2 не предусмотрена. И дело даже не в том, что «петля внешнего доступа» ещё никем не реализована и существует только в нашем коллективном воображении. Перенести транслятор в новый шитый код несложно. Тот же eForth, как и SP-Forth, через много видов компиляции прошёл, и ничего. Даже лучше стали.

Можно ринуться вперёд и делать огромные скачки там, где требуется два-три шага. Но последовательное развитие позволяет мне укрепиться на каждом (независимо проверяемом) этапе, подстраивая транслятор под требования платформы и совершенствуя язык, убирая медленно работающие куски кода, выкидывая ненужные и излишние концепции, утяжеляющие среду и загромождающие язык.

Если всё делать и отлаживать, например, на айфоне — из-за его избыточных ресурсов многие «узкие места» Каллисто я просто не почувствую, культурная цепь прервётся. Надеюсь, что к релизу Каллисто-2 петля внешнего доступа уже будет кем-то доведена до релиза и появится на рынке, как товар или продукт. Могу этому помогать, словом и советами.

Тогда в Каллисто-3 будет генерация родного кода. И отталкиваться новый язык будет уже не от Каллисто Классик, а от более продуманного и оптимизированного Каллисто-2. Что принесёт дополнительную экономию и преимущества. Может, к тому времени уже появится ЭКВМ с возможностью писать прошивки — и костыли вроде нашей «нашлёпки» не понадобятся.

всё это нужно, чтобы среда выполнения шевелилась, а это без создания другой прошивки реализуемо только через (само)модифицирующийся код. Что то вроде оптимизирующего транслятора Форта.

Здесь уверенности нет. Надо экспериментировать.

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

Как эти два фактора уравновесят друг друга и что победит, надо смотреть на практике. Можно, например, МК-161 оставить в режиме внешнего доступа, а все данные для самомодификации гонять по SPI. Можно позволить «нашлёпке» считать всю информацию по требующимся само-изменениям самостоятельно через внешний доступ, по команде через параллельный порт.

В пределе весь оптимизирующий компилятор можно вынести в «нашлёпку», а без неё внутренний камень будет всё компилировать в быстрый шитый код по технологии Каллисто-2.

возможно имеет какой то смысл в потоке компиляции слов отлавливать "маркерные" слова работы со стеком
(DUP, DROP, SWAP, OVER ...) и по информации от них перестраивать результирующий целевой код (использования регистров и команд целевой архитектуры) возможно и подстраивая код по входу/выходу в используемых "общих" словах.

P.S. Вопрос: насколько эта "трассировка" может быть эффективна и на какой глубине (окне) повторной обработки входного потока Форт слов. В макро-оптимизаторе SP-Forth используется примерно такой принцип, но может быть не в полной степени и своими "хаками".

тоже можно оптимизировать. И вообще, я бы гаденько заметил, что Форт конечно минималистичен и могуч, но явно не вершина компьютерных достижений. Скорее всего те же самые функции можно поиметь с помощью другого языка, в котором не будет шитого кода (на языке МК он теряет смысл из-за низкой производительности и слишком высокой абстракции от машины). Думаю надо стремиться к той же расширяемости, но сделать язык более отображаемым на язык МК, тогда и транслятор сможет легко преобразовать программу, не забираясь в дебри соответствия механизмам Форта, кроме того не дурно было бы заиметь проверку типов и чтобы сигнатуры функций проверялись при трансляции (конечно и динамическая трансляция т.е. во время выполнения из самой программы - это тема). Короче чтобы снаружи выглядело примерно как Форт (не уверен в необходимости обратной нотации) или Лисп (какие-нибудь sweet-expressions с инфиксной арифметикой для удобства), но внутри работало как транслятор какого нибудь Си. Даже в случае открытой архитектуры вроде STM32, это только пойдёт на пользу, при такой мощи классический Форт становится слишком расточительным и в плане ресурсов (чтобы сложить два числа надо прыгать по словам в лучшем случае джампами) и в плане "мелочности" всяких механизмов (чтобы реализовать структуры и ими пользоваться надо соблюдать странные соглашения и т.п.). Надо чтобы из коробки были плотно интегрированные в язык списки, структуры, строки, и всякие такие вещи, которые позволяют нормально программировать. Между прочим RPL на HP 50g в плане динамических структур и операций с ними до жути неудобен оказался, думаю это тяжёлое наследие стековых заморочек, надо определиться, что некие структуры на стеке являются указателями (ссылками) и не копируются при дублировании, иначе операции нормальными динамическими структурами становятся невозможны.

и какие семантические сопряжения (и их уровень расположения) могут быть в различных (разнородных) языках в рамках одного ПМК?
От верхнего языкового уровня формируется внутренняя библиотека алгоритмов.
А, на верхнем уровне может быть любой язык, но вот его представление и обработку в нижний уровень можно сделать на Форт.
Нижний уровень же при этом вполне может статься и Си (Rust ...) :)
А, вообще, даже в рамках дизайна Форта существуют разные решения.

P.S. А, если необходимо какое то семантическое Форт наполнение, то есть разные возможности для этого и разные проекты со своим кодом. (как один пример http://irdvo.nl/FFL/modules.html)
В том же проекте http://rosettacode.org много каких то задач решены на разных языках.
Группа разных "Форт языков" (конкатенативных) там тоже есть 8th, Factor, oForth ...
oForth, кстати, имеет один из самых лаконично-минимальных синтаксисов. Розеттский код: измеряем длину кода в огромном количестве языков программирования, изучаем близость языков между собой
На Github тоже разнообразных "Форт" представлено много (reda4, pforth, kForth, BigForth ...)
У тогоже Reda4 достаточно минималистический дизайн и подход.
Но да, Форт в каком то понимании может, в силу опыта "классического программирования" не восприниматься широкой программерской аудиторией. Но и на Github имеет какое то порядка 80чел сообщество https://github.com/orgs/ForthHub/people

А, вообще на ПМК должно быть представлено разноообразие подходов к дизайну инструмента для привлечения к платформе большего числа разных пользователей. Даже варианты как, например, https://forthsalon.appspot.com/ :)
Не говоря и о всевозможных Бейсиках.

Даже на TTL компьютер Gigatron хотят портировать какой то Форт https://forum.gigatron.io/viewtopic.php?f=4&t=171

По Форту скорее сомнения в плане классической реализации его рантайма. На мощных платформах аля 32-bit ARM шитый код уже нафиг не сдался, логичнее транслировать сразу в машинный код и вызовы процедур, кроме того базовый уровень языка Форт слишком уж аскетичный, мало людей смогут участвовать в развитии такой платформы. К тому же глянем на историю, при наличии Форта на том же ZX Spectrum под него почти ничего не было создано, я думаю он был мощным расширяемым, но просто не был достаточно эффективен на столь дохлых платформах (примерно по тому что и Лисп не стал популярен на более мощных компах), поэтому народ всё кодил на чистом асме.

Идея делать - базовый рантайм (виртуальная машина аля Java) под множество языков показали себя неплохо. Получается из Форта надо брать не языковые и мета-языковые достижения, а какие то общие принципы построения базовой исполнимой среды, под которую будут транслироваться более высокие языки. У Форта большой плюс в том, что ясно как его реализовать практически на любой платформе, даже с такой прорвой регистров как ARM, но и минус такой же - не эффективно используются ресурсы платформы, как ни крути эффективней будет компилировать все операции так чтобы регистры использовались по максимуму, т.е. инлайнить операции (кодировать сами операции виртуальными регистрами, которые потом подменяются свободными из контекста), а не делать шитый код. В принципе даже это ведь не противоречит самому языку Форт. Семантику можно оставить прежнюю, только стека уже никакого не будет, уровни стека будут связаны не жёстко, а будут привязаны к разным регистрам или даже ячейкам памяти по мере использования (в идеале в момент компиляции куска кода). Потом сам Форт со своими словесными делами представляет конечно гибкие средства мета-программирования, но они какие то слишком уж низкоуровневые и завязаны на шитый код. Получается лучше просто генерировать словесные конструкции, которые потом "нормально компилируются" в регистровые и прочие машинные операции.

Получается уже ближе к Лиспу надо держаться, хотя многое можно и из Форта подчерпнуть. В общем вертится на уме реализация аля Corman Lisp (которая была под Windows X86 опубликована вместе с исходными кодами), там небольшой рантайм, бутстрапинг Common Lisp компилера из сишной реализаци, очень эффективный сборщик мусора. Вот по поводу GC думаю можно поговорить отдельно, ибо всё же ресурсы надо экономить, неплохо бы уметь выделять их почти вручную как в Форте. С другой стороны это чревато всякими сюрпризами, ибо требует от сообщества хорошей дисциплины и микроменеджмента.

А в итоге хотелось бы чтобы в этот рантайм компилялось нечто вроде Бейсика, и нечто вроде Паскаля, и нечто вроде Си и т.д., чтобы не париться сильно за низовую реализацию и оптимизацию низкоуровневых операций. И хотелось бы чтобы модуль написанный на высоком уровне и транслированный в базовый уровень мог спокойно общаться с модулями написанными на других языках транслированными под этот же базовый уровень (как если бы мы всё транслировали в Форт или Лисп). В общем думаю рантайм должен быть нечто вроде Фортолиспа, с некоторыми низкоуровневыми чертами Форта и пластичностью Лиспа.

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

Я сейчас работаю над темой нейронного генератора ПО, того самого который типа должен заменить программистов в новом веке :-) Не думаю что программистам стоит сильно бояться, но вот поднятие таких сложных проектов с кучей аспектов оно может сильно упростить. Это что то вроде экспертной системы, где вместо жесткой логики используется нейросети и достижения в области естественно-языковой обработки (погружения слов, конвееры для разбора и т.п.).

Предполагается, что на начальном этапе мы накачиваем систему объяснениями и реальными проявлениями в виде кода и изменения состояния целевой машины, в результате мы можем иметь те же типы последовательностей что на входе, то есть можем получить код, объяснения на естественном языке, изображения, схемы и всё что можно ожидать от интеллектуального работника, занимающегося направленной трансляцией одних смыслов в другие. Учим эту систему на примере тысяч реализаций и чужих кодов, что может быть, она запоминает объяснения и в то же время определяет свои уникальные условия для каждого случая (т.е. выжимает смысл ситуации, определяет контекст), чтобы потом понять как генерировать код в тех или иных условиях как бы сливая тысячи вариантов действий на разных уровнях в единый структурированный поток, например это может быть поток модулей С, каждый из которых содержит структуры и функции, внутри которых также осмысленно объявлены некие переменные, созданы циклы, условные выражения и т.д. Изменям контекст и получаем новую реализацию.

Я вообще затачивал его под другую платформу, но подумал что МК-161 (152) с его несложной средой является неплохой промежуточной вехой. В принципе если будет получаться на этом, то и всякие ARM и даже IA-64 не будут проблемой. В плане кода ей плевать что жрать, главное чтобы это были последовательности каких то кодов, у нас вполне неплохая библиотека программ для МК (включая советские), вот и первая проба будет. Если бы ей "объяснить" как устроен Каллисто, то она сама найдёт как его улучшить, а потом ещё оттранслирует на любую другую платформу с которой также должна будет "познакомиться", т.е. думаю будет возможен перенос смыслов и знаний по аналогии !!!

Старые игры на языке Форт

TurboForth system for the Texas Instruments TI-99/4A (игры и тесты на Ютуб канале)

|Форт слишком уж аскетичный, мало людей смогут участвовать в развитии такой платформы

С ним, как с ассемблером должно быть самое первое знакомство. (в детских OLPC он вообще прошит в виде стандарта IEEE -1275)
Хорошо, если бы ещё контроллеры поддерживающие его вычислительную модель выпускались.
Тот же GA144 на западе смог венчурный капитал сделать, хоть и не без "претензий" (+ другие железные Форт процессоры - тот же RTX2010). Жаль, что Российские и Белорусские Форт процессоры остались только в применении самих их разработчиков.

| Я сейчас работаю над темой нейронного генератора ПО

Форт использовался в железных компьютерах симуляторах клеточных автоматов (проект CAM8)
Какая то статья по его применению в нейросетях тоже кем то публиковалась. :)
Как нейросети скормить хотя бы текущее количество решённых задач на разных языках программирования в рамках проекта http://rosettacode.org ? :)(человеку, то этот поток информации сложно формализовать)

вырастим искусственный интеллект!!, эволюция по ламарку
Автор тему не осилил (сейчас переквалифицировался из биологога в "монтажники" - присутствует на Хабре в комментариях)
Есть и такой проект Forth for Artificial Intelligence in Robots

P.S. И, да Форт в своих возможностях базовой конфигурации не для "хомячков" (без IDE, большого сообщества, больших массовых проектов применения ...) Он сейчас хорош для задач прототипирования, исследовательских задачах (+ в FPGA применении в качестве вычислительного ядра) при умелом обращении с ним, но с ним ещё надо как то "ужиться" для использования. Поэтому Да, массовых перспектив почти никаких, что в принципе объяснимо.
Некоторое объяснение Форт реалий В некоторых статьях
Но есть же и более менее "хомячковые" Форты - Win32Forth, ?BigForth, ... SwiftForth, VFX Forth ...
На SwiftForth даже кто игровой движок пилит RogerLevy/RamenEngine

USA Fig разрабатывает на базе SP-Forth ForthWin в "закрытой" группе на Фейсбуке. Cайт у этого же автора по Win32Forth

Понравились и игры и вообще ваш интересный обзор. Ну у меня нет задачи заточить всё под какой то язык, скорей наоборот это что то вроде переводчика с любого на любой, даже нейронная архитектура частично от переводчика, частично от чат бота. Вообще я не отказался бы в данный момент от игрового фреймворка на Forth для ZX Spectrum, да ещё бы с примерами применений. Заточил вот ZesarUX под управляемую трассировку кода и памяти, можно было бы разобраться, как оно там работает. В принципе сильно шустрая графика мне не обязательна, если геймплей продумать.

Не знаете что нибудь про SoloForth? С виду заманчиво, много наворотили и ассемблер Z80 встроенный.

| Вообще я не отказался бы в данный момент от игрового фреймворка на Forth для ZX Spectrum, да ещё бы с примерами применений.

Но так как (почти "100" лет в обед) перестал программировать на ZX (и программировал код на Asm) то себя смотивировать на сеё действие не так просто :) (поэтому не загадываю и без гранд-мотивации -:)

Кстати на Github есть ещё и такой проект-начинание A Forth-based Game Boy development kit

реверс-инжиниринг файлов игры Starflight в псевдо Си язык

TileMap проект - Предварительно трассируется игра и её локации объёдиняются в большую игровую карту со спрайтами на этих локациях

В рамках Лисп-ориентированной Zillions of Games Interface запилен и Game: Axiom Development Kit - Forth language

P.S. Из лингвистики есть наследие Тузова С.А. Построение семантически связанных информационных объектов текста
у Тузова есть ещё монография (есть в i-net) и Языки представления данных

Проект с Github - морфологического разбора языка тюрской группы на Форт

статья о Форте на нейронных сетях Programming with a Differentiable Forth Interpreter

А, на форуме Zx.pk реально зарегистрироваться новому участнику?

Шитый код для Форта необязателен. Например, в СПФ компиляция идёт прямо в машинный язык.

Кстати, шитый код не тормоз. Он довольно эффективен по занимаемому месту и шустр. Порой шитый код даже быстрее других решений, т.к. компактен и меньше обращений к памяти происходит. Иногда память — бутылочное горлышко.

Эти вещи — вопрос реализации. Большинство программистов владеет лишь сиподобными языками, поэтому различные виды шитого кода им кажутся чем-то сложным и излишним. Но когда ими владеешь, они весьма эффективны и для каждой платформы можно выбрать вариант шитого кода, наиболее эффективный для неё.

На МК-161 косвенный шитый код заработал так быстро (даже при АИ на ЯМК), что Арбинаде пришлось срочно менять систему оценки для объяснения, почему ЭКВМ это всё равно плохо. :-)

Здесь в одной заметке на примере цикла ШИМ для PIC18 и FlashForth он всего в 2-а раза медленее.
Частное cравнение скорости СИ/ФОРТ.

P.S. Но, разные контроллеры имеют разную аппаратно-командную организацию.
Тот же PIC18 "своеобразен" в своей системе команд и регистров.

Ну для вывода графики в видеоиграх 2 кратная потеря производительности - это катастрофа. Получается производительность теряем, места под рантайм порядка 16K надо. Для больших проектов это не критично, кроме того спрайты можно и оптимизированной процедурой выводить. Для многих жанров остальные недостатки не критичны.

2-х кратное в данном примере. Иногда шитый код оказывается даже быстрее, и МК-161 после взлома может оказаться таким случаем.

Дело в том, что команда Р ПП занимает три шага, а ссылка в шитом коде это просто адрес подпрограммы — 2 шага. Все эти шаги располагаются за пределами камня, и разница в 33% на считывании из медленной внешней памяти иногда оказывается решающей.

Когда шитый код медленней, применяются известные инструменты программирования. Замеряются узкие места и их код выносится в примитивы — реализуясь на ЯМК или даже ассемблере. Шитый код это верхний уровень. Какие слова выбрать в примитивы показывает мастерство программиста.

В Каллисто Классик тормоза идут во время компиляции, уже откомпилированный код работает шустро. А в Каллисто-2 будет ещё шустрее, за счёт применения подпрограммного шитого кода в памяти программ. Это и другие улучшения позволят приблизить время компиляции к 161eForth. Который, видимо, даёт верхнюю границу скорости МК-161 без взлома прошивки и внешнего процессора.

а также бутлоадер через программатор
можно было бы, наверное, в симулятор 51-го ядра загрузить например в программе Proteus (частично скорректировав прошивку)
вместе со схемой калькулятора.
Что бы тогда Семико сказала на такой "финт ушами" :)

P.S. В этой теме один разработчик задал вопрос по вариантам защиты прошивки в контроллере при возможности штатного обновления
http://forum.easyelectronics.ru/viewtopic.php?f=35&t=41392

Прошивки первых МК-152 были отозваны и Новосибирск серьёзно относился к тому, чтобы им вернули старый камень по почте. В последующих камнях активирован бит защиты и ни прошивка, ни загрузчик напрямую программатором не считываются.

Можно ли так поменять бутлоадер, чтобы считать прошивку или залить основную программу так, чтобы считать загрузчик и поискать ошибки там — всё это никто не пробовал. Вообще, серьёзных попыток даже написать свою прошивку в чистом камне никто не предпринимал.

Кстати, я могу пробовать ваши прошивки дистанционно, вторая «Электроника МК-161» для этой цели уже есть.

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

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

Все прошивки когда-нибудь ломают, если к устройству есть хоть какой-то интерес. Но здесь ваша позиция по этому вопросу ясна. Хотя мной и не одобряется — только ленивый не лазал по BIOS’ам и другим прошивкам как иностранных, так и отечественных персоналок. А код советских ПМК вообще вскрывали микроскопом и все «спасибо» говорят. Но дело, как говорится, хозяйское.

Взломом ЭКВМ я не занимаюсь. Моя задача — удобный входной язык для ПМК — и без этого объёмная. И вариантов куча. От того, что конечный вариант Каллисто заработает в новом, разработанном с нуля устройстве, до того, что Новосибирск таки проснётся и сам выпустит что-нибудь более достойное, чем keystroke programming и, желательно, даже лучше Каллисто.

Будет кто взламывать — разумеется, не здесь.

Вот смотрю, почему же игры на спек, написанные на Форте настолько уступают ассемблерным играм ??? Казалось бы логику куда легче прописать, а вывод графики вообще на голом асме оптимизирован. В чём подвох ? Может просто фортеров среди хороших разрабов было мало ?

В последнее время на ПЛИСах всякие HLS должны решать вопросы, для которых раньше только Форт помогал, хотя на младших устройствах HLS наверное дрянь генерит ?

Вот смотрю, почему же игры на спек, написанные на Форте настолько уступают ассемблерным играм ??? Казалось бы логику куда легче прописать, а вывод графики вообще на голом асме оптимизирован. В чём подвох ? Может просто фортеров среди хороших разрабов было мало ?

Ну, так на том же игровом сайте пояснение:
"В Atari пытались использовать Форт по крайней мере со времени выхода 8-битных машин, таких как Atari 400/800. Идея была в использовании компактного языка, в духе современной "платформонезависимой" Java. Увы, реальность оказалась не столь радужной. Landon Dyer, один из Atari-разработчиков той эпохи вспоминает".

"Он (коллега по проекту портирования игры Donkey Kong) изначально хотел все сделать на Форте и не понял, что мы не можем потратить половину памяти картриджа для интерпретатора Форта только ради нашего удобства".

"Прискорбный факт состоит в том, что люди, привлеченные этим языком, кажется, меньше всего способны написать хороший код на нем. Отсюда и несколько катастрофических попыток создания видеоигр на Форте в Atari".

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

У Чака Мура получается писать хороший код на Форте. :-)

Давно подмечено, что Форт работает, как мощный усилитель. У плохих программистов код получается гораздо хуже, у хороших — гораздо лучше.

Проблема же Спектрума в том, что ассемблер Z80 знает куда больше народу, чем Форт. На асме писали тысячи и тысячи игр, на Форте — несколько десятков максимум.