nedoPC.org

На самом деле, многозадочной форт машину можно сделать ввести слова типа fork, open, read, write,close, kill. Т.е. сначала фот машина форкает сама себя, создается вторая с таким же загруженным словарем и программой, затем вторая мишания окрывает новый словарь и программу, читает и исполняет до тех порт пока что не сделал и не получила сигнал kill, вообще такая машина на пропеллере бы пошла, классно.
ЗЫ: Кстати умные мысли не приходя только в одну голову http://www.jacobsdesign.com.au/software ... dforth.php

Оно так и замышляется. Только наверное для запуска будет два слова - fork и spawn (spawn - будет создавать "чистую" форт-машину и выполнять на ней новый файл. Типа execa).

Кроме того хочу предусмотреть ещё два слова - sendmsg и recvmsg - для обмена сообщениями между aForth-машинами.

Параллакс у меня живой есть. Но там - 8 ядер имеется. И прерываний нет. Вообще. Хитроархитектурная штука.

Примеры рабочих программ на aForth:








[/url]

Кстати это всё хорошо, но неплохо было бы, заиметь схему, разводку платы афорт машины? Кстати благодаря своей польской последовательсности афорт может выступать в роли баша для армос:) Ещё не плохо было бы добавить слово(если не пропустил) запуска произвольного бинарного кода:) И тогда получается что армос будет выступать своего рода микроядром, я форт машины интерфесом более высокого уровня:) Одна форт машина может обслжывать переферию,другая работать с файлами, третья запускать приложени, а из армос эти функции можно убрать, она будет только передавать сообщения Десятая или 20ая форт машина может выступать даже в виде инерпритатора рв0 кода.

Разводку выложить не могу - отлаживаюсь не на своей плате и разводки нет.

Но там AT91SAM7S256 + FLASH AT45DB081, подключенная по SPI размером 8 Мбайт.

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

Добавить слово "запустить любой машкод" - это не проблема. Но смысла немного в таком слове при программировании форт-машины и возможности записи-чтения в любую точку памяти (слова setm* getm*).

Сейчас хочу первым делом сделать нормальный ввод с терминала и слово save для выгрузки текущего состояния aForth-машины.

Плюс - приём-передача файла по протоколу TSA (он уже поддержан на PC и в NEDOPC-ARMOS).

Тогда получится самостоятельная aForth-система с выгрузкой состояния и возможностью автозагрузки.

Идея простая - при загрузке системы дать пользователю скажем 3 сек в течении которых он может нажать любую клавишу на терминале и вывалиться в интерактивную форт-машину.
Если же он не нажимал клавишь - подгружается файл, скажем init.af и выполняется в форт-машине.

Вообще на повестке дня (из задач, сложных для реализации):

- слова обработки ошибок. скажем система, если определено слово onerror будет очищать при ошибке стеки и выполнять его, поместив на стек код ошибки и прочие данные.
- Приём-передача сообщений между форт-машинами. Скажем при приёме сообщения выполняется слово onmsg, если оно определено и выполнение программы продолжается.
- fork() spawn() kill() - запуск-останов форт-машин.

А простых-мелких задач типа математики и обработки строк - вообще ещё тьма.

Угу, вот недописюк появился, Шаос , АУУУУУУУУ:)

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

Сделал команду save, которая выгружает всё в текстовый файл.
Всё бы ничего - но не знаю пока как выгружать байтовые массивы array.
Остальное - на ура прокатывает.
Выгружаются все слова и переменные, НО НЕ СТЕК!.

Как кусок памяти?

Неа выгрузка производится в виде ИСХОДНОГО ТЕКСТА. Даже с форматированием для читабельности.
ПОка спал пришла мысль сделать возможность задавать константу-байтовый массив типа так:

{ 00 23 45 66 "Строка" 'A' 'Б' } array MASSIV
Тогда можно и в программе это задавать и выгружать.
Конечнно, если массив адреса содержит - то выгружать его бесполезно - но тут уж все сами думать должны. А для таблиц - милое дело.

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

В принципе моё поделко aForth могёт собраться на всём, на чём есть С.
Все биты-флаги у меня вроде как в пределах 8 бит, все раззмеры - через sizeof().

Если и есть где пара узких разрядно-зависимых мест - можно и поправить. Только у меня сейчас 8- 16-битного железа нет, чтобы туда портировать и проверить.

А у меня есть NedoPC-91, на который я периодически пытаюсь RW0-движок водрузить

В принципе можно попробовать Портануть ARMOS на AVR. Я пока не вижу особых проблем. Разве что прошерстить на предмет правильности указания типов и разрядности.

Самый геморр - переписать драйвера под систему прерываний, UART и PIO для AVR - и будет 8/16 разрядная ОСЬКА.

И aForth - поверх неё.

Ограничения - надо AVR с внешним ОЗУ хотя бы на 32К и флешкой. Иначе ничего кроме "Hello world!" не запустишь толком.

В общем - я пока форт до ума доведу на SAM7. А там - может и к AVRу обращусь.

Сейчас на очереди поддержка массивов в виде констант для их загрузки-выгрузки. Это, пожалуй, последнее, что в язык надо для полноценности включить.

Ну и компрессия-декомпрессия при выгузке-загрузке "на лету". Очень оно память экономит.

Доделал работу с массивами.
Теперь массив можно объявить так:
10 array A - массив размером 10 байт, забитый нулём

Пустой массив:
0 array A
{ } array A

Массив, заполненный значениями:
{
1 3 4 34 0x14 "Строка"
} array A

Массив из другого массива (копия):

{ A } array B

Целые числа в массиве интерпретируются поразному - по умолчанию - как целые. Но могут и как байты и как короткие целые:

{
byte 0x11 0x33 0x44
short 0x1234 0x2344
int 0x12345678 0x87654321
} array A

Выгружается массив всегда как массив байт.