Эффективный Форт на регистрах

Я вот думаю, особенно в перспективе использовать 32-битные микроконтроллеры для того чтобы поселить Форт, надо для части основных слов генерировать "регистровый" код не используя стек вообще, особенно организация циклов и всякие проверки.

Само слово должно быть как бы шаблоном для регистров.
Например уровни стека, они же неизвестные на данный момент регистры процессора:
Слово SUM (x y -- sum)
Аргументы: x,y
x->ST0,y->ST1
ADD ST0,ST1 -> ST0

Вышестоящие слова, начиная от какого то начала во время компиляции задают фактические назначения:
: MAIN ()
5 3 SUM 2 SUM ;

Получится R0 = ST0, R1 = ST1 в первом SUM
(8->ST0=R0), 2 -> ST1 -> R1

В итоге реализация будет выглядеть так:
MOV R0, 5
MOV R1, 3
ADD R0, R1
MOV 2,R1
ADD R0,R1

И никаких адресных интерпретаторов, всё со скоростью света !
Если потребуется вызвать "настоящее" слово (пользовательское слово-процедуру), то оно будет полагать, что первые N уровней стека ему переданы в регистрах R0-R(N-1), остальное в стековой памяти. Снова, все инлайновые функции там будут скомпилированы с учётом распределения регистров, а вызовы "настоящих" слов точно также должны производиться с какой то конвенцией использования стека. При этом. Например если стек был такой: ST0=R0, ST1=R1, а встретилось SWAP, то поменяются только назначения регистров во время компиляции ST0=R1, ST1=R0, в итоге после компиляции не будет никакого фактического перемещения данных, следовательно и накладных расходов.

Естественно такой оптимизирующий компилятор потребует памяти, и может не влезть в маленькие контроллеры. Хотя тут нет никакой особой оптимизации, компилятор не рассматривает N вариантов размещения, выбирая самый выгодный и т.п.

Это наверное давно решено, но информация закопана в разных местах. Вот нашёл диссер
"Implementation of Stack-Based Languages on Register Machines" свободно раздают PDF в Google кому интересно.

Были исследования на эту тему. Производительность целочисленного Форта резко растёт при кэшировании 1-2 элемента стека в регистрах, а потом выгоды очень мало из-за постоянного шаманства при доступе, например, к вершине стека. Она всё время в разных регистрах. :-)

Сложность же компилятора повышается. Во время компиляции Форту придётся держать «в уме» современную ситуацию со стеком — сколько верхних элементов находится в регистрах, и в каких именно. Учитывать эту ситуацию при компиляции надо не только в SUM и SWAP, но и во всех других примитивах, кому нужен стек. Это сильно усложняет компилятор. Иногда приходится делать по несколько обработчиков той же арифметики — в зависимости от того, на какие регистры сейчас стек выпал.

Полностью описанная система реализуется только на настольных ПК. Она подразумевает компилирование не в шитый, а сразу в машинный код, что сильно ограничивает транслятор. Мы выигрываем в скорости, но проигрываем в объёме откомпилированных программ. Например, при компиляции в шитый код SWAP и + занимают всего два байта — а уровень машинного языка на МК-161 там, где хранится откомпилированный код (за пределами камня) недоступен. Форт на настольном ПК работает достаточно быстро, скорость там не самое главное.

Ещё надо учитывать, что на ПМК стек содержит числа с «плавучкой» — их так просто в регистр камня не засунуть.

В Каллисто-2 вершина стека будет вынесена в отдельный регистр — скорее всего, RC. К ней будет доступ без косвенной адресации, что слегка ускорит примитивы вроде 1+ и усложнит некоторые другие.

Да и фиг с ним, пускай будет сложным, примитивными компиляторами уже сыты по горло. Что касается обмена регистров и т.п. это всего лишь шаблоны. То есть SWAP : ST0 <-> ST1 - обменять текущие назначенные регистры между собой.

Некоторые вещи будут невозможны, например когда стек наполняется динамически (хотя это редкая фигня). В регистровой реализации SWAP вообще не будет занимать места. Настольные ПК идут лесом, там Форт не нужен, там уже есть Java и .NET машина и прочие машины :-)

С плавучкой в Форте как то всё гадко. Один вариант, засовывать плавучие числа в спец. стек, а в основном как то метить, что это плавучее число с плавучего стека. Вообще пока не ясно как иным кроме тэгов типов способом можно узнавать на стеке хотя бы основные примитивы:
BCD целое, BCD плавучка, BIN целое, BIN плавучка, Строка, Массив (многомерная матрица), Вектор, Список, Пользовательский объект (как его печатать и оперировать специально объявлено), и может быть - Графический объект (растр), Бинарный массив (байтовый файл).

В HP используются именно тэги типов, в большинстве Лиспов тоже. Это применимо только на машинах не менее 32 бита, иначе в регистр влезет только тэг :-)

Я за динамику и полный интерактив, но похоже низкоуровневый особенно арифметический код лучше компилировать вчистую в машкод, то же касается массивных циклов. Для MCS-51 вы можете сделать два компилятора, один на борту, другой на ПК, будет оптимизирующим кросс-компилятором (так кстати все и делают). Запрототипировал задумку, потом загнал на ПК, скомпилировал с полной оптимизацией, и в релиз :-)

Дело в том, что решение SWAP поменять два регистра "в уме" влияет на следующее слово. Оно должно брать вершину стека из другого регистра. DUP тоже заставит перетасовывать регистры, кэширующие стек.

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

Именно что следующее слово возьмёт эту вершину там где скажет компилятор. Если это "честное" слово, вызываемое через адресный интерпретатор (слова могут вызываться и динамически), то для него среда предварительно "нормализуется", но это для каких то жирных слов (процедур) верхнего уровня. Зачем пользователю перепрошивать камень ? Базовые то слова как были однажды скомпилированы, так и останутся. А новые будут не в камень добавляться, а во внешнюю память. Вручную нельзя это оптимизировать, т.к. накладные расходы на адресный интерпретатор и прыжки туда сюда всё же не малые, правда экономия места на шитом коде, но для арифметики и массивных циклов - это катастрофа. А калькулятор для чего нужен, чтобы вычислять что то.

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

обычно кэшируется вершина стэка в один регистр и это фиксируется для написания ассемблерных слов или ассемблерных вставок.
В SPF4 это EBX (если не напутал), а в VFX это EAX (для ARM наверное тоже один регистр)
При этом SPF4 проводит потоковую макро оптимизацию выискивая в потоке определённые шаблонные комбинации и заменяет их уже на регистровые вычисления. Из ~120Kб исполняемого файла примерно больше половины это макрооптимизатор. Но даже бинарник при этом можно сжать архиватором до ~25Кб. В VFX оптимизатор вроде уже сделан по классике. В IForth неизвестно как проводится оптимизация. В GForth (ядро на С) тоже задействованы какие то техники оптимизации.
http://www.mpeforth.com/arena/benchmrk.fth Бенчмарк разных Форт систем использующих техники оптимизации (и разных их версий)
http://www.mpeforth.com/arena/mm.fth Тест плавающей арифметики.
https://web.archive.org/web/20070111200500/http://www.forth.org.ru:80/~a... (SPF3, SPF4 2003года в сравнении с Си компиляторами на некотором количестве тестов)

Много полезной информации. Думается для современных пмк сотня килобайт на компилятор это приемлемо.

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

P.S. Можно и другие коммерческие Форт системы дизасемблировать и провести построение графа программы :)
(но разбирать структуру кода программы надо с помощью ещё каких то автоматических средств)
C C то SPForth (c основой http://www.mpeforth.com/resource-links/downloads/#papers в конце страницы) тоже экспериментировал (С библиотечный основной рантайм был на Форт), но штатный оптимизатор SPF4 уже не смог справится с таким издевательством, а на VFX эти тесты не проводил.
Ресурс, кстати, перепрограммирования флэш контроллера очень большой поэтому можно смело использовать режим самопрограммирования в процессе отладки и периодически возращаясь к базису зашитого ядра (через слово Marker )

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

Прошивка камня это меньше 64К двоичного кода. Не знаю уж, зачем для неё городить оптимизирующие компиляторы. ИМХО её вполне можно ручками на ассемблере написать. Проведя один раз самостоятельно любую оптимизацию, какую можно.

В 51 ядре нет регистров плавучки. Так что регистровая оптимизация стека данных не получится. Её можно продумать для x87. Но цель настольной версии — компилировать версии для 8051 и языка МК. Она одноразовая и отдельно оптимизировать её — только время терять.

В версии на языке МК можно разместить вершину стека в регистре, так это и будет. Но там весь стек хранится в регистрах. Указатель стека в R3 просто бегает по десятичным регистрам туда-сюда, вот и весь стек.

Нельзя оптимизировать руками неизвестный юзерский арифметический код. А не юзерский (ядро Форта) тоже негоже делать тормозным, как там сотни слов руками оптимизировать не представляю (порядок вызовов важен). По сути полезней было бы потратить 64K на минимальное ядро, которое умеет хорошо компилировать прямо на борту, а остальное вообще хранить на внешнем Flash, включая юзерские дела. Тем более что обычный Форт это дело уже пройденное, а настоящий хакерский вызов - это оптимизирующий Форт, на котором можно и более высокие языки построить без тотального торможения (как случилось с языком МК->Каллисто). Какой нибудь Паскаль будет транслироваться в Форт, затем компилироваться и быстро выполняться. И всё это на небольшом пятачке МК-161, вот это был бы вызов. Жаль эта хреновина тяжело перешивается, я купил программатор, пытался прошить несколько камней (более свежие модели W78LE) по ногам вроде совместимы, но ничего не получилось. А на нынешнем этапе нет смысла тратить время на МК-161, производство которого уже точно загнулось (судя по ценам) - жизнь коротка.

Какие оптимизаторы в эти 64К не кодируй, они не смогут оптимизировать машинный код за пределами ПЗУ камня — просто потому, что оттуда невозможно запускать машинный код. Только шитый код.

«Обычный» Форт это не пройденный этап. Он только начался. Торможение в Каллисто 1.0 не «тотальное». Выявлено, где оно происходит и именно это должно быть устранено в Каллисто-2. Кстати, там планируется полуавтоматическая оптимизация хвостовой рекурсии в шитом коде.

Поздравления с программатором! Это самое начало. Теперь нужно заказать с Али настоящие W77LE516P, и можно присоединяться к экспериментам.

И я забыл, что там засада с записью в память программ и самопрограммирования Flash вроде бы нет (в AmForth такая компиляция возможна на AVR не смотря на гарвардскую архитектуру, т.к. он самопрограммирует свою Flash ППЗУ).

Я так и не понял работает ли программатор, закинул в долгий ящик его, ни одного чипа прошить не удалось, родной из МК-161 я пробовать побоялся. Уровни напряжения на программаторе прозванивал, ноги проверял - вроде всё было нормально. Есть ещё нюанс - на программаторе панелька под DIP, а эти чипы PLCC, я купил переходник и вроде бы проверка по даташитам показала, что все ноги правильно разведены. Может быть родные W77LE516Р прошились бы. Кстати можно ведь и похулиганить - зарядить туда какой нибудь эмулятор W77LE516Р сделанный на ПЛИС или микроконтроллере :-) Ибо отлаживать на старинном W77LE516P без JTAG и прочих удобств - это тот ещё геморрой !

Если бы по цене ST-LINK раздавали вот такие эмуляторы отладчики:
http://www.phyton.ru/development-tools/80c51

Заводские W77LE516P, разумеется, лучше не трогать. Обычными средствами оттуда прошивку не достать. Возможно, их реально переписать — но если затереть родную прошивку, то не факт, что получится восстановить дефолтовые МК-161. Для шитья только новые кристаллы.

Да, я тоже шью W77LE516P через переходник с dip-корпуса. Успешно. В том плане, что программатор обратно читает, что я записал. Пока не удалось записать в камень такой код, исполнение которого удалось бы заметить на МК-161 — но это в ближайших планах.

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

Делать ISP через APFLASH (пункт 15.2 в datasheet) просто для того, чтобы Форт можно было автономно программировать в кодах, видимо нет смысла. Лучше прошивку заранее загрузить полезным — bcd-библиотекой, шрифтами, алфавитной клавиатурой, последовательным и параллельным портами, таймерами, звуком, файловой системой и т.п. А пользователям обеспечить хороший высокоуровневый доступ ко всему из шитого кода.

У меня большое подозрение после прочтения примеров самопрограммирования из даташита, что у них нет постраничного стирания и записи, либо стирается весь APPFLASH либо ничего. Самопрограммирование отлично используется в AmForth и там отличные библиотеки в прошивке.
Высокоуровневый юзерский код может содержать арифметику и массивные циклы, тогда о производительности можно забыть. А если их компилировать в FLASH то становится доступным даже машинный код. Хотя в AmForth у них не хватило памяти для такого компилятора. Но его самого как раз можно было бы хранить в другом месте в виде шитого кода с ссылками на компилированные слова. В общем беда с этими 8-битными гарвардскими уродцами. Не вижу причин мучаться и придумывать для них что то, лучше переходить уже на STM32 или MSP430.

Вот я думаю, а нельзя ли из штырьковых разъемов сделать переходник, который бы хорошо сидел в колодке для PLCC44 ??? Тогда можно в этом калькуляторе (я смотрел место там есть) в принципе приделать совершенно другой микроконтроллер, например тот же STM32 и забыть мучения с MCS-51 как страшный сон. Мой первоначальный план был такой - взять дохлый камень в корпусе PLCC44 и к его контактам подпаять проводки так чтобы его можно было вставить в колодку, а проводки ушли бы вверх, в итоге там такой адЪ получился, что я бросил эту затею. А теперь увидел на этом их внутрисхемном отладчике переходник, блин, там же штырьки вроде торчат самые обычные, почему мне не пришло в голову растопырить штырьки в 4 стороны !!!

Что-нибудь из такого, наверное, надо

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

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

Оставляем от МК-161 корпус, индикатор и клавиатуру. Заменяем материнскую плату (её называют «плата контроллера») на свою аналогичного форм-фактора. Где любой процессор, любой объём памяти и любые интерфейсы, вплоть до USB и SD.

Когда будут разработаны и налажено производство своего корпуса с клавиатурой и дисплеем, можно будет полностью открепиться от негостеприимного Новосибирска. Отстрелим последнюю ступень. :-)

Похоже и это не новая идея если поискать на aliexpress
по примерно такой фразе "Калькулятор Чехол Для Iphone"
Вот же блин маркетинг :) Дизайн и наполнение тоже разнообразное.

P.S. Или это только имитация? (хотя не похоже)
Некоторые очень брутально смотрятся. :)

Тут наоборот и при чём здесь айфон? Здесь не в чехле начинка с калькулятором, а «чехол» от МК-161 предоставляет клавиатуру и индикатор для собственно самоделки-калькулятора.

Поскольку к вычислительным мощностям калькулятор не так требователен, в качестве сердца контроллера имеет смысл использовать не «айфон», а отечественный камень — дав дорогу разработчикам процессоров. Об этом здесь долго говорим, моя позиция не изменилась.

В принципе, учитывая конскую цену на плату нецелесообразно использовать ничего из этого набора, побаловаться или для отладки неплохой вариант!

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

Когда будет разработан корпус, можно будет заменить и его. Тут я желаю удачи, но несколько скептичнее. Ведь аж 10 лет назад была выпущена «Электроника МК-152» и за всё это время единственная выпущенная альтернатива это «Электроника МК-161» того же производителя.

Ха! СЕМИКО стоит выпустить комплект для отладки приборов без контроллера, корпуса и кнопок :-)
Это и будет та самая штука которую мы сейчас медленно разрабатываем + корпус и кнопки.
Не поняли они любителей, большинству нужна была отладочная плата с клавиатурой и экранчиком, а не готовый калькулятор !

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

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

Новосибирск сделал всё верно. Возможно, можно сделать лучше, но даже уже сделанное ими никто пока не повторил ни в России, ни на Украине, ни в Белоруссии. Собственно, давление на них именно потому и идёт, чтобы не выпендривались и жрали зарубежное, как все остальные.

Обычно корпус из какой нибудь коробки клепают. А в нынешнем виде оно недалеко от любительского проекта ушло. Насчёт "никто не повторил" - это про востребованность неуловимых Джо, никакой надобности ЭТО повторять нет. Какое ещё давление на СЕМИКО ??? В чём оно выражается ? Всё совершенно наоборот, отечественное есть невозможно, ПРИХОДИТСЯ не выпендриваться и жрать зарубежное. В МК-161 много избыточного и нет необходимого для ПМК. Например микросхема АЦП за 200-300 рублей есть, линия 12 вольт для связи с компом есть, а слота для карты памяти нет (хреновины в виде LPT ключей не предлагать). Огромный промышленный разъем на ПМК не нужен. И где вы горах будете заряжать аккумулятор, этот приборчик жрёт до пол ампера !

В горах я заряжал МК-161 от солнечных батарей. Большой массив солнечных батарей питал скромную электростанцию, которая снабжала электричеством наш монастырь.

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

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

Это, чем вы занимаетесь, и называется созданием атмосферы нетерпимости к ЭКВМ.

http://www.ebay.com/itm/PLCC44-PLCC44-Connector-for-programmer-8051-emul...
С виду такой можно спаять из гребёнок самому и более компактный

В свете имманентных проблем Форта, вспомнил про Лисп машины. Там была аппаратная поддержка сборки мусора и тэги типов.

А это же может решить проблему производительности динамических языков, к которым можно и Форт отнести. Если процессору скажут XXXX YYYY +, насколько я понимаю при наличии тэгов типов и данных в регистрах, операция + в тот же такт выполнит (начнёт выполнять) нужную инструкцию.

reg [32:0] input1;
reg [32:0] input2;
reg [63:0] alu_out;
wire cvtClock;

always @(posedge clk) begin
  case ({tag_1,tag_2})
   4'b0000 : assign {carry,alu_out} = input1 + input2; // int + int
   4'b0101 : FloatAdder(input1,input2,alu_out,carry); // FBCD + int
   4'b0100 : begin // FBCD + int
                   IntToFloat(input1, alu_out);
                   input1 <= alu_out;
                   FloatAdder(input1,input2,alu_out,carry);
             end
  endcase
end

Обычно выбором занимается интерпретатор или рантайм, это занимает нцать тактов.

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

Это конечно FPGA и не самые тощие. Аппаратный сборщик мусора может быть реализован как сопроцессор для контроллера.

Первая идея годна, но не для ПМК.

Приведённый код даст серьёзную экономию только для сложения целых. FloatAdder() занимает столько тактов, что экономия с гулькин нос — тем более, что «типы» в Форте это просто считывание из поля кода адреса обработчика FloatAdder вместо IntegerAdder. «Имманентные проблемы Форта» сильно преувеличены.

На нижнем уровне (прошивка) код сам знает, где складываются быстрые целые числа и может обойтись без аппаратных извращений. Тэги нужны только для реализации верхнего уровня, где пара тактов погоды не делает — но калькуляторам критична лишь быстрота плавучки. Целочисленный тип реализуется как десятичная плавучка (упрощает входной язык по сравнению с «настольными»), т.к. миллионы быстрых сложений это больше для микроконтроллеров и промышленности, чем для бытовых, научных и инженерных вычислений на ПМК.

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

Аппаратный сборщик мусора поддержу. Размышляю про ПМК мечты, изучаю Оберон — всё же это именно калькуляторное, делать alloc() и не делать free(). Экономит нажатия на клавиши, текст на экране дисплея. При этом интересно и полезно, что такой подход совпадает с развитием компьютерных наук.

Можно параллельно разрабатывать архитектуру входного языка и аппаратный сборщик мусора.

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

Сборка мусора в современном её исполнении нужна для снижения порога входа в программирование людям, которые не в курсе, как устроен компьютер.

Если вы когда-нибудь дойдете до прошивки, позволяющей на входном языке манипулировать объектами, простого счетчика ссылок хватит для всех целей управления памятью.

Сборка мусора в современном её исполнении нужна для снижения порога входа в программирование людям, которые не в курсе, как устроен компьютер.

Примерно такие же аргументы в своё время приводили противники калькуляторов (сторонники вычислений «в столбик»). Фортран натыкался на такие же возражения от тех, кто гордился своим умением программировать на ассемблере.

Развитие компьютерных наук как раз делегирует часть рутинной работы (вроде освобождения памяти от неиспользуемых переменных) компилятору. Понятно, что среди обученных по устаревшей программе совершенствование парадигм вызывает внутренний протест — зачем новичкам такие упрощения входного языка, когда наше поколение корячилось и корячится по старинке? Пусть тоже «жизни понюхают» на C++, чтобы «мёдом не казалась». :-)

Сборка мусора снижает порог входа, но не спасает ни от проблем занятых "кем-то" ресурсов, ни от ошибок null pointer exception, ни от утечек памяти, вызванных хранением ссылок где-то в глубинах "говнокода" или в соседних потоках. Проблемы откладываются на потом. Чтобы разрешать их программисту все равно приходится подтягивать уровень к пониманию механизмов управлению памятью в программах.

В языки с GC вводятся элементы, призванные явно управлять освобождением памяти (using и IDisposable в Сишарпе).

На досуге попробуй поиграться с простым тестом производительности, когда создаются и освобождаются сотни тысяч объектов (разбор DOM, например). Потом сравнить результаты.

Мой совет, держите лучше такие «перлы» при себе. Если ссылки увязли в «говнокоде», предлагаемый вами счётчик ссылок ситуацию не спасает.

Вы боретесь с ветряными мельницами, как в своё время противники Фортрана. Никто из дееспособных людей не станет утверждать, что изучать механизмы управления памятью — плохое занятие. Точно также, как использование «транслятора формул» в 1960-ые не отрицало владение ассемблером и умение кодировать математические формулы вручную.

То, что консерваторами воспринимается, как «снижение порога входа» на практике означает доступность более сложных задач для формализации в виде программы на Обероне. Когда становится проще перевозить грузы, можно увеличить грузопоток — это тот же путь, который позволяет нам сейчас считывать с диска и выводить на экран не страничку печатного текста (как в 1980-ые), а многостраничные книги с иллюстрациями.

Счетчик ссылок, как написано выше, является не решением проблем сборки мусора, а простой реализацией ЖЦ объекта, разделяемого между несколькими владельцами. Простой, но ненужной для ПМК, покуда его входной язык не начнет оперировать объектами вне стека. Использование же для ПМК реальных механизмов сборки мусора (и вытекающей из нее многопоточности!) - не снижение порога входа, а стрельба из пушек по воробьям ввиду очередного приступа маниловщины у прожектеров.

Как хороший компилятоп в массе уделает любого ассемблерщика, так хороший современный сборщик мусора + компилятор уделают всех ваших любителей смартпоинтеров и прочего окаменевнего г мамонтов.Не на хэллоуоурдах естественно.

Сборка мусора в ПМК только рассматривается. Меня она привлекает упрощением входного языка и соответствием научной разработке — Оберону.

«Многопоточность» при аппаратной реализации сборки мусора (успехов Ватнику) будет естественной реализацией, а в Форте она была чуть ли не с рождения языка. В Каллисто она не реализована, но следы (переменные USER) остались. Эти «пушки» не страшнее, чем анимация раскрытия окон в iOS — и даже нужнее, если помогают упростить входной язык. «Снизить порог входа» в вашей интерпретации.

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

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

Сборщик мусора - это средство самых ранних этапов борьбы со сложностью. Кстати говоря в RPL он уже должен был какой то быть, так как структуры там представлялись указателями. Даже если нет, то это самая большая дыра в RPL моделях. Если в других языках я мог легко оперировать всякими связными списками и прочими хэшами, то программирование на ПМК - это тотальная примитивщина или сильный геморрой.

Не понимаю возбуждения ретроградов по поводу сборщиков мусора. Давно уже практически установлено, что на реальных задачах правильные сборщики уделывают ручных управленцев памятью при любой погоде. Точно также как нормальный (не гениальный) ассемблерщик ARM не сможет побороть компилятор на такой туче регистров (ну не дано человеку эффективно оперировать такой тучей ресурсов) ! Теория популярно описана в книгах и может быть реализована как программно, так и аппаратно.

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

А в Лиспе и Lua разве есть многопоточность, которой нас здесь запугивают? :-)

Аргументы за сбор мусора понятны. Недаром проф. Вирт отказался в Обероне от устаревшей модели Паскаля и переложил освобождение памяти с плеч программиста на автоматического сборщика. Что многие другие разработчики, кстати, подхватили.

Важно продумать, что делать с типами. Расширение типов и сборщик — мощные современные технологии, которых не было во времена МК-61 и Рапир. Если мы хотим делать современные ПМК, а не музейный экспонат, нужно рассмотреть возможность их реализации.

Но сперва хочется определиться, зачем это нужно. Не делать «для галочки», а рассмотреть практические задачи, решаемые на ПМК будущего — чтобы заточить входной язык под них. Одна из таких задач это СКМ. Также возможны реализации протоколов (TCP/IP), файловых систем (карты SD) и интерфейса.

С другой стороны, калькуляторы должны быть приспособлены для быстрого решения научных и прикладных задач. Это подразумевает минимум типов и возни с ними. Как в МК-61 любой регистр может хранить и целые, и плавучку — программист даже не задумывается об этом. Такой подход хочется сохранить в будущих ПМК.

Здесь много работы, частично проделанной в RPL.

Лисп - современный мощный язык программирования, не хуже других языков общего назначения и сборщики мусора в его реализациях самые лучшие. Кстати был такой небольшой Corman Lisp под винду, с исходными кодами, хвасталсямногопоточным не останавливающимся сборщиком мусора, я его пробовал, реально на ходу собирает без задержек, которые все приписывают сборщикам, т.е время сборки равномерно размазано, как при ручном управлении. Кажется сегодня все сборшики так работают.

"Меня терзают смутные сомнения" (с) Если не секрет, у вас образование профильное? А то пишу вроде бы ключевые слова, но вы их не замечаете. Наверное, и не стоит писать.

Жду от вас рассказов о практических применениях Лиспа в повседневной работе, а также результатов тестов интенсивного использования памяти с GC и без него.

Со времен вуза, Лисп мне за десятилетия встречался один раз. В формате лисп-программы Оракл хранит свои доморощенные конфигурационные файлы. Учитывая специализацию и назначение языка (LISt Processing - обработка списков), решение логичное, правда, логичное лишь для времен работы над первыми версиями СУБД в конце 1970-х.

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

Кто то там сказал, что якобы используйте счётчик ссылок, когда есть сложные запутанные структуры данных. Как по вашему постоянное дёрганье этих ссылок на каждую передачу объекта, может быть эффективнее, чем поиск выживших объектов раз в сколько то миллисекунд на небольшом поколении ? Сомневаюсь, что без умных указателей или GC можно написать сколько-нибудь сложную программу со сложными структурами данных.

Жду от вас рассказов о практических применениях Лиспа в повседневной работе

А есть ли смысл в таких рассказах, если вы ничего по теме не знаете ? Если бы знали, такой вопрос просто не мог бы родиться.

а также результатов тестов интенсивного использования памяти с GC и без него.

Ага, попу с ручкой захотелось сравнить ? Здесь можно далеко зайти, например, если гадить какой то странице памяти, а потом её целиком выбросить, то никакой GC конечно не угонится. Вы знаете сложный софт, который бы работал без какого то подобия GC ? Интересно узнать, что же это за чудо софт такой ! 10 правило Гринспуна? Не, не слышали! :-)

В калькуляторах HP есть сборщик мусора, в TI естественно тоже, наверное они идиоты, не знали как написать среду не требующую сборщика :-)

Благодарю за содержательный ответ по всем пунктам, подтвердивший мои смутные сомнения.

Не пойму, к чему весь этот троллинг? Каждый ваш пост какой то боевой выпад, вызов, попытка как то поддеть, местами даже унизить. А по существу вы говорите мало и, извините, невпопад, если ваша аргументация проваливается, переходите на менторский тон, образованиями мериться зачем то начали. Как будто диплом гарантирует, что человек будет знать всё. Вы же не в курсе, какими характеристиками обладает современный Лисп, современные сборщики мусора, предлагаете счётчики ссылок для массивных операций с разветвлёнными структурами (которые очень даже могут появиться в калькуляторе). Вам уже сказали, что первой из проблем будет даже не производительность, а циклические ссылки. По факту во всех современных калькуляторах используются сборщики мусора, ОСОБЕННО ТАМ ГДЕ СИСТЕМА СИМВОЛЬНОЙ МАТЕМАТИКИ, в каждой более менее сложной программе есть какое то подобие автоматического управления памятью. Нечего возразить по существу? Может обсудим профильность образования разработчиков калькуляторных отделов HP и TI ? :-)

Образованием не кичатся, образование (в том числе самообразование) - это базис, позволяющий людям говорить на одном языке, полагать одну и ту же суть под терминами, оперировать общепринятыми классификациями и пропускать длинные цепочки выводов "А вытекает из Б, Б из В и т.д. до Я". Я не вижу вашего понимания моих слов, хотя их минимум, при этом наблюдаю ответный поток терминологической "каши", не всегда логически связной. В отличие от Арви, который понимает, но просто упорствует по квазирелигиозным причинам. Предлагаю деструктивное общение на этом завершить, чтобы освободить ваше время для реализации чего-то более реального, нежели поток комментариев.

Честно говоря, с вами ужасно не интересно дискутировать, вы говорите банальные вещи и всё время снисходительно поучаете и намекаете на какое то превосходство. Вероятно вы действительно большую часть поднятых здесь вопросов знаете гораздо лучше меня, здесь я даже и не думал спорить. Но в отличие от Арви, ваше знание бесполезно для людей, вы используете его как символ своих притязаний, вместо того чтобы поделиться. И думаю по последней теме со сборкой мусора вы вообще не знаете как достойно признать, что не правы по сути. Я хоть и ляпнул (ПРИЗНАЮ!), что сборщик мусора эффективней всяких ручных программистов (подразумевая, что на длинной дистанции в нормальном приложении (не геймдев) никто ничего вручную не сможет оптимизировать эффективней), но ведь не сильно погрешил против истины. Никак вам не объяснить вопроса, почему у них (HP и TI) таки есть сборщики мусора, когда они якобы не нужны и можно всё и так решить. Про многопоточность,якобы вытекающую из GC, вы тоже ничего не пояснили, и Арви не поддержал, раз уж он понимает вас (в этов вопросе нет религиозности). Вот вам и длинные цепочки выводов.

Я ещё раз перечитал ваши рассуждения по поводу (мало)полезности сборщиков мусора. Вы явно забываете, что кроме "снижения порога", у сборщика мусора есть много других преимуществ.
1) "Снижение порога вхождения" => "повышению уровня абстракции".
2) "Сложные структуры данных" => "невозможность использования счётчиков ссылок"
3) "Накладные расходы на управление памятью" компенсируются факторами "Снижение стоимости памяти в современности" и "Повышение уровня абстракции" + "Возможность вынести за рамки сборщика операции и структуры с которыми можно работать на стеке".
4) Современные сборщики мусора хорошо разбивают работу по частям и благодаря этому могут вообще работать многопоточно (но не обязательно). Они ЗНАЧИТЕЛЬНО облегчают работу программиста (прямо сейчас сижу и портирую код с C# на C++), при этом затраты в массе меньше,
чем на постоянное дёрганье счётчиков ссылок.
5) По ряду факторов ни одном современному средству программирования не удастся состязаться с реализациями Common Lisp. Я достаточно использовал его в реальных проектах, чтобы сказать, что такой уровень интерактивности при высокой производительности кода, ещё не достигнут ни одном другим языком-технологией. Ну и кроме того один из лиспов, богато используется даже в мэйнстриме это Clojure.

Эта «квазирелигия» называется наукой. Которой действительно приходится жёстко пробивать себе путь сквозь невежество и религиозные предрассудки.

Оберон можно сравнить с гелиоцентрической системой мира, теорией эволюции или более новыми фронтами науки, вроде человеческой гомосексуальности, как разновидности нормы. Эти битвы каждый век одинаковы и проходят по похожим сценариям — которые немного напоминают баталии между религиями, популярные в донаучные времена. Кто не хочет адаптироваться к науке, вымирает. Но если консерваторов сильно разозлить, могут немножко нагадить и затормозить распространение (и развитие) общедоступных знаний человечества.

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

...можно ли этот ваш (с Виртом) Оберон скомпилировать в коды Форт машины ?
Там есть какой то научно обоснованный механизим вывода типов (аля Хиндли-Милнера) ?
Насколько тяжело будет забацать транслятор Оберона в Форт (причём наверное на Форте же) ?
Требуется ли создать "калькуляторную версию" Оберона, чтобы им было удобно пользоваться на неполной клавиатуре калькулятора и может быть убрать лишние механизмы ???

Вот этими вопросами я и занимаюсь последние годы. Вы хорошо их сформулировали.

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

У Оберона есть авторская виртуальная машина, отличная от фортовской. Даже две версии. Первая из Оберона-0, вторая аппаратная на FPGA из проекта RISC Oberon.

Вы прямо как я с попытками очеловечить RPL и Lisp слепив из него что то гомоиконическое, но с человеческим лицом :-) Всякие Sweet Expressions выглядят многообещающе,но полного счастья я пока не добился.

RISC Oberon, надо же целую машину забацали. А исходники доступны ?

По поводу Рапиры, ведь никто не мешает Сергею выкинуть эти наши форты из контроллера и прямо на сырую без сборщиков мусора и всего раздражающего написать свою Рапиру как единственную прошивку. Я даже бы поспособствовал, обеспечив минимальную реализацию для общения с клавиатурой, экраном и вообще всей периферией, в отличие от закрытости СЕМИКО. Никакой коммерческой составляющей в этом проекте нет, поэтому нет смысла зажимать исходники, схемотехнику и препятствовать использованию аппаратной базы.

Юзер мог бы выбирать и даже менять прошивку, через какой нибудь DFU загрузчик. Не понравилась Рапира, поставил Каллисто и остальное добро. Предлагаемый общеязыковой подход лучше тем, что мы реализуем всю вычислительную часть ОДИН РАЗ, далее для сложения двух BCD надо будет просто написать в форт машину FBCD1 FBCD2 +FBCD64, для получения синуса надо будет написать FBCD1 FSIN64. Реализация для STM32 в общем то уже есть в кодах библиотеки десятичной арифметики и калькулятора WP34s, надо просто это дело перепаковать под Форт машину.

Далее вы пишите свой транслятор МикроОберона на языке Каллисто, и мы получаем сразу компилируемый язык со всей десятичной плавучкой и функциями. Потом я пишу транслятор UltraRPL и мы получаем ещё один прикольный язык :-) Может быть потом Сергей напишет транслятор Рапиры и наступит общее счастье, можно вызывать функции друг друга из программ на разных языках. Допустим вы напишите на Каллисто эффективную библиотеку астрономических рассчётов. Я в UltraRPL скажу мол ForeignCall 'АстроФункция1 аргумент1 аргумент2 и получу результат на стеке, если один результат то он и будет результатом функции, если ожидается несколько, то будет
ForeignCall* 'АстроФункцияТочка [X Y] (ARG1 ARG2 ARG3), и получу результаты как привязку к лексическим переменным X и Y с Фортовского стека.

В общем идея выглядит несложно и позволяет развивать многоязыковую среду на общем по сути переносимом базисе (общей для всех реализации Форта).

Допустим мы решили добавить к STM32 реализацию на MSP430 (432), пишем ваше Каллисто под эту платформу, затем просто запускаем всё что наработали уже на новом месте. Или запускаем софт процессор на FPGA и пишем Каллисто, где часть BCD операций переложена на железо и Форт в этом случае вызывает аппаратные инструкции ускоряющие десятичную арифметику. Получается весь наработанный софт, включая все наши трансляторы и даже программы на компактном языке МК, который там тоже будет симулироваться, заработает на этом процессоре с ускорением.
Естественно можно подумать об "эмуляторах" этой машины для PC, Android, iOS, JavaScript.

Подобные проекты конечно уже есть, но в них нет вычислительной части и всего калькуляторного багажа, который можно затащить туда и подкупить этими "батарейками в комплекте" пользователей. Тёплый ламповый Каллисто при поддержке высокоуровневых языков наконец реабилитирует Форт как достойный язык :-) А ещё мы туда вклячим все справочники Дьяконова, можно перевести на Каллисто или ввести в компактном языке. Причём прикол в том, что можно будет в программе на Обероне вызывать программу из МК мира, склеив наконец все процедуры из справочников в единый мега пакет аля советский мини Матлаб. :-)

Исходники виртуальной машины Оберона (и компилятора с Оберона на неё) есть, конечно. Это же наука, а не коммерческая секта. :-) Описание старой машины не просто опубликовано, но и переведено на русский язык.

Компилятор Оберона в RISC-процессор на FPGA пока описан на английском языке. Это всё не полная версия Оберона, а упрощённая Оберон-0, которой вполне достаточно для начала. Описание полных версий, включая операционную систему, тоже имеется, и опять RISC-версия для FPGA описана на английском языке.

Сам RISC-процессор, под который разработан компилятор, описан автором (англ.). Чтобы упростить разработку процессоров, проф. Вирт предлагает удобный язык Lola-2 (англ.), который компилируется в VHDL или Verilog.

На калькуляторе можно сделать единую файловую систему, где на исходном коде поставлены тэги (расширения) для редактора и компилятора — а на двоичном коде поставлены тэги виртуальной машины, которая будет исполнять этот код.

Но мне хотелось бы не просто компилировать Оберон в шитый код Каллисто, а объединить мощность и лаконичность Оберона с компактностью и привычностью Каллисто. Сейчас напишу про это отдельно.

Когда я объединял ЯМК и Форт, основным противоречием был целочисленный стек Форта и десятичный стек ПМК. Практика показала, что эти вещи объединяет «бесконечный» десятичный стек и внезапно слово U@ Заранее это было сложно предугадать.

Попробую сформулировать основные противоречия, возникающие при переводе входного языка на следующее поколение. Возможно, их быстрее решить в диалоге или публичном обсуждении. Кстати, мне нравится идея RPO (Reverse Polish Oberon), но вчера придумал аббревиатуру ПРО — Прямой Русский Оберон. Во-первых, причём здесь Польша? Во-вторых, здесь приводили цитату, что если для поляков это обратное, то для нас — самое прямое. :-)

1. Компактность. Вирта не пугала необходимость набирать на клавиатуре слово PROCEDURE или INTEGER. На крохотном индикаторе и клавиатурке ПМК это лишняя боль. Можно оставить : имя … ; и продумать синтаксис параметров, об их реализации см. ниже.

2. Типы данных. Оберон силён своими развитыми типами данных, где расширение записей и указателей увеличивает и без того удивительную мощь Паскаля. Форт же наоборот — практически полностью лишён типов данных, бесстыдно оперируя голыми адресами. Скрестить эти две вещи, чтобы типов данных одновременно и не было, и было — задача, достойная ТРИЗа.

3. Объявление переменных. В Обероне и Каллисто переменные объявляются до использования. Для ПМК же логично иметь переменные, объявляемые в момент первого использования, как в Бейсике (и как регистры МК-61) — это уменьшает размер кода и ускоряет ежедневное создание мелких бытовых программ. Можно предусмотреть опцию для отладки и пуристов, чтобы объявлять переменные требовалось.

Интересный вариант — сделать закладки-табуляции. Например, исходный текст модуля может состоять из четырёх текстовых страниц. На первой список зависимостей (обероновский раздел IMPORT), на второй типы данных (раздел TYPE), на третьей глобальные переменные (раздел VAR), на последней заголовки слов-процедур. Переключение между этими страницами осуществляется «программируемыми клавишами» или по кругу K (Ctrl) ТАБ / К F ТАБ. Когда выбираешь нужную процедуру для просмотра или редактирования, загружаются три страницы. Первые две локальные TYPE и VAR, а на последней уже размещён исходный код, т.е. собственно «программа» в смысле МК-61, работающая в контексте уже объявленных регистров-переменных, объявленных типов.

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

4. Передача параметров. В Обероне нет явного стека и есть проверка типов параметров. Часть параметров передаются по значению, часть по ссылке. Это позволяет функции, возвращающие несколько значений (см. мою модель аппаратного умножителя). В Каллисто и Форте функции берут параметры со стека и возвращают результаты туда же. Также в них можно возвращать несколько значений, но типы аргументов и значений не проверяются.

5. Модульность. Хочется иметь модули-библиотеки на ПМК с раздельным интерфейсом и реализацией. Я просматривал модульные нашлёпки на Форт, но всё это пока не то, что хотелось бы. В Обероне интерфейс модуля создаётся компилятором из того же исходного кода, что и реализация. Когда изменяется интерфейс модуля, все зависящие от этого модуля «клиенты» требуют по цепочке перекомпиляции (аналог MAKE).

6. Компиляция. ПМК интерактивный, как Бейсик. В ПРО хочется такой же диалоговой возможности создавать и использовать новые слова по мере их ввода, как в Каллисто.

Оберон компилирует сразу весь модуль, линкуя его с уже откомпилированными модулями. В чистой системе Оберона модули экспортируют «методы» — которые вызываются и исполняются независимо, как каллистянские слова. Каким образом предусмотреть компиляцию отдельных процедур ПРО, или же мы отдельно редактируем и компилируем модули — это всё надо продумать.

7. Паржер и инфиксная запись. Оберон разбивает входной поток на лексемы иначе, чем Форт. В Форте слова разделяются пробелами, Оберон же позволяет "2+2" разбить на три лексемы 2 + 2

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

Что-то похожее на творческий паржинг сейчас пытаются протолкнуть в стандарт Форта под названием RECOGNIZER (pdf, англ.) — возможно, здесь лазейка для бесшовного стыка с Обероном.

8. Также можно предусмотреть доступ к виртуальной машине ПРО прямо из языка, для написания примитивов подобно форт-ассемблеру. Насколько эта машина будет опираться на самобытный «ассемблер» вроде Виртовского, позволять программировать в кодах камня или же исполнять шитый код вроде Каллисто — даже это пока неясно.

Прежде всего я окончательно не понял, будет ли Ваша задумка опираться на Форт машину, или этому ПРО требуется какая то своя особенная виртуальная машина (рантайм) ?

Когда я объединял ЯМК и Форт, основным противоречием был целочисленный стек Форта и десятичный стек ПМК. Практика показала, что эти вещи объединяет «бесконечный» десятичный стек

Я думаю нехорошим явлением является, что на стеке нельзя распознать тип значения, в идеале бы значение хранить с тэгами типов, как в RPL машинах. А там можно валить всё "вперемешку".
Вообще с наличием умного компилятора, который помнит, где что было и для каждого слова знает, на сколько оно сдвинуло стек, это не обязательно, но для интерактивной среды важно просекать типы динамически. Опять же для софт процессоров реализовать аппаратный контроль типов проще, там можно выделить дополнительные 3-4 бита на регистр не теряя остальные 32-64, чтобы не ограничивать точность или масштаб значений.

1. Компактность.

Имхо именно Паскаль и его производные в плане многословности синтаксиса просто ужасны. Надеюсь из этого есть какой то выход.

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

Вот это меня и смущает в вашей речи. Вы почему то внезапно оказываетесь то на уровне Оберона, то на уровне Форта. В ассемблере практически нет типов данных, если написать компилятор Си на ассемблере, то самому ассемблеру они по прежнему не понадобятся. Почему вас волнует проблема недостачи типов в Каллисто ??? Вы хотели в добавок к Оберону ещё и какой то улучшенный Форт??? То есть Каллисто задумывается как развитая версия базового Форта, с улучшенными типами и т.п. ?

Модульность. Хочется иметь модули-библиотеки на ПМК с раздельным интерфейсом и реализацией.

А мне как хочется, почти нигде это не реализовано. В HP Prime есть что то подобное, но эта странная система наследования дубовых приложений, а создавать свои типы приложений (классы) не разрешается...Если ещё сделать их языко-нейтральными (хотя на рантайм каждого языка таки может случиться оверхед, поэтому тот же сборщик мусора надо бы сделать общий на машину и как можно больше других механизмов как JVM, .NET).

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

Ха ха ! Как то в дискуссии с Михаилом Борисовичем в ответ на какой то стёб надо МК-152 всплыла фраза мол "студент напишет алгоритм паржировки и доволен", типа студенческие поделки несовершенны и там много работы. Я весь Гуголь сломал, чтобы понять что за "паржировка" такая. Только теперь понял, что это то что называется парсером.

Только мне не понятно, почему вас опять волнует сходство парсеров Форта и Оберона, ведь Оберон не Форт, или вы хотите нарисовать синтаксис под Форт (типа DSL) и не делать полный парсер Оберона ???
Разбор инфиксной записи - это ж вроде не самая сложная вещь, кстати один из основных алгоритмов её парсит как раз в обратную польскую нотацию, сразу в Форт получается :-)

Вот рекогнайзеры, ридеры и т.п. подходы я люблю. В Лиспе они отлично зарекомендовали себя, нечто похожее внедрено в AmForth.

Также можно предусмотреть доступ к виртуальной машине ПРО прямо из языка, для написания примитивов подобно форт-ассемблеру.

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

Прежде всего я окончательно не понял, будет ли Ваша задумка опираться на Форт машину, или этому ПРО требуется какая то своя особенная виртуальная машина (рантайм) ?

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

Уже ясно, что классической Форт-машиной, как Каллисто, ПРО не будет. Нижний уровень будет подстраиваться под верхний — который продумывается на основе «что удобней человеку с нашим ПМК на ладони». Это не альтернатива Каллисто vs Оберон поверх форт-машины, а замена Каллисто на ПРО с бережным сохранением всего хорошего, чего удалось добиться в Каллисто. ПРО будет проще и мощнее, как Оберон в сравнении с Паскалем.

Если кому захочется написать Каллисто на ПРО это будет примерно также, как сейчас делаются эмуляторы и симуляторы МК-61 на Си и JavaScript.

на стеке нельзя распознать тип значения, в идеале бы значение хранить с тэгами типов

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

Имхо именно Паскаль и его производные в плане многословности синтаксиса просто ужасны.

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

Почему вас волнует проблема недостачи типов в Каллисто ??? Вы хотели в добавок к Оберону ещё и какой то улучшенный Форт??? То есть Каллисто задумывается как развитая версия базового Форта, с улучшенными типами и т.п. ?

Каллисто — вполне завершённый язык и даже Каллисто-2 уже продумана намного глубже ПРО. Типы там не нужны, их роль выполняет выбор слов, например @ U@ C@ для считывания значения из памяти. В стеке же все значения одного типа, как на МК-61.

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

вы хотите нарисовать синтаксис под Форт (типа DSL) и не делать полный парсер Оберона ???

Я продумываю лексику нового компактного языка. Необходим ли полный паржер Оберона или можно будет свести лексический уровень к простейшему фортовскому, установив систему рекогнайзеров — это всё палитра, краски которой можно использовать. Возможно, я зря всю эту кухню вынес в Сеть. Готовых блюд пока предложить не могу. Продумывание Каллисто заняло десятилетия, готовый к использованию язык получился лишь в прошлом году.

там могут быть разные камни и даже архитектуры

Да, в этом смысл примитивов и форт-ассемблера. Они открывают доступ к реализации, возможность программировать под конкретный кристалл — то, чего нет в МК-161. В Обероне есть модуль SYSTEM для системно-зависимых программ, в Интернете можно найти его критику.

Можно не использовать управления памятью (прям по вашему рецепту), если всё передавать по значению (насколько я понимаю в HP это по большей части так и есть). Но при этому на копирование значений каких нибудь матриц может уходить такое колоссальное количество времени, что выигрыш от такой "экономии" сильно уйдёт в минус. Это главный облом RPL программирования, т.к. в целом всё передаётся по значению и копируется каждый раз. Второй подход - это просто сделать всё очень убогим и фиксированным. То есть сделать глобально все массивы и списки (пускай они даже выделяются динамически), как в CASIO, тогда ясно, что управление этим скромных хозяйством особо не требуется. Но блин, это и программировать не захочется, т.к. там ничего приличного не сделаешь, пока будешь сидеть на низком уровне.

Совсем не обязательно делать сборщик многопоточным. Он может включаться кратковременно в ходе работы основного потока. Учитывая, что ничего стоящего без нормальных "разделяемых" структур данных написать нельзя, нафига мне калькулятор без удобных механизмов управления памятью ????
В HP 48 (вероятно и в боле ранних моделях) есть сборщик мусора, что за бред вы несёте про ненужность GC для ПМК !!!

Мусор можно собирать в двух случаях. Либо когда памяти становится маловато, при запросе NEW. Либо в то время, когда процессор простаивает.

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

Сигнал от прерывания (нажатие клавиши или таймер) может прерывать сборку мусора. Которая возобновится при следующей возможности. Если заранее известна продолжительность паузы, сборщик может заранее спрогнозировать возможный объём работы, зная свою производительность.

Хотелось бы только возразить, что никакая многопоточность из этого не следует. Её "можно применить", но не более того. Конечно неплохо бы "размазать" сборку мусора чтобы она шла примерно также ритмично как освобождается память в без автоматического управления или по счётчикам ссылок.Расход памяти - это для мелких девайсов конечно проблема, но в современности с памятью уже не так плохо. А сборщик был уже на HP 28S. А если сделать аппаратный, сопряжённый с софт процессором, это была бы вообще чума :-) Конечно до супервылизанного и масштабного продукта путь далёк, но и начинть приходится не с нуля, по сути студенческий проект на курсовик (что софтовый сборщик, что аппаратный). Не пойму чего Сергей Тарассов так взъелся, как будто я предложил потратить всего его деньги/время на это :-) Я всё равно собирался это всё щупать и ковырять, не может быть чтобы не получилось хоть что то. Очень воодушевляют исходники WP-34s, виден свет в конце тоннеля с этими десятичными вычислениями.

Да, предложенное решение без многопоточности. Многопоточность, скорее, вылезет при реализации TCP/IP. Хотя известны браузеры под MS-DOS, я не лазал по их коду и не уверен, что они сами не делают себе внутреннюю многопоточность.

Сергей хочет водрузить на ещё неоперившиеся плечи новых ПМК устаревший язык Рапиру (уровнем абстракции между Паскалем и Модулой) — у которой не было другого назначения, кроме как быть отечественной. В Рапире уже реализована структурность, но нет сборки мусора, расширения типов и многопоточности, а многословный синтаксис делает её не очень компактным языком. По хорошему этот язык должен быть развит с учётом современных достижений компьютерных наук и адаптирован под задачу. Примерно так, как HP поступила с Лиспом в RPL.

Увы, её разработчики ушли из жизни, не оставив учеников. Серьёзно дорабатывать Рапиру, в отличии от входного языка МК или Форта, некому — Сергей намерен реализовать лишь каноническую версию. Поддержку, сравнимую с государственной в СССР, мы обеспечить не сможем при всём желании — да и та не помогла Рапире стать такой популярной, какими стали Форт и язык МК.

Рапира умела, а ПМК жив. Входной язык МК настолько хорошо изучен и передан нашему поколению, что его творчески развивают конкурирующие команды, с учётом требуемой компактности входного языка — даже после смерти его автора и идеолога, Ярослава Карповича Трохименко (укр.). На входном языке ПМК пишут программы до сих пор. Он оказался «вирусным», самоходным. Получил популярность в СССР, выжил в РФ без господдержки и может пойти дальше.

Мой подход к расширению входного языка ПМК — брать уже проверенное, «вирусное», прижившееся в народе и развивающееся даже без государственной поддержки. Советские книги по Форту вызвали сравнимый с ПМК энтузиазм, вдохновили народ на написание своих трансляторов. Форт объективно вызывает интерес, привыкание и желание развивать дальше. Каллисто должна усилить ПМК — даже если ей просто не мешать. Многое в каллистянских «кишках» уже известно большему числу наших соотечественников, чем сможет достичь любой наш новый проект, т.к. бережно собрано из популярных советских реализаций.

Подход Сергея — раз ПМК оживает, давайте нагрузим его балластом типа Рапиры. Вдруг любимый труп заразится жизнью? Бесспорно, Сергей вправе реализовать свой любимый язык самостоятельно поверх чего угодно, включая ПМК будущего. К сожалению, Рапира не имеет шансов без новосибирского брутализма — прошиваем «единственно верный» язык и мешаем тем, кто предлагает альтернативы. Отсюда и агрессия к любителям современных подходов — давить всякую конкуренцию, чтобы либо живое умерло, либо мертвецы ожили.

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

С Рапирой более менее всё ясно, что то напоминающее язык HP Prime, вполне годное, дружественное, но....не совершенное. То есть из разряда "дубовых" языков, внутри которых новые языковые средства и парадигмы уже не реализовать. А почему бы и нет, и такие языки очень нужны, для старта само то !

Язык МК жив потому что он по сути ассемблер этой высокоуровневой стековой машины (МК-152, МК-161), а ассемблер по определению так же жив как и сама машина, куда ему деваться. Но это низковатый уровень (а местами высоковатый), у Форта этот бланс как то получше.

Подход Сергея — раз ПМК оживает, давайте нагрузим его балластом типа Рапиры. Вдруг любимый труп заразится жизнью? Бесспорно, Сергей вправе реализовать свой любимый язык самостоятельно поверх чего угодно, включая ПМК будущего.

Забавно. Я поклонник сериала "Ходячие мертвецы" :) Мне кажется эта Рапира не мертвее Форта или языка МК. Я же уже обозначил свою точку зрения - пускай расцветают тысячи цветов. Надо сделать чтобы низкоуровневый рантайм был как бы виртуальной машиной (предварительно будем считать, что основанной на Форте), на основе которой можно построить разные языки, по примеру JVM или .NET, да ещё и обмениваться вызовами между ними. Единственному языку - однозначно нет, даже в HP встроено как минимум 3-4 языка. В новых TI два языка Basic и Lua.

Из отечественного меня больше впечатлил Рефал. Ну я нифига не понял, не сделал ментального усилия, чтобы понять, видимо там как в Clean идёт какая то редукция выражений, но круто, видно не хуже западных наворотов вставляет. Могут же наши когда захотят ! Но для калькулятора - это слишком страшно, пользователи могут прийти с вилами и замочить разработчиков :-)

Я Рапиру видел только мельком. Там что то есть кардинально препятствующее её компиляции в стековую форму (в Форт) ? И почему там нет места автоматическому управлению памятью, там как в древнем Бейсике нет структур(объектов) и ссылок на их экземпляры ?

Рапирский текст

Выглядит как бы непривычно, как первый раз Язык 1C на русском. Но ведь не хуже CASIO BASIC ? Однако ехидно замечу что тот бейсик самый примитивный из всех, в TI и HP языки намного гибче, удобнее и поэтому там есть сборка мусора, потому что гибкие структуры нуждаются в управлении памятью, а ручное управление на устройстве не для программистов - это садизм. Ну понятно, что Рапире не надо никаких сложных механизмов управления памятью - это её преимущество и как бы недостаток.

Тысячи цветов это правильно. Просто раз пошло давление на сборщики мусора и Оберон — позволю себе однажды высказаться в адрес Рапиры. Нарушу многолетнее вежливое молчание, а сказать есть что.

Мне кажется эта Рапира не мертвее Форта или языка МК.

Вот не соглашусь! По Форту проводятся международные встречи, принято несколько стандартов разного уровня и прямо сейчас дорабатывается новый стандарт. Продаются коммерческие реализации. Есть несколько наследников — от автора, от сообщества и много самобытных.

Язык МК вызвал к жизни множество отечественных приложений в App Store и вашем любимом Гуглеплее, включая коммерческие. Есть аппаратные подражания. Эмуляторы на основе микрокода написаны на нескольких языках программирования.

Всего этого у Рапиры нет.

Ещё раз. Я не против Рапиры в новом ПМК. Любые зомби за ваш счёт. Даже могу чем-нибудь помочь мелким, если это не сильно будет отвлекать. Но я категорически против, чтобы другие проекты и даже размышления блокировались на основе того, что в Рапире что-то отсутствует.

Для своего поколения Рапира была неплоха. Но возрождать её это отдельный проект, который мне не так интересен, как эволюция ПМК. Тогда не зацепила, и сейчас не цепляет. Конечно, если бы в 90-ые были доступны ПЭВМ только с Рапирой, программировал бы на ней от безвыходности — как программировал на Фокале БК-0010.

P.S. Бейсик в ПМК тоже оказался неудачной идеей. И по тем же причинам, по которым Рапира. Многословен. А сейчас ещё и устарел, требует существенной доработки тем же самым. На МК-85 программировал, это не то — все эти HP Basic'и путь в никуда. МК-61 нащупал правильный путь, а Трохименко смог этот ещё и рассказать, как это ему удалось. Из первых уст, так сказать.

особенного по сравнению с Бейсиком, который реализовать бы тоже надо.
Чем она особенна, кроме лёгких синтаксических различий ?

Касательно BASIC меня немного впечатлил TI Basic 89, там многое сделано для снижения многословности и даже можно определить в урезанном виде списки списков :-)

Наверное идеальный язык должен быть с виду синтаксически прост как Бейсик, но настраиваться гибко как Форт или Лисп и иметь в коробке много батареек вроде генераторов последовательностей (списков, массивов, матриц), фильтров последовательностей, всякие интераторы и сопрограммы и т.п. По этим параметрам для компьютера наверное близок Lua,
но для калькулятора тоже слишком многословен. В общем будем идти потихоньку, по дороге думаю к чему то придём. Тестирую e-Ink экранчик 2 цветный (чёрный и красный).

Главный плюс Рапиры то, что это отечественный язык. Американцы активно используют антропоморфизм («язык», «наследование»…) и он навязывает разрушительные идеи. Одна из них та, что у каждой нации якобы должен быть свой личный язык программирования.

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

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

Возвращаясь к Рапире, в своё время мне понравилась идея кортежей. Возможно, она спёрта из Лиспа, но вполне практична и красива. Также, в сравнении с Бейсиком, Рапира изначально поддерживает структурное программирование. В Бейсик и Фортран структурные IF и циклы были уже потом добавлены, значительно позже разработки общей концепции языка.

Здесь описывается устройство на PIC18 cфортом на борту, со слов автора как альтернатива ардуине с фортом вместо С++.
З.Ы. На сайте есть тема про скалярное магнитное поле, что для меня весьма подозрительно выглядит :) я от попыток постройки вечного двигателя ещё в детстве отказался :) автором не учтён магнитный поток между половинками ферритового кольца, отверстие в кольце описываемого трансформатора как раз играет роль немагнитного зазора :) всё в рамках классической электродинамики.

Серьёзно чел озадачился и подощёл к вопросу. Надо будет ознакомиться.