[quote="ac"]С рувимовым расширением storage.f - можно, уже несколько лет это используется на практике (в Eserv и др.).[/quote]
это не является свойством ядра. когда будет в ядре расширение storage.f - можно будет говорить, что СПФ поддерживает многопоточную компиляцию.
(по крайней мере для меня такой критерий)

[quote="mOleg"]Так же не стоит забывать о том, что одновременное компилирование нескольких слов в память форт может не поддерживать, по крайней мере, в SPF этого делать нельзя даже во временные словари.[/quote]
С рувимовым расширением storage.f - можно, уже несколько лет это используется на практике (в Eserv и др.).

[quote="in4"]mOleg писал(а):Четвертое: все интерфейсные слова необходимо стараться делать таким образом, чтобы они поглощали и возвращали значения, а не ссылки на них. То есть, надо учиться обходиться без реальных адресов.
не понял смысла. Можешь сказать более подробно?
"стараться делать" подразумевает необязательность действия, что не подходит в контексте твоего предложения.[/quote]
смысл в отказе от реальных адресов и указателей. В простых случаях это возможно - то есть имена и метки можно, а адреса и ссылки нельзя.

[quote="in4"]mOleg писал(а):Пятое: не желательно предоставление возможности подключения внешних динамических библиотек, потому что их невозможно контролировать. То есть скрипты должны рассчитывать только на возможности, предоставляемые базовой программой.Вроде это (или аналогичное) сказал в п.1. Может, предложить вообще запретить?
Но применение DLL в скриптах очень удобное расширение. Обсуждаемо.[/quote]
да, не спорю, удобное. Но опасное. То есть, если ты хочешь, чтобы скрипты были безопасны, надо заранее предусмотреть все возможные DLL, и сделать для каждой функции обертку. Причем, всегда есть шанс, что кто-то сделает DLL с тем же именем и с теми же именами функций и сламает защиту. Так что dll в любом случае опасны.

[quote="WingLion"]Кстати, для ссылок можно пользоваться[/quote]
спасибо, уже исправил.

[quote="WingLion"]Кстати, если Limit = 2n-1, то ограничение выхода за пределы делается простым AND с Limit, а старшие биты адреса могут быть использованы для неких иных целей, например, для указания типа адреса или переменной, хранящейся по этому адресу.[/quote]
да, этот вариант обсуждался в статье.
Проблема тут только в том, что выход за диапазон не контролиуется в таком случае.

[quote="WingLion"]Кстати, если Limit = 2ⁿ-1, то ограничение выхода за пределы делается простым AND с Limit, а старшие биты адреса могут быть использованы для неких иных целей, например, для указания типа адреса или переменной, хранящейся по этому адресу.[/quote]
где-то я эту идею уже видел ...

[quote]Изолировать опасные функции от плагина можно в отдельный словарь, который при сборке и работе плагина только и будет доступен. ... Изолировать пространство данных процесса тоже достаточно просто на первый взгляд: надо выделить память в хипе, необходимого размера (этот размер может задавать сам скрипт), и работать с этой памятью, как с именованным массивом, при этом обязательно контролировать выход за пределы массива (либо просто ограничивать адресуемую область). [/quote] вопрос безопасности прочно занял своё место в обсуждении 8) :)

Кстати, если Limit = 2ⁿ-1, то ограничение выхода за пределы делается простым AND с Limit, а старшие биты адреса могут быть использованы для неких иных целей, например, для указания типа адреса или переменной, хранящейся по этому адресу.

Кстати, для ссылок можно пользоваться
[code]<sup>[color=red]1[/color]<sup>[/code]

получится - ^{[color=red]1[/color]}

^{[color=red]1[/color]}- ссылка в верхнем индексе

(с 27 ноя не мог залить :( )

Так почему не хочешь красные числа в качестве ссылок?
А то получается несоответствие - сначала были звездочки, а потом - числа.
[quote="mOleg"]не позволяющий залазить в системные области программы[/quote]обращаться к системным областям. "Залазить" - разговорное и неприменимо в строгом научном тексте.
[quote="mOleg"]Четвертое: все интерфейсные слова необходимо стараться делать таким образом, чтобы они поглощали и возвращали значения, а не ссылки на них. То есть, надо учиться обходиться без реальных адресов.[/quote]не понял смысла. Можешь сказать более подробно?
"стараться делать" подразумевает [b]необязательность[/b] действия, что не подходит в контексте твоего предложения.
[quote="mOleg"]Пятое: не желательно предоставление возможности подключения внешних динамических библиотек, потому что их невозможно контролировать. То есть скрипты должны рассчитывать только на возможности, предоставляемые базовой программой.[/quote]Вроде это (или аналогичное) сказал в п.1. Может, предложить вообще запретить?
Но применение DLL в скриптах очень удобное расширение. Обсуждаемо.
[quote="mOleg"]мощьность[/quote]мощность

Автор: [url=http://fforum.winglion.ru/viewtopic.php?t=1240]mOleg[/url]
Дата публикации: 2008-11-26
публикуется впервые

[color=blue][size=200]Скрипты и плагины в Форте[/size][/color]

[size=150][color=green]Аннотация[/color][/size]

В статье предлагается размышление о том, как можно реализовать в форт-программах скрипты^{[color=red]1[/color]} и плагины^{[color=red]2[/color]}, то есть куски исходного текста и бинарного кода, создаваемые не разработчиком программы, а ее пользователем для получения дополнительной функциональности уже готовой программы. Так как обычно программы, написанные на форте, уже содержат в себе компилятор^{[color=red]3[/color]}, а так же, обычно, обращаются к функциям по их именам, такая идея кажется очень удобной и перспективной, даже присущей Форту. Часто создатель программы не может предусмотреть всех возможных направлений использования программы, а так же ряда удобств, которые реализовать очень просто пользователю, не отвлекая программиста. Однако, при реализации такого подхода, если не забывать об устойчивости программы (то есть скрипты и плагины не должны «ронять» работающую программу), а так же о безопасности (чтобы кто-то не написал деструктивный код в виде скрипта), возникают довольно серьезные проблемы.

[size=150][color=green]Введение[/color][/size]
Форт устроен очень удобно с точки зрения встраивания новой функциональности в уже существующие программы, то есть на первый взгляд очень легко и естественно можно реализовать скрипты. В реальности же все не так гладко, потому что некорректное использование ряда слов^{[color=red]4[/color]} гарантированно приводит к критическому завершению работы программы. В ряде случаев форт слишком открыт для вмешательств, что одновременно является и его сильной стороной и его большой слабостью.
На данный момент времени все Форты (виденные мною) устроены по уязвимой схеме, в которой данные, код, различные критические внутренние структуры доступны вмешательству, поэтому могут быть «исправлены» или запорчены случайно в результате ошибки или преднамеренно, в том числе злонамеренно. Это одновременно и хорошо, если управляемо, и плохо, так как невозможно обезопасить скрипты. Из-за стремления к быстродействию, нежелания реализовывать сложные схемы работы с памятью, а так же, зачастую, неизбежного наследования модели памяти, предлагаемой операционной системой, под которой работает форт-программа, делать скрипты в форте не так просто, как может показаться на первый взгляд. Существуют методики создания безопасных интерфейсов, но все они имеют свои ограничения и проблемы.

[size=150][color=green]Анализ[/color][/size]

Наиболее опасными словами в Форт-системе, а значит и в программе, в первую очередь являются слова для работы с памятью: @ ! CMOVE и подобные им; после них, конечно же, идут системные переменные и слова для работы с ними, например: S0 R0 SP! RP! DP LAST и им подобные; слова, работающие со стеком возвратов: >R R> RDROP R@ и т.п.; а так же слова или конструкции слов, передающие управление на указанный адрес (а не на фиксированную метку): EXECUTE CATCH и подобные, либо пары слов: >R EXIT и т.п., а так же RECURSE. Соответственно, за ними идут слова, работающие с файлами. Не стоит забывать о потенциальной опасности переполнения стеков, утечек памяти (что критично в программах, которые должны работать непрерывно на протяжении длительного времени), а так же потенциальной опасности несовместимости некоторых слов (то есть такая последовательность «безопасных» слов, которая приводит к исключению, например, деление на нуль).
Стоит отметить, что плагины в форте удобно представлять их исходными текстами (то есть скриптами), так как скорость компиляции кода очень высока, а плагины редко бывают очень большими. В то же время бинарные плагины лучше оформлять как пару: dll-библиотека + инициализирующий исходный текст, который подключит dll, импортирует нужные функции, произведет необходимые инициализирующие действия и передаст управление на необходимый код. Однако же, контролировать dll мы не в состоянии, поэтому этот вариант дальше в тексте рассматриваться не будет. Реализация же поддержки бинарного кода внутри форт-системы вещь редкая и достаточно нетривиальная (я знаю только одну такую форт систему SMAL32) поэтому дальше будут рассматриваться только скрипты.

Итак, первый вывод: при необходимости обеспечения надежной работы программы, поддерживающей механизм скриптов, необходимо изолировать опасные функции, имеющиеся в словарях программы от скриптов.
Второе: при работе с файлами необходимо контролировать действия плагина, например, не давать открывать dll и исполнимые файлы, не давать возможности выходить за пределы определенных каталогов, не давать открывать самостоятельно файловые потоки и тому подобное.
Третье: так как обойтись при решении более-менее серьезной задачи без переменных и массивов в памяти (в том числе динамических) невозможно, необходим некий набор слов для работы с памятью, не позволяющий залазить в системные области программы.
Четвертое: все интерфейсные слова необходимо стараться делать таким образом, чтобы они поглощали и возвращали значения, а не ссылки на них. То есть, надо учиться обходиться без реальных адресов.
Пятое: не желательно предоставление возможности подключения внешних динамических библиотек, потому что их невозможно контролировать. То есть скрипты должны рассчитывать только на возможности, предоставляемые базовой программой.

[size=150][color=green]Изоляция опасных слов[/color][/size]
Изолировать опасные функции от плагина можно в отдельный словарь, который при сборке и работе плагина только и будет доступен. Для SPF это может выглядеть так:
<pre>
\ создаем словарь, в котором будут находиться общие для всех плагинов слова
VOCABULARY Interface
\ создаем словарь, в котором будут находиться все плагины
VOCABULARY Plugins

\ создается словарь, определяемый именем плагина
\ (вероятно это будет имя файла, содержащего исходный текст плагина,
\ но в данном случае имя плагина будет идти за определяющим словом Plugin:
: Plugin: ( / name --> )
ALSO Plugins DEFINITIONS \ в словаре Plugins
VOCABULARY \ создается словарь с именем name
ONLY Interface \ оставляется в контексте только интерфейсный словарь
ALSO \ поверх интерфейсного словаря
VOC-LIST @ CELL + CONTEXT ! \ кладется созданный словарь name
DEFINITIONS \ и делается текущим
;

\ добавляем слова, доступные любому плагину, то есть: создаем интерфейс
ALSO Interface DEFINITIONS

: WORDS WORDS ; \ в данном случае создается заголовок в словаре Interface
: BYE TERMINATE ; \ для уже существующих в словаре FORTH слов.
: ORDER ORDER ;
: : : ;
: ; [COMPILE] ; ; IMMEDIATE
\ …и другие слова, доступные плагину…

PREVIOUS DEFINITIONS

\ Теперь можно попробовать посмотреть что получилось:
Plugin: test
ORDER \ enter –
\ должен показать в контексте два словаря: Interface test и
\ test текущим словарем, то есть словарем, в который будет в дальнейшем вестись
\ компиляция
BYE
\ позволит нам завершить процесс плагина
</pre>
Впрочем, каждый скрипт должен работать в собственном потоке, что удобно уже потому, что завершение потока не приведет к завершению программы. Так же удобно автоматическое освобождение блоков памяти, занятых в хипе при завершении процесса. Поэтому так же необходимо предусмотреть некий механизм, инициализирующий контекст таким образом, чтобы в нем были только необходимые для работы словари, и, соответственно, слова. Кроме того, если предполагать, что скрипт может быть завершен принудительно, либо в результате ошибки, либо после выполнения предназначенных действий самостоятельно, стоит позаботиться об удалении кода скрипта, словаря, в котором этот скрипт находится. Перечисленные действия реализовать, например, в SPF не так уж и просто, поэтому в рамках данной статьи они рассматриваться не будут. Компилирующие структуры должны использовать изолированный стек, не давая перехватить и подменить адреса переходов.

[size=150][color=green]Изоляция адресного пространства[/color][/size]
Изолировать пространство данных процесса тоже достаточно просто на первый взгляд: надо выделить память в хипе, необходимого размера (этот размер может задавать сам скрипт), и работать с этой памятью, как с именованным массивом, при этом обязательно контролировать выход за пределы массива (либо просто ограничивать адресуемую область). Например, если базовый адрес памяти хранится в переменной Memory , а размер этой памяти в переменной Limit , можно переписать слова @ ! следующим образом:
<pre>
: ! ( n addr --> )
Limit OVER > THROW \ если хочется контролировать выход за диапазон, либо:
\ Limit UMIN \ если хочется ограничить выход за предел диапазона
Memory + \ получить реальный адрес переменной
! \ сохранить значение
;
</pre>
Кстати, переменная Limit должна быть на один CELL меньше, реально выделенной памяти. Точнее, реально выделенная память должна быть на один CELL больше запрашиваемой, которая будет храниться в Limit, либо придется учитывать размерность данных, записываемых в массив, чтобы не выйти за его границы при работе с крайними адресами.

Аналогично будет выглядеть слово @ :
<pre>
: @ ( addr --> n )
Limit UMIN \ обязательно беззнаковый, чтобы не нарваться на отрицательные адреса.
Memory +
@ ;
</pre>
Пересылки будут выглядеть чуточку сложнее, но для иллюстрации идеи достаточно рассмотрения слов @ и ! . Проблема только в том, что постоянная проверка выхода за адресуемый диапазон отнимает время, но с потерей производительности в любом случае придется мириться.
В принципе, похожий механизм уже используется в системе при работе с USER переменными, однако,
USER переменные возвращают реальные адреса, с которыми работает классический @ и ! , что нас никоим образом не устраивает, хотя можно ограничиться только USER-VALUE переменными. К тому же USER область по умолчанию не очень велика, и содержит много не нужных и даже опасных данных, например, переменные S0 R0 .
Кроме того, как уже отмечалось, код самого скрипта необходимо компилировать не в базовую область программы, а в какое-то отдельное адресное пространство (в SPF для этого можно использовать TEMP-WORDLIST). Так же не стоит забывать о том, что одновременное компилирование нескольких слов в память форт может не поддерживать, по крайней мере, в SPF этого делать нельзя даже во временные словари.

[size=150][color=green]Другие варианты[/color][/size]
Перечисленные методики обладают неприятным качеством – они ограничивают возможности скрипта, методики работы в рамках форт-системы, то есть требуют создания некоего специфичного проблемно-ориентированного языка с ограниченной функциональностью, что не всегда приемлемо. То есть получившийся язык не будет обладать гибкостью классического форта и будет иметь другой, пусть и близкий, набор слов (наследование традиционных имен может привести к путанице). Возможным выходом из данного положения видится создание защищенной виртуальной машины и форта на ее основе, который бы просто не давал возможности выходить на системный уровень и не давал непредвиденным заранее образом влиять на базовую программу, либо такая машина должна подключаться к готовой программе. Однако же, вся гибкость, мощьность, свобода форта не обязательно необходимы при создании интерфейсов для скриптов (или плагинов), поэтому без специфичных ВМ все-таки можно обойтись в большом количестве случаев.

[size=59][color=red]1[/color]. исходные тексты, подключаемые средствами программы, позволяющие автоматизировать некую задачу, которую без сценария пользователь делал бы вручную, используя интерфейс программы.
[color=red]2[/color]. независимые бинарные модули, подключаемые к программе через специализированный интерфейс
[color=red]3[/color]. очень редко форт содержит в себе только код, относящийся к программе, обычно форт-программа наследует компилятор, на котором она создана
[color=red]4[/color]. в современном программировании принято программу разделять на небольшие куски, так называемые подпрограммы или функции – в форте такие куски принято называть определениями или словами
[/size]