Здравствуйте уважаемые фортеры!

Есть задача - создать на основе микроконтроллера MSP430 аналог вычислительной среды RPL (фортообразный язык в программируемых микрокалькуляторах HP). Допустим взяли за основу Camelforth. Но тут же выплывает ряд вопросов, которые хотелось бы решать ближе к идиоматическому Форту.

1) Плавучку в Форте обычно оформляют на отдельный стек, и вообще плавучее число занимает больше 16 бит. В RPL вообще один стек, учитывать числа на разных стеках и показывать их на одном стеке - это нереально. Расширить стек, сделать кадры по 32бит ? А может быть в таких случаях Форт будет языком низкого уровня, в нём там отдельный стек для плавучки и всё такое, а над ним сделать другой стек, как бы более высокоуровневый Форт написанный на Форте, только IMHO это должно быть тормознее, чем сразу идти с низкого уровня.

2) Требуется знать, какого типа объекты лежат на стеке. Какие методы лучше всего, тэги типов, дополнительное поле на тип ?

3) Требуется создавать гибкие структуры вроде списков, которые содержат списки, с возможностью ссылки на самих себя, то есть списки как в Лиспе. А как лучше управлять памятью, какого типа использовать сборщик мусора, или можно извернуться без сборщика ?

Памяти в текущей железке мало. 60Kб флэша, 2Кб ОЗУ, есть SD карта, потенциально можно приделать микросхему сериальной FRAM или SRAM. К сожалению, не смотря на свою фон-неймановскую архитектуру, MSP430 не умеет работать с внешней памятью, включая её напрямую в своё адресное пространство. В общем для кучи динамических объектов будет не больше 1200 байт "честной" памяти ОЗУ, которую можно попробовать откачивать на SD карту, ценой скорости.

Пока что настроил Camelforth в Proteus на MSP430F2370, компиляю из под IAR Embedded Workbench, но он после выдачи приветствия почему то продолжает печатать содержимое всей памяти в терминал. Разбираюсь в чём дело.

Спасибо за внимание!
XSet

http://fpauk.narod.ru/spmsp.rar целевой компилятор (с генерацией листинга)
и распределенная форт-система.

Просмотрел исходный код, но не могу понять как он решает какие либо проблемы из приведённого списка: 1) как сделать чтобы стек выглядел как один и для целых и для плавучки, 2) как лучше сделать динамическую типизацию, 3) как лучше управлять динамическими структурами памяти ?

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

Можно и другие варианты на данном этапе рассмотреть. Например 4E4th Forth For Education
на easyelectronics ,были три статьи касающееся данной разработки
Введение
4E4th + TI LaunchPad. Основы языка Forth
Лезем внутрь
Camel Forth c данным Фортом сделаны близко.

P.S. Общее правило используемое в Форте формат обрабатываемых данных проходящих через стек известен слову которое их положило и слову которому они
предназначены и будут обработаны. Хотя есть варианты и с типизацией стека в разных вариантах (например strongForth и др. PostScript тоже с типизацией)
Какие то обсуждения были на местном форуме и статьи по сборке мусора в рамках Форт системы от true-grue (в Forth IRC канале его можно быстро об этом спростить)

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

Следует завести стек типов и операции поставить в зависимость от содержания
этого стека.
http://mak.chat.ru/F-PL.RAR

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



О! Тема. В исходниках вижу "виртуальный стек" ! Т.е. надо как бы сделать виртуальный Форт над физическим и сделать относительно высокоуровневый интерфейс из слов. Получаем видимость 1 стека и можно определять типы. Функционал менеджера памяти будет упрятан под капот

Спасибо за помощь
XSet

1) стеков может быть много - для каждого типа данных свой - это наиболее экономичное решение.
2) можно все числа (в том числе адреса) хранить в формате с FP, но, тогда надо заботиться о том, чтоб эти адреса не подвергались нормализации
3) можно хранить в стеке не данные, а указатели на данные, которые, скажем, могут храниться в разных областях памяти (что позволит определять их тип).


списки какого типа (в смысле что должны хранить элементы списка)?

По условию задачи, программирующий юзер должен увидеть стек единым. Причём там должны быть как целые так и плавающие числа.



Это уж больно радикально.

>3) можно хранить в стеке не данные, а указатели на данные, которые, скажем, могут храниться в разных областях >памяти (что позволит определять их тип).

В случае виртуального Форта это может быть единственный вариант.
К тому же это неизбежно для ссылочных типов вроде списков, массивов и т.п., но неэффективно. Желательно чтобы "непосредственные" типы вроде чисел всё же были сразу на стеке.



Весь фокус, что любого. Ячейка связного списка это пара указателей или значений. В списке каждая ячейка в первом указателе содержит значение, а второй ссылается на следующую ячейку, последняя ячейка содержит нулевой указатель. Значениями могут быть как числа, так и другие списки, массивы,а также символьные идентификаторы слов. На таких списках удобно строить всякие символьные вычисления вроде сопоставления шаблонов и т.п. В HP 48 - 50g они реализованы на отлично, хотя я не уверен, что внутри они являются связным списком, возможно там массивы указателей. Может быть достаточно реализовать сборку мусора (определение достижимости объекта) только для ячеек списков, а всё остальное склеивать ими. Если объект недостижим через ячейки, то сборщик его уничтожает (метит область свободной). Переменные Форта приравниваются к ячейкам и также участвуют в обходе. ОЗУ там мало, не знаю как это будет жить на пятачке 2Кб, где под кучу дай Бог есть 1.5Кб Хотелось бы сделать нечто вроде виртуальной памяти, чтобы относительно редко используемые переменные со всеми сложными структурами откачивались на SD карту, подкачивались по требованию в ОЗУ (читать то можно наверное любыми кусками), в случае жесткой нехватки эта хреновина начнёт жёстко своповать.
Это вызов инженерной мысли, задача интересная.

С уважением
XSet

Зависит от того, какие типы данных преобладают и сколько всего типов.


Если бывают произвольные ссылки и произвольное время жизни объектов, тогда нужен сборщик.
Если время жизни ограничено, можно в каких-то точках освобождать весь кусок памяти, откуда выделялись объекты (obstack). Так делали списки в GCC.


Это очень грустно.

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



для меня наиболее интересно, как вариант для адресации блочной памяти. Т.е. мантисса - это смещение внутри блока, а порядок - это номер блока
Кстати, в Бейсике все числа (в том числе адреса) имеют формат FP


Это плохая идея, имхо. Чем плохо много стеков?
Что же касается эффективности, это быстрее и легче, чем поддержка еще одно стека типов, либо любая другая методика отслеживания типа.

Не вижу смысла в хипе на таких объемах.
Списки можно хранить в стеке (кстати стек легко свопится), т.е. при переполнении, скажем половину выгружать во внешнюю память. Опять же см. Постскрипт.

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

Эти методы видятся очень похожими. Все равно отличие будет чисто стилистическое - оформлены две структуры данных, или же одна, но с составными элементами. Чуть сложнее окажется реализация слов, которые должны учитывать, какой тип оказался у реально переданных им параметров.

А вот тут начинается не совсем Форт, поскольку аппаратного сборщика памяти в Форте не предполагается. Предполагается только простейшее выделение областей памяти известного размера. Все остальное - на усмотрение разработчика. Если есть эффективный для данной задачи алгоритм gc, то его можно реализовать, не оглядываясь на стандарт.

Никак Увы, это известная особенность общения Mihail-а - ну сложно ему обойтись без того, чтобы дать ссылки на свои продукты, надеясь, что благодарные последователи тут же их разовьют...

Спасибо за советы, попробую разные варианты, может быть удобнее окажется нарисовать RPL (по сути Форт) на Си.

С уважением
XSet

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

Елси быстродействие не критично, могу рекомендовать
форт-машину на Си в рамках моей системы http://93.100.60.208:8980
обсуждалось http://www.fforum.winglion.ru/viewtopic.php?f=22&t=2648&view=next