Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 14:41

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Я написал интерпретатор форт-подобного языка.
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
Написал обработку ошибок. Теперь пользователь может любую ошибку перехватить и обработать.
Принцип - простой. Если пользователь определил слово onerror, то при ошибке делается следующее:
1. Код ошибки - на стек.
2. Выполняется onerror.
3. Код ошибки - со стека в систему.

Если слово onerror помещает 0 на стек - (то есть говорит - "ошибок нет"), то система продолжает выполнение программы.
Простейший пример слова onerror, которое при возникновении ошибки не даёт завершиться программе, а просто выводит информационное сообщение о том, какая ошибка возникла:

Код:
: onerror "Ошибка [" . dup . "]: " . strerror . '\n' .C 0 ;


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

http://www.nedopc.org/nedopc/upload/afort-1.11.0.tar.bz2
Сообщение Добавлено: Вс авг 03, 2008 19:56
  Заголовок сообщения:   Ответить с цитатой
Появился первый платформо-зависимый словарь linux.dict. В нём линукс-специфичные настройки стандартного ввода.
Как видно - платформозависимый словарь - полностью отделён от осноного словаря.

В linux.dict сведены слова получения информации со стандартного ввода getchar и getcharnb - они отличаются тем, что getchar ждёт символа, а getcharnb не ждёт.

Исходники и дока обновлённой версии тут:

http://www.nedopc.org/nedopc/upload/afo ... .1.tar.bz2
http://www.nedopc.org/nedopc/upload/afo ... .1.tar.bz2
Сообщение Добавлено: Ср июл 30, 2008 20:24
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
SfS, кстати, на главной странице есть ссылка на IRC, где с 22:00 (мск) обычно происходит общение форумчан.


22:00 (мск) - это 01.00 по-нашему :) на выходной загляну наверное.
Сообщение Добавлено: Ср июл 30, 2008 11:09
  Заголовок сообщения:   Ответить с цитатой
SfS, кстати, на главной странице есть ссылка на IRC, где с 22:00 (мск) обычно происходит общение форумчан.
Сообщение Добавлено: Ср июл 30, 2008 01:26
  Заголовок сообщения:   Ответить с цитатой
Kopa писал(а):
Все таки Postscript - это не Forth + Lisp,


это из "Thinking in postscript"

Like all programming languages, the PostScript language builds on elements and
ideas from several of the great programming languages. The syntax most closely
resembles that of the programming language FORTH. It incorporates a postfix
notation in which operators are preceded by their operands. The number of special
characters is small and there are no reserved words.
Note: Although the number of built-in operators is large, the names that represent
operators are not reserved by the language. A PostScript program may change the
meanings of operator names.
The data model includes elements, such as numbers, strings, and arrays, that are
found in many modern programming languages. It also includes the ability to
treat programs as data and to monitor and control many aspects of the language’s
execution state; these notions are derived from programming languages such as
LISP.
Сообщение Добавлено: Пн июл 28, 2008 22:48
  Заголовок сообщения:  Re: Я написал интерпретатор форт-подобного языка.  Ответить с цитатой
Kopa писал(а):
Интересна мотивация разработки данного подхода.
И какие аналоги рассматривались в качестве прототипов?
\ пример в FreeBSD в качестве загрузчика применяется Форт - Ficl.


Мотивация - "захотелось, потому что интересно". Это во-первых. Ну и надо было какойто язык сделать более-менее высокоуровневый и с лёгкостью добавления новых клманд-слов. Это уже во-вторых.
До этого форт видел довольно издали, но подход заинтресовал. Вот и сделал своё - наподобие форта.
Аналоги рассматриволись - только книжечка в которой описан форт для ZX-Spectrum + ресурсы инета некоторые.

ДЕлал я бейсик когда-то - упарился с парсингом. Да и медленно работало.
Сообщение Добавлено: Пн июл 28, 2008 14:48
  Заголовок сообщения:  Re: Я написал интерпретатор форт-подобного языка.  Ответить с цитатой
SfS писал(а):
Прошу оценить, если конечно у кого есть время и желание.


Интересна мотивация разработки данного подхода.
И какие аналоги рассматривались в качестве прототипов?
\ пример в FreeBSD в качестве загрузчика применяется Форт - Ficl.
Сообщение Добавлено: Пн июл 28, 2008 09:45
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
SfS писал(а):
А какое отношение оно к форту имеет ?

прямое: Postscript = Forth + Lisp.



Все таки Postscript - это не Forth + Lisp,

\ использование стека для передачи параметров между словами
\ не ключевой признак Форт языка.:)
\ Так к Форту можно отнести и язык Factor? и еще n-языков "клеевого" типа.
Сообщение Добавлено: Пн июл 28, 2008 09:39
  Заголовок сообщения:   Ответить с цитатой
SfS писал(а):
Не спорю. Но в моём конкретном случае - практическое использование винце - не предвидится. А от того, что я немного про неё почитал и скомпилировал пяток разных "хелловорлдов" - толку в освоении мало.

В моем пока тоже :) Но чтобы был толк, и нужен Форт, тогда освоение сведется к реализации POSIX-подобного интерфейса (один раз) и запуске на получившейся ФВМ ранее написанного софта.
SfS писал(а):
У нас другой бренд требуют МСВС называется - микрософт отдыхает

Ну, это он локально у вас отдыхает. Судя по объемам софта - отдыхает-то как раз не микрософт. В России рынок коммерческой электроники уже сейчас превышает рынок "специальных" изделий раз этак в 50. Рано или поздно предприятие захочет диверсификацию, и выяснится, что прибор надо бы состыковать с сеткой или WiFi на ноуте, на котором Windows. Хотя тут и линукс-системы справятся.
SfS писал(а):
Если появится у меня реальный проект, где винце даст реальный выигрышь во времени разработки или заказчик захочет "бренд от микрософт" - то без фанатизма поставлю и буду вплотную изучать.

Вот это правильный подход...
Сообщение Добавлено: Вс июл 27, 2008 17:17
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
В любом случае, владение и WinCE, и embedded-вариантами Линукса лучше, чем только Линуксом.


Не спорю. Но в моём конкретном случае - практическое использование винце - не предвидится. А от того, что я немного про неё почитал и скомпилировал пяток разных "хелловорлдов" - толку в освоении мало.

Хищник писал(а):
170 рублей с устройства. Взамен - бренд, и возможность отсыла пользователя к смартфону или КПК, чтобы не приставали с вопросами "почему тут так?". Деньги сегодня не всегда определяющий фактор, баррель-то стоит больше, чем раньше в анекдотах фантазировали. Покупка средств разработки окупается.


У нас другой бренд требуют :) МСВС называется - микрософт отдыхает :)
Я ничего не имею против винце как таковой. Но поскольку в ней нет ничего, чего не было в свободных системах - то смысла в ней особого нет. Да и госзаказчики МСВС предпочитают - ибо сертефицирована на всякие безопасности и прочую фигню. Если появится у меня реальный проект, где винце даст реальный выигрышь во времени разработки или заказчик захочет "бренд от микрософт" - то без фанатизма поставлю и буду вплотную изучать.
Сообщение Добавлено: Вс июл 27, 2008 15:27
  Заголовок сообщения:   Ответить с цитатой
SfS писал(а):
По-моему проблема не в том - как занести байт в переферийное устройство, а в том, что данные получаемые/передаваемые от/в переферийного устройство - привязаны к конкретному устройству и жёстких стандартов вообще нет. Поэтому как бы мы не пихали данные в регистр устройства - всё равно придётся писать ДРАЙВЕР, который обслуживает данную конкретную железяку - и никакую более. Ну или класс железяк. Конечно, есть стандартные шины. Но шина - это только формат передачи данных и не более. Сами данные - опять же определяются разработчиком конкретной железки и ни кем более. От уровня прослойки - железо-программа, то есть от уровня драйверов - никуда не уйти. Хоть как извернись. Вопрос только в том - вкомпилировать эти драйвера в форт-систему, в ОС или подгружать их в виде модулей.

Для этого существует концепция layered драйверов. POSIX - как раз один из вариантов верхнего уровня (уровень адаптации к ОС). Как минимум делается "обвязка" с заменой "вывода в порт 123" на "вывод в BASE_ADDRESS_OF_DEVICE". Весы в этом случае качаются между слишком навороченными форматами, претендующими на абсолютную универсальность (в результате чего драйвера становятся чрезмерно сложными, и какому-нибудь UART-у приходится рассказывать, что он не накопитель, не поддерживает DMA, имеет 0 байт в дополнительной служебной области, не поддерживает через-пень-колодные-отложенные-вызовы-инициализатора-энумерации-периферийных-субсистем и прочую подобную ерунду), и чрезмерно простыми обвязками, которые по сути умеют только пересылать данные, но не реализуют протоколы обмена. Один из вариантов для Форта - векторизованные слова для обмена с периферией, реализующие только базовую функциональность (или наоборот, по умолчанию работающие со стандартным системным драйвером - навороченным и медленным). По мере появления необходимости векторы переключаются на слова, определенные разработчиком.
SfS писал(а):
Вин СЕ отличается от просто Win XP или Win 98 так же как обращение "государь" от "милостивый государь". И в общем случае работоспособность программы сложнее "Hello world", написанной для WinXP и запускаемой под WinCE - скорее исключение, чем правило. Плюс - win ce - мягко говоря, далека от следования POSIX.

Дело не столько в прямой совместимости, сколько в поддержке современных протоколов, которые очень сложно писать руками. Плюс Microsoft ну никак не захочет отставать от развития рынка, поэтому можно полагать, что при выходе новой железки, пригодной для мобильных устройств, ее поддержка все-таки появится в WinCE. В любом случае, владение и WinCE, и embedded-вариантами Линукса лучше, чем только Линуксом.
SfS писал(а):
Ещё недостатки WinCE - денег оно стоит в итоге.

170 рублей с устройства. Взамен - бренд, и возможность отсыла пользователя к смартфону или КПК, чтобы не приставали с вопросами "почему тут так?". Деньги сегодня не всегда определяющий фактор, баррель-то стоит больше, чем раньше в анекдотах фантазировали. Покупка средств разработки окупается.
SfS писал(а):
Помоему подход к построению форт-системы от ОС не зависит. Более того, могу свою систему под Видовс откомпилировать тем же gcc. У меня там ни одного вызова нет, который Юникс-онли. open() close() malloc() free() - всё и для виндос работает - один в один - насколько я помню.

О чем и речь. Для Форта вполне можно пользоваться протокольным уровнем, написанным на самом Форте, и тогда один и тот же текст будет работать под обоими основными ОС. А до кучи и на embedded-платформе.
SfS писал(а):
все работы по разработке устройства выполнялись в общем одним человеком От составления принципиалльной схемы и разводки платы - до написания ПО.

Полезный на сегодня навык :)
Сообщение Добавлено: Вс июл 27, 2008 10:12
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Форт-периферия (аппаратные или сильно привязанные к формату Форта EMIT, PIXEL, KEY) очень даже реальна. Запуск аппаратного Форта много проще чем просто "какой-то процессор и Форт-машина на нем". Но это детали, да...


По-моему проблема не в том - как занести байт в переферийное устройство, а в том, что данные получаемые/передаваемые от/в переферийного устройство - привязаны к конкретному устройству и жёстких стандартов вообще нет. Поэтому как бы мы не пихали данные в регистр устройства - всё равно придётся писать ДРАЙВЕР, который обслуживает данную конкретную железяку - и никакую более. Ну или класс железяк. Конечно, есть стандартные шины. Но шина - это только формат передачи данных и не более. Сами данные - опять же определяются разработчиком конкретной железки и ни кем более. От уровня прослойки - железо-программа, то есть от уровня драйверов - никуда не уйти. Хоть как извернись. Вопрос только в том - вкомпилировать эти драйвера в форт-систему, в ОС или подгружать их в виде модулей.

Хищник писал(а):
Win CE вполне работает на ARM, а вот XP, и даже XP Embedded действительно x86-only. Вот взять API от WinCE, получив поддержку всего периферийного зоопарка, файловую систему и мультимедиа - это может быть полезным. Правда, с какой стороны реально подступаться к BSP для таких систем, пока не знаю.


Вин СЕ отличается от просто Win XP или Win 98 так же как обращение "государь" от "милостивый государь". И в общем случае работоспособность программы сложнее "Hello world", написанной для WinXP и запускаемой под WinCE - скорее исключение, чем правило. Плюс - win ce - мягко говоря, далека от следования POSIX. Ещё недостатки WinCE - денег оно стоит в итоге. Программу, взятую в репозитории линуксовом/фряшном - а где ещё с открытами текстами брать, чтобы кросскомпилировать ? - уже не поставишь. В общем - WinCE для встраиваемых систем - идёт "ф топпку", IMHO.

Хищник писал(а):
Вот как раз тот самый компонентный подход, только для Windows.


Помоему подход к построению форт-системы от ОС не зависит. Более того, могу свою систему под Видовс откомпилировать тем же gcc. У меня там ни одного вызова нет, который Юникс-онли. open() close() malloc() free() - всё и для виндос работает - один в один - насколько я помню.

Хищник писал(а):
Вообще, я эту штуку уже собираюсь портировать под Линукс. Формат взаимодействия до ужаса тривиальный - библиотеке сбрасываются строки форт-текста (dll экспортирует функцию Evaluate(s : lpstr) : errorpos). Собственно, что именно будет там внутри, будет ли типизация, и какая - совершенно неважно. Важно то, что под IDE (которая proton) можно подкладывать разные dll. Интересно было бы подрихтовать наши две системы до их взаимозаменяемости :)


Ну я под виндовс не пишу уже года этак с 2003го (мелкие приблуды не считаются). Так что специфику уж позабыл.
В студенчестве писал "всё и на всём" :) Пробовал, творил, выдумывал :)
А по работе: сначала писал на ассемблере для AVR, потом на С для него же - системы автоматизации техпроцессов. Поскольку фирма была микроскопическая - все работы по разработке устройства выполнялись в общем одним человеком :) От составления принципиалльной схемы и разводки платы - до написания ПО.
Потом - в 2003м - ушёл в другую контору и занялся Линуксом в плотную. Forth для меня сейчас скорее предмет изучения, чем рабочий инструмент - у нас задачи проще решать взяв набор уже написанного ПО под лин, портировать его, дописать свой интерфейс.

Fortом же я занялся именно когда засел за программирование систем-на-кристалле AT91SAM7S256. Хотелось иметь хороший монитор и возможность удалённо менять ПО. Этим сейчас и занимаюсь. Да и интересно стало.
Сообщение Добавлено: Вс июл 27, 2008 06:25
  Заголовок сообщения:   Ответить с цитатой
SfS писал(а):
Вариант б) сводится к а) практически всегда, поскольку форт-процессор не означает отсутствие периферии. Обычно проблема то не с процессором, а с переферией (встроенной или наружной - не важно).

Форт-периферия (аппаратные или сильно привязанные к формату Форта EMIT, PIXEL, KEY) очень даже реальна. Запуск аппаратного Форта много проще чем просто "какой-то процессор и Форт-машина на нем". Но это детали, да...
SfS писал(а):
Де-факто - Виндовс разработан с жёсткой привязкой к одному типу железа. Поэтому пускать Венду на АРМ

Win CE вполне работает на ARM, а вот XP, и даже XP Embedded действительно x86-only. Вот взять API от WinCE, получив поддержку всего периферийного зоопарка, файловую систему и мультимедиа - это может быть полезным. Правда, с какой стороны реально подступаться к BSP для таких систем, пока не знаю.

SfS писал(а):
Посему проще всё писать под POSIX, а ежели надо это пускать под виндой - то ставишь cyhwin (эмулаятор вызовов юникса для винды) - и большинство проблем снимаются

Ну тут я полностью поддерживаю, поскольку под cygwin пишу для MicroBlaze :) Причем Линукс в основном именно ради POSIX-интерфейсов, ну и до кучи TCP/IP + FAT32, которые вручную на Форте выписать очень трудоемко, и требует знания именно этих областей, и в меньшей степени языка (любого). Поэтому связка "стандартные решения на стандартной платформе" + "Форт для верхнего прикладного слоя, скриптующего вызовы стандартных вещей" весьма и весьма хороша именно из-за разделения стилей работы. Сначала аккуратно выписываем базовую функциональность, не углубляясь в прикладную задачу, потом начинаем быстренько конфигурировать устройство форт-приложениями, где 99% работы по редактированию текста идет именно с форт-программами, которые запускают готовые системные и библиотечные функции (которые, в свою очередь, работают 99% времени).
SfS писал(а):
Кстати - сейчас моя системка компилируется как библиотека, у которой интерфейс из трёх вызовов: инициализация, исполнения форт-файла и деинициализация. Можно её в качестве библиотеки прикрутить куда угодно.

Интерактивной оболчки пока нет - она без средств отладки бесполезна в общем.

Посмотри msyst.ru\quarkexe.zip :)
Там же msyst.ru/quark.pdf
msyst.ru/proton.zip
Вот как раз тот самый компонентный подход, только для Windows.

Вообще, я эту штуку уже собираюсь портировать под Линукс. Формат взаимодействия до ужаса тривиальный - библиотеке сбрасываются строки форт-текста (dll экспортирует функцию Evaluate(s : lpstr) : errorpos). Собственно, что именно будет там внутри, будет ли типизация, и какая - совершенно неважно. Важно то, что под IDE (которая proton) можно подкладывать разные dll. Интересно было бы подрихтовать наши две системы до их взаимозаменяемости :)
Сообщение Добавлено: Сб июл 26, 2008 23:19
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
прямое: Postscript = Forth + Lisp.


Обалдеть! А я и не знал! Спасибо - буду знать.

mOleg писал(а):
понятно, но тогда StrongForth интереснее за счет статической типизации (уж если таковую хочется)
У тебя же подход такой же как в Постскрипте


У меня подход - как проще. :) Мегабыстрые слова - можно на си или асме прописать. Не так уж много их и надо.
Сообщение Добавлено: Сб июл 26, 2008 22:50
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
SfS писал(а):
1. Форт-система на "голом" железе. Без всякой ОС как таковой.

С подвариантами:
а) Форт-система на "голом" железе типа PC, ARM и прочего. Требуется эмуляция стековой машины и разработка драйверов.
б) Форт-система на Форт-процессоре.


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


Хищник писал(а):
Линукс и Windows здесь имеют одинаковые права на существование, и опять же интересно как можно сильнее расширить класс программ, которые одинаково пойдут и там, и там.

Де-факто - Виндовс разработан с жёсткой привязкой к одному типу железа. Поэтому пускать Венду на АРМ или на Спарк какомнибудь - занятие хоть и интересное - но практически неразумное. Посему проще всё писать под POSIX, а ежели надо это пускать под виндой - то ставишь cyhwin (эмулаятор вызовов юникса для винды) - и большинство проблем снимаются.


Хищник писал(а):
Для линукса это, в принципе, нормально. И, если угадаю, Форт туда пришел в том числе и для сокращения количества make all при отладке системы? :)


ну я не знаю для чего туда пришёл форт :) Всёж мне кажется - что просто потому что туда давно портировали все языки какие можно.

Лично меня в первую голову интересует aForth на маленькой ОС NEDOPC-ARMOS на кристалле AT91SAM7S256, что имеет 256К ПЗУ и 64К ОЗУ. Под линуксом я сейчас все аппаратно-независимые вещи тестирую. Быстрее. Как отлажу средства отладки - типа слова traceon, traceoff и trace - буду уже на живом чипе всё запускать.

Тут опять же - когда я писал ту самую NEDOPC-ARMOS - то работу с файлами оформил в виде стандартных POSIX-вызовов. Это позволило практиечески один в один переносить код с Линуса на NEDOPC-ARMOS. Это же позволило и aForth там запустить с первого раза.

Так что - СТАНДАРТЫ РУЛЯТ ! :)

Кстати - сейчас моя системка компилируется как библиотека, у которой интерфейс из трёх вызовов: инициализация, исполнения форт-файла и деинициализация. Можно её в качестве библиотеки прикрутить куда угодно.

Интерактивной оболчки пока нет - она без средств отладки бесполезна в общем.
Сообщение Добавлено: Сб июл 26, 2008 22:46

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB