SPF5 vision

[Ruvim Pinka]

Привет всем!

Об SPF5 разработчики SPF4 грезят по крайней мере с 2004-го, а то и раньше (архива писем под рукой нету).
Неспеша мы вынашиваем наши идеи и испытываем прототипы... И по всему становится видно, что его время приближается. Ниже  привожу, как я вижу следующую версию системы. Ожидаю ответных идей, возражений, дополнений и т.п (только не надо целиком все цитировать ;). Будет хорошо, если мы сформируем общую цель (как образ ясного результата).


Критерии 5-ой версии

1. Явно-прослеживаемая генетика от SPF4 (иначе — почему это вообще SPF ;)
2. Развитие заложенных в SPF4 идей и реализация новых. Это неизбежно влечет изменение многих механизмов ядра, поэтому старые расширения могут быть не совместимы с новой системой, и значит, логично ему быть 5-ым.
3. Консенсус разработчиков предыдущих версий SPF о выполнении перечисленных пунктов в отношении единственной системы (наследник короны только один :)
   

Система ценностей

• Человеческий труд ценней машинного. Исходый код, то, что делается руками, — это главное :)
  
• Долговременная выгода важней сиюминутной (т.к. работает закон сложного процента ;). Поддержка, модификация и повторное использование кода важней, чем время, затраченное на первичное написание этого кода.
• Гармония формы и содержания; это формально не описывается, и ощущается сугубо человеком ;)  SPF — это редкий продукт ручной выделки в единственном экземпляре (поймите меня правильно :), поэтому лучше дольше подумать (мы помним, что упрощать сложно :) и сделать проще и красивей, чем быстро и абы как.
  

Общая стуктура

1. Микроядро (типа spf5-mc.exe). Представляет собой простейший интерпретатор стандартного входного потока (STDIN).
   
• Предоставляет необходимый и достаточный набор слов для расширения системы до уровня базового транслятора.
• Задает такие параметры системы как размер ячейки, размер символа, основной формат откладываемого кода, средства связи с операционной системой или другим окружением, и т.п.
  
2. Базовый транслятор (типа spf5.exe). Форт-транслятор уровня ANS (не обязательно совместимый), собираемый на основе микроядра (путем его расширения и сохранения исполнимого образа).
3. Набор компонентов в исходном виде, включающий:
• расширения базового транслятора (для совместимости с ANS, с SPF4, поддержки неких парадигм и т.п.);
• расширения микроядра (зависимые от окружения форт-системы);
• базовый набор библиотек (ANS-совместимых, возможно, с простой прослойкой);
• сложные расширения (включающие компоненты разных уровней: расширения микроядра, транслятора, независимый высокоуровневый код, базируемый на прослойке совместимости).

Микроядро

Его принцип: для портирования базового транслятора достаточно портировать микроядро.

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

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

Для минимизации микроядра оно наделено лишь умением интерпретировать слова. Нету STATE и режимов. Нету слов немедленного исполнения, в том числе и управляющих конструкций. Нету способа заглянуть вперед по входному потоку. Нету различия строк ( REFILL ). Нету подключения файлов ( INCLUDED ). Есть лишь сплошной поток слов на входе и способ маскировки однословных строк, все. :)   Это похоже на colorForth. Правда, писать код специфично для этого интерпретатора я нахожу неудобным. Удобным же нахожу транслировать нормальный код в упращенный поток слов для микроядра. Например, так: msxsl.exe spf5-index.xml spf5-mc.xsl | spf5-mc.exe  (в этом случае исходник, естественно, размечен в XML, например  в ForthML, о котором я писал на wiki),  или так: spf4.exe spf5-mc.trans.f spf5-index.f | spf5-mc.exe. На выходе получаем spf5.exe.

Каждый, кто разбирался с исходниками SPF4, должен был заметить, что в ЦК (tc_spf.f) часто дублируется код из самого ядра, когда лучше было бы подключить имеющийся код. Эту ситуацию стоит разрулить.
Исходники самого микроядра должны быть представлены в том же виде, что и исходники базового транслятора, с тем, чтобы их было легко преобразовать в поток исполняющихся слов. Тогда целевой компилятор будет предельно прост — это будет такой же интерпретатор, какой реализуется микроядром, и для сборки ЦК можно будет использовать исходники самого микроядра. Исходный код микроядра не должен быть завязан на ЦК — что означает, что он целиком (за исключением, быть может, нескольких оберток) должен загружаться в форт-систему без всякого ЦК.


Базовый транслятор

В нем видиться развитие и реализация следующих идей:

• отделение хранилищ от списков слов;
• отделение трансляторов слов от списков слов;
  
• детальный постфиксный способ создания и именования статей отложенного кода;
• поддержка различных моделей связывания при откладывании (немедленное, позднее в указанном контекста, позднее в позднем контексте);
• по возможности, независимость представления исходного кода от того, будет он исполнен немедленно или отложен (!);
• вложенное откладывание кода;
• улучшение рефлексии форт-системы (путем ведения дополнительных списков объектов и др.);
  
• еще?
  

Общии тенденции в поддержку следующих подходов:

• предпочтение именованным (тем или иным способом) объектам, которые будут долго жить и многократно  использоваться, по сравнению с созданием и удалением анонимных объектов каждый раз; такой подход дает некоторое упрощение при отсутствии автоматической сборки мусора;
• использование на верхнем уровне крупных замыканий и позднего связывания вместо параметризации функций; жесткая привязка кода к данным упрощает код, но требует простой возможности динамически откладывать код (генерить исполнимый код наравне с созданием объектов-данных).
  

Далее...

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


--
Ruvim

[Dmitry Yakimov-2]

Привет,

Ruvim Pinka wrote:
> Система ценностей
>
>     * Человеческий труд ценней машинного. Исходый код, то, что
>       делается руками, — это главное :)
>

Хочу добавить что в SPF5 должно быть ассемблера по минимуму. Основную
задачу по оптимизации надо предоставить машине.

>    1. Микроядро (типа spf5-mc.exe). Представляет собой простейший
>       интерпретатор стандартного входного потока (STDIN).
>           * Предоставляет необходимый и достаточный набор слов для
>             расширения системы до уровня базового транслятора.
>           * Задает такие параметры системы как размер ячейки, размер
>             символа, основной формат откладываемого кода, средства
>             связи с операционной системой или другим окружением, и т.п.
>    2. Базовый транслятор (типа spf5.exe). Форт-транслятор уровня ANS
>       (не обязательно совместимый), собираемый на основе микроядра
>       (путем его расширения и сохранения исполнимого образа).
>    3. Набор компонентов в исходном виде, включающий:
>           * расширения базового транслятора (для совместимости с ANS,
>             с SPF4, поддержки неких парадигм и т.п.);
>           * расширения микроядра (зависимые от окружения форт-системы);
>           * базовый набор библиотек (ANS-совместимых, возможно, с
>             простой прослойкой);
>           * сложные расширения (включающие компоненты разных уровней:
>             расширения микроядра, транслятора, независимый
>             высокоуровневый код, базируемый на прослойке совместимости).
>
>

С этим согласен.

> Микроядро
>
> Его принцип: для портирования базового транслятора достаточно
> портировать микроядро.
>
> Может быть несколько вариантов микроядра, различающихся такими
> деталями как размер символа, размер ячейки, хранить ли вершину стека в
> регистре, для каких целей использовать аппаратный стек, включен ли
> оптимизатор, совмещены ли хранилища кода и данных, и т.п. Далее, можно
> легко проводить сравнительные испытания, какой вариант быстрей или
> меньше. По идее, JIT-компилятор тоже на этом уровне может обитать —
> например, при первом исполнении ранее отложенного кода (отложенного в
> виде косвенного шитого, например) он может длинно разворачивать его в
> машинный.

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

Далее - предлагаю сделать основное ядро. В котором мы все будем
работать. Все остальные будут сделаны по желанию.
Форматом словарной статьи для основного ядра предлагаю сделать прямой
шитый код. К нему позже будет легко подключить JIT.
Более того, можно будет реализовать ahead time compilation - собирание
чистого exe (или dll) из приямого шитого кода с помощю JIT.

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

В тему же - WINAPI: слово должно быть с указание количества параметров.
Например потому что на WinCE тупое копирование 15 параметров не пройдет,
там стек очищает тот кого вызвали, а не тот кто вызывает. А также чтобы
не сбивать оптимизатор от распределения регистров.

Данные предлагаю отделить от кода. Тогда SPF можно будет зашивать в ROM
(в оптимизированном или нет виде).

>
> Микроядро должно предоставить достаточный набор слов, чтобы реализация
> базового транслятора не зависела от окружения форт-системы, и в нем не
> должно быть никаких лишних высокоуровневых определений.
>
> Для минимизации микроядра оно наделено лишь умением интерпретировать
> слова. Нету STATE и режимов. Нету слов немедленного исполнения, в том
> числе и управляющих конструкций. Нету способа заглянуть вперед по
> входному потоку. Нету различия строк ( REFILL ). Нету подключения
> файлов ( INCLUDED ). Есть лишь сплошной поток слов на входе и способ
> маскировки однословных строк, все. :) Это похоже на colorForth.

Я бы сказал machineForth.
> Правда, писать код специфично для этого интерпретатора я нахожу
> неудобным. Удобным же нахожу транслировать нормальный код в упращенный
> поток слов для микроядра. Например, так: msxsl.exe spf5-index.xml
> spf5-mc.xsl | spf5-mc.exe (в этом случае исходник, естественно,
> размечен в XML, например в ForthML, о котором я писал на wiki), или
> так: spf4.exe spf5-mc.trans.f spf5-index.f | spf5-mc.exe. На выходе
> получаем spf5.exe.

Можно и так. Выход пишется в exe, ошибки в поток ошибок.

>
> Каждый, кто разбирался с исходниками SPF4, должен был заметить, что в
> ЦК (tc_spf.f) часто дублируется код из самого ядра, когда лучше было
> бы подключить имеющийся код. Эту ситуацию стоит разрулить.
> Исходники самого микроядра должны быть представлены в том же виде, что
> и исходники базового транслятора, с тем, чтобы их было легко
> преобразовать в поток исполняющихся слов. Тогда целевой компилятор
> будет предельно прост — это будет такой же интерпретатор, какой
> реализуется микроядром, и для сборки ЦК можно будет использовать
> исходники самого микроядра. Исходный код микроядра не должен быть
> завязан на ЦК — что означает, что он целиком (за исключением, быть
> может, нескольких оберток) должен загружаться в форт-систему без
> всякого ЦК.
>
>
> Базовый транслятор
>
> В нем видиться развитие и реализация следующих идей:
>
>     * отделение хранилищ от списков слов;
>

Да да, пространство имен. Предлагаю как в DSF - хранить в текстовом
файле (с возможность брать этот текстовый файл из памяти, для ROM).

>     * отделение трансляторов слов от списков слов;
>
Абстрактный API?
>
>     * детальный постфиксный способ создания и именования статей
>       отложенного кода;
>     * поддержка различных моделей связывания при откладывании
>       (немедленное, позднее в указанном контекста, позднее в позднем
>       контексте);
>
А подробнее?
>
>     * по возможности, независимость представления исходного кода от
>       того, будет он исполнен немедленно или отложен (!);
>

Это как?
>
>     * вложенное откладывание кода;
>

Это как?

>
>     * улучшение рефлексии форт-системы (путем ведения дополнительных
>       списков объектов и др.);
>     * еще?
>
> Общии тенденции в поддержку следующих подходов:
>
>     * предпочтение именованным (тем или иным способом) объектам,
>       которые будут долго жить и многократно использоваться, по
>       сравнению с созданием и удалением анонимных объектов каждый раз;
>       такой подход дает некоторое упрощение при отсутствии
>       автоматической сборки мусора;
>     * использование на верхнем уровне крупных замыканий и позднего
>       связывания вместо параметризации функций; жесткая привязка кода
>       к данным упрощает код, но требует простой возможности
>       динамически откладывать код (генерить исполнимый код наравне с
>       созданием объектов-данных).
>
>
> Далее...
>
> ToDo: сделать детализацию способов достижения поставленных планок;

Как ты это представляешь? Я прямо сейчас детализую - надо сесть и начать
писать :)

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

Да, надо писать микроядра одновременно для x86 x86-64 (Win32), ARM
(WinCE), x86 x86-64 Linux.
Тогда получится учесть аппаратные особенности.

Я пару месяцев назад начал набрасывать платформо-независимый CORE слов
ANS 94 - не зависит от размера CELL, от ОС, от формата словарной статьи,
двигаюсь медленно.

--
Dmitry

[Aleksej Saushev]

"Ruvim Pinka" <[hidden email]> writes:

> Система ценностей
>
>   • Человеческий труд ценней машинного. Исходый код, то, что делается руками, —
>     это главное :)
>   • Долговременная выгода важней сиюминутной (т.к. работает закон сложного
>     процента ;). Поддержка, модификация и повторное использование кода важней,
>     чем время, затраченное на первичное написание этого кода.
>   • Гармония формы и содержания; это формально не описывается, и ощущается
>     сугубо человеком ;)  SPF — это редкий продукт ручной выделки в единственном
>     экземпляре (поймите меня правильно :), поэтому лучше дольше подумать (мы
>     помним, что упрощать сложно :) и сделать проще и красивей, чем быстро и абы
>     как.
>
>
> Общая стуктура
>
>  1. Микроядро (типа spf5-mc.exe). Представляет собой простейший интерпретатор
>     стандартного входного потока (STDIN).
>       □ Предоставляет необходимый и достаточный набор слов для расширения
>         системы до уровня базового транслятора.
>       □ Задает такие параметры системы как размер ячейки, размер символа,
>         основной формат откладываемого кода, средства связи с операционной
>         системой или другим окружением, и т.п.

Известно про postForth?

> Микроядро
>
> Его принцип: для портирования базового транслятора достаточно портировать
> микроядро.

Мне это не очень нравится.

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

> Для минимизации микроядра оно наделено лишь умением интерпретировать слова.
> Нету STATE и режимов. Нету слов немедленного исполнения, в том числе и
> управляющих конструкций. Нету способа заглянуть вперед по входному потоку. Нету
> различия строк ( REFILL ). Нету подключения файлов ( INCLUDED ). Есть лишь
> сплошной поток слов на входе и способ маскировки однословных строк, все. :)  

Если с вырезанием INCLUDED ещё можно согласиться, с вырезанием
REFILL пропадают даже комментарии до конца строки.

> Это похоже на colorForth. Правда, писать код специфично для этого
> интерпретатора я нахожу неудобным. Удобным же нахожу транслировать нормальный
> код в упращенный поток слов для микроядра. Например, так: msxsl.exe
> spf5-index.xml spf5-mc.xsl | spf5-mc.exe  (в этом случае исходник, естественно,
> размечен в XML, например  в ForthML, о котором я писал на wiki),  или так:
> spf4.exe spf5-mc.trans.f spf5-index.f | spf5-mc.exe. На выходе получаем
> spf5.exe.

Плохая мысль.

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

> Каждый, кто разбирался с исходниками SPF4, должен был заметить, что в ЦК
> (tc_spf.f) часто дублируется код из самого ядра, когда лучше было бы подключить
> имеющийся код. Эту ситуацию стоит разрулить.

Да, это непорядок.

Ещё мне по DragonForth не понравился стиль с лишними префиксами "TC-".
Я думаю, как это устранить получше.

> Базовый транслятор
>
> В нем видиться развитие и реализация следующих идей:
        ~~~~~~~~

Пожалуйста! Ты не представляешь, как это раздражает некоторых людей.

> Далее...
>
> ToDo: сделать детализацию способов достижения поставленных планок; сформировать
> список требований, которым должно отвечать микроядро и базовый транслятор
> форт-системы SPF5; проработать и сформировать структуры каталогов, форматы
> файлов, способ сборки с тем, чтобы поддерживать альтернативные сборки (под
> различное окружение и с различной реализацией): куда класть код, зависимый от
> ОС, куда зависимый от процессора, а куда от того и другого.

Надо бы предусмотреть сборку под какой-нибудь FICL или pForth.

[Aleksej Saushev]

Dmitry Yakimov <[hidden email]> writes:

> JIT потребует точного знания длины слова, поэтому необходимо будет
> выделить слово в словарной статье под это.

Все константы должны рассчитываться, а не зашиваться.
Код не должен использовать порядок полей.

> JIT должен знать еще о примитивах - их стековую нотацию.
>
> В тему же - WINAPI: слово должно быть с указание количества параметров.
> Например потому что на WinCE тупое копирование 15 параметров не пройдет,
> там стек очищает тот кого вызвали, а не тот кто вызывает. А также чтобы
> не сбивать оптимизатор от распределения регистров.

Что там Эртль написал по поводу переносимого FFI, разбирался?
Я ещё не успел.

>> сформировать список требований, которым должно отвечать микроядро и
>> базовый транслятор форт-системы SPF5; проработать и сформировать
>> структуры каталогов, форматы файлов, способ сборки с тем, чтобы
>> поддерживать альтернативные сборки (под различное окружение и с
>> различной реализацией): куда класть код, зависимый от ОС, куда
>> зависимый от процессора, а куда от того и другого.
>>
>
> Да, надо писать микроядра одновременно для x86 x86-64 (Win32), ARM
> (WinCE), x86 x86-64 Linux.

x86/BSD, PPC(?)

> Тогда получится учесть аппаратные особенности.
>
> Я пару месяцев назад начал набрасывать платформо-независимый CORE слов
> ANS 94 - не зависит от размера CELL, от ОС, от формата словарной статьи,
> двигаюсь медленно.

Чего не хватает?

[Ruvim Pinka]

Привет!

On 12/9/06, Dmitry Yakimov <[hidden email]> wrote:

>     * отделение хранилищ от списков слов;

TEMP-WORDLIST — это сейчас одновременно и хранилище и список слов. Если в нем создать обычный словарь ( WORDLIST или VOCABULARY ) и начать добавлять в него слова, то код пойдет в основное хранилище, а не во временное.

>     * отделение трансляторов слов от списков слов;
>

Абстрактный API?

NOTFOUND является абстрактным транслятором слов, но оно жестко привязанно к списку слов (и ORDER).  Изначально же лучше быть ему отвязанным, а привязывать можно опционально.
 

>     * поддержка различных моделей связывания при откладывании
>       (немедленное, позднее в указанном контекста, позднее в позднем
>       контексте);
>
А подробнее?

Все это известно, просто я непонятно выразился :(

: ttt a B C D ;  это откладывание исполнения "a B C D" под именем ttt с немедленным связыванием (разрешением имен).

: ttt S" a B C D " EVALUATE ;  это откладывание с поздним связыванием в позднем контексте.

: ttt S" S' a B C D' EVALUATE " EVALUATE ;  это вложенное откладывание.

Правда, разметка кавычками дает скудные возможности.

Мне нужны простые возможности откладывания на уровне таких динамических языков как ECMAScript (JavaScript) и Ruby :)  Сложные способы сделать это есть и так, я же делаю реализацию простых :)

В реализации же они сложны, поэтому в простых форт-системах они не находят места.

>     * по возможности, независимость представления исходного кода от
>       того, будет он исполнен немедленно или отложен (!);
Это как?

а так, что немедленно используется   [IF] ' abc [THEN]
а при откладывании: IF ['] abc THEN

код имеет разное представление, хотя суть та же.
Одна из причин — вредное заглядывание вперед, а по большому счету проблема в том, что сделать маскировку произвольноко куска текста довольно трудно. Хорошо же эту задачу решает xml :)

--
Ruvim

[Ruvim Pinka]

Привет!

On 12/10/06, Aleksej Saushev <[hidden email]> wrote:
>  Известно про postForth?

нет, расскажи пожалуйста.


> > для портирования базового транслятора достаточно портировать микроядро.
>
> Мне это не очень нравится.
>
> Форматы исполняемых образов сильно отличаются в разных
> операционных системах, поэтому не очень ясно, куда идёт
> соответствующий код.

Дык, SAVE располагается в микроядре. Какие еще возражения?

> Если с вырезанием INCLUDED ещё можно согласиться, с вырезанием
> REFILL пропадают даже комментарии до конца строки.

Слово "\" может парсить до разделителя строк. Но, в моем списке нет
заглядывания вперед.
Поэтому, и комментариев нет. Этот интерпретатор не для человеческого
ввода, а для машинного.

> Писать текстовый препроцессор --- однозначно плохая мысль.

1. это не препроцессор, а некий "компилятор" (это гораздо проще, чем,
например, компилировать в Си-код);
2. Писать XSL очень легко, и раз написанный он служит годами :)
3. Такая прослойка дает некую независимость исходного кода от деталей
интерпретатора. Сменил прослойку -- получил код для другого
интерпретатора с его особенностями.

> Это и идеологически неверно.

Обоснуй, пожалуйста.


> > В нем видиться развитие и реализация следующих идей:
>         ~~~~~~~~
> Пожалуйста! Ты не представляешь, как это раздражает некоторых людей.

ты имеешь ввиду орфографическии  ошибки? Да, бывает у меня
проскакивает "ть"  не замеченным, оно на автомате как и другие
опечатки.

--
Ruvim

PS нашел, чего в первый раз не прошло письмо.

[Ruvim Pinka]

On 12/10/06, Ruvim Pinka <[hidden email]> wrote:

> >  Известно про postForth?
>
> нет, расскажи пожалуйста.

Прочитал обзор. Это маленькое форт-ядро, с поздним (динамическим)
связыванием, как в PostScript, доступен для DOS и Linux. Автору
хотелось уложить его в 400 строк исходников и 1 кб исполнимого кода,
должно быть, удалось.  Не обновлялось с 2000-го года.

Вобчем, на что был намек, я не понял :)

--
Ruvim

[Aleksej Saushev]

"Ruvim Pinka" <[hidden email]> writes:

> On 12/10/06, Aleksej Saushev <[hidden email]> wrote:

>>  Известно про postForth?
>
> нет, расскажи пожалуйста.

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

>> > для портирования базового транслятора достаточно портировать микроядро.
>>
>> Мне это не очень нравится.
>>
>> Форматы исполняемых образов сильно отличаются в разных
>> операционных системах, поэтому не очень ясно, куда идёт
>> соответствующий код.
>
> Дык, SAVE располагается в микроядре. Какие еще возражения?

Возражения будут.
SAVE может быть слишком сложным, отчего запихивание в микроядро
теряет смысл: ядро перестаёт быть "микро".  Если оставить
разумное микроядро, то можно получить скромный загрузчик,
например, для медленных или несильно быстрых скриптовых задач.

>> Писать текстовый препроцессор --- однозначно плохая мысль.
>
> 1. это не препроцессор, а некий "компилятор" (это гораздо проще, чем,
> например, компилировать в Си-код);
> 2. Писать XSL очень легко, и раз написанный он служит годами :)

Покуда существует соответствующий процессор.

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

Про вред текстовых процессоров написано немало.
Основная претензия: они слишком неочевидно работают.
Из-за этого в схеме придумали "правильные" макросы.

>> > В нем видиться развитие и реализация следующих идей:
>>         ~~~~~~~~
>> Пожалуйста! Ты не представляешь, как это раздражает некоторых людей.
>
> ты имеешь ввиду орфографическии  ошибки? Да, бывает у меня
> проскакивает "ть"  не замеченным, оно на автомате как и другие
> опечатки.

Я сталкивался с тем, что некоторые вообще это не переносят, да и
меня самого это иногда раздражает.

[Andrey Cherezov]

Добрый день, Aleksej Saushev!

Ваше сообщение от 10.12.2006 22:16:
> SAVE может быть слишком сложным, отчего запихивание в микроядро
> теряет смысл: ядро перестаёт быть "микро".  Если оставить
> разумное микроядро, то можно получить скромный загрузчик,
> например, для медленных или несильно быстрых скриптовых задач.
>  
Да, я тоже думаю, что SAVE можно из ядра SPF5 убрать, и его можно будет
подключать как либу в тех случаях, когда требуется сохранение бинарника.
К тому же это может быть платформозависимо; даже под виндой у нас есть
четыре разных SAVE - без ресурсов, с ресурсами, с relocations (DLL), с
цифровой подписью (Eserv/3). Может и другие.

Теоретически можно из ядра убрать даже возможность компиляции и
создания словарных статей, оставив минимум в виде "C," и т.п.
Насколько это полезно практически (для некомпилируемых скриптов) -
не знаю.

[Ruvim Pinka]

Привет!
да, насчет SAVE согласен, убедили :)
Значит, для сохранения образа надо делать подключение некого
системно-зависемого модуля, желательно иметь возможность подключить
его во временное хранилище (чтобы сам он не шел в сохраняемый образ).
Чтобы подключать его прозрачно, и код не зависел от варианта ОС, в
микроядро вшить тэг (идентификатор ОС), который будет использоваться
для вычисления имени этого модуля.

Да, в микроядре можно обойтись и без компиляции кода, но тогда будет
удобней делать три ядра, вместо двух (т.к. компиляция может зависеть
от процессора):
mc0.exe дает стеки, арифметику, память, хранилище;
mc1.exe дает компиляцию, создание именованных статей, доступ к ОС;
spf5.exe  дает полноценный транслятор.

Обсуждаемо. Пока я не вижу особых преимуществ такого подхода по
сравнению с двумя образами ( spf5-mc.exe и spf5.exe ).

On 12/11/06, Andrey Cherezov <[hidden email]> wrote:
> Добрый день, Aleksej Saushev!
> > SAVE может быть слишком сложным, отчего запихивание в микроядро

> Да, я тоже думаю, что SAVE можно из ядра SPF5 убрать, и его можно будет

> Теоретически можно из ядра убрать даже возможность компиляции и
> создания словарных статей, оставив минимум в виде "C," и т.п.

--
Ruvim

[Dmitry Yakimov-2]

Привет,

Aleksej Saushev wrote:

> Dmitry Yakimov <[hidden email]> writes:
>
>  
>> JIT потребует точного знания длины слова, поэтому необходимо будет
>> выделить слово в словарной статье под это.
>>    
>
> Все константы должны рассчитываться, а не зашиваться.
> Код не должен использовать порядок полей.
>  

Эту константу в общем случае рассчитать нельзя, потому что слова в
словаре не обязательно идут друг за другом.
И код не будет использовать порядок полей, ведь смещение можно именовать!

>  
>> JIT должен знать еще о примитивах - их стековую нотацию.
>>
>> В тему же - WINAPI: слово должно быть с указание количества параметров.
>> Например потому что на WinCE тупое копирование 15 параметров не пройдет,
>> там стек очищает тот кого вызвали, а не тот кто вызывает. А также чтобы
>> не сбивать оптимизатор от распределения регистров.
>>    
>
> Что там Эртль написал по поводу переносимого FFI, разбирался?
> Я ещё не успел.
>
>  
>>> сформировать список требований, которым должно отвечать микроядро и
>>> базовый транслятор форт-системы SPF5; проработать и сформировать
>>> структуры каталогов, форматы файлов, способ сборки с тем, чтобы
>>> поддерживать альтернативные сборки (под различное окружение и с
>>> различной реализацией): куда класть код, зависимый от ОС, куда
>>> зависимый от процессора, а куда от того и другого.
>>>
>>>      
>> Да, надо писать микроядра одновременно для x86 x86-64 (Win32), ARM
>> (WinCE), x86 x86-64 Linux.
>>    
>
> x86/BSD, PPC(?)
>
>  
>> Тогда получится учесть аппаратные особенности.
>>
>> Я пару месяцев назад начал набрасывать платформо-независимый CORE слов
>> ANS 94 - не зависит от размера CELL, от ОС, от формата словарной статьи,
>> двигаюсь медленно.
>>    
>
> Чего не хватает?
>  

Времени. Пока остановился на software division, которое работает, кроме
пары тест кейсов.
Да, оно необходимо для не x86 процессоров, и для быстрого
прототипирования надо иметь его в форте.


Best Regards,
Dmitry Yakimov

[Alex-334]

Добрый день всем!
-----------------

Извините что вклиниваюсь в Ваш спор. Но заставило несколько вещей. Точнее одна -- ЗАЧЕМ? Объясню на примере. Один из успешных проектов на Форте -- nncron -- использует spf3.16 Текущая версия 4.18, и ..... ? Мысль понятна?

Недавно задал вопрос на форуме, зачем каталог ./lib ? Если честно -- нет ответа.

Коллеги, реально НЕТ ответа! Андрей Черезов, Человек, благодаря которому живо наше сообщество, использует свои библиотеки. Мы их ценим? Я -- да. Но почему тогда они частные? YreK -- ( извини, хоть и рядом, но до сих пор не знаю как реально зовут :( ) сделал свою библиотеку. Тратит свое время на создание дистрибутива. Мир тебе, добрый человек!

Вопрос не в версии. Вопрос -- в ИДЕОЛОГИИ! Извините, но как не больно будет всем нам -- но ее  нет.

Идеология -- это КАК мы решаем задачи. Как быстро решить задачу. Есть ответ? Да? Да! -- мы на коне!

Коллеги, скажите, Вы готовы оплатить версию SPF5.00? В какую стоимость и что Вы собираетесь в ней увилеть? Я не требую делать дистрибутив коммерческим -- я просто прошу всех нас честно ответить СЕБЕ на этот вопрос. Это вопрос ценностей, всего лишь...
----------------

>Привет всем!
>
>Об SPF5 разработчики SPF4 грезят по крайней мере с 2004-го, а то и раньше
>(архива писем под рукой нету).
>Неспеша мы вынашиваем наши идеи и испытываем прототипы... И по всему
>становится видно, что его время приближается. Ниже  привожу, как я вижу
>следующую версию системы. Ожидаю ответных идей, возражений, дополнений
>и т.п(только не надо целиком все цитировать ;). Будет хорошо, если мы
>сформируем
>общую цель (как образ ясного результата).
>
>
>Критерии 5-ой версии
>
>   1. Явно-прослеживаемая генетика от SPF4 (иначе ≈ почему это вообще SPF
>   ;)
>   2. Развитие заложенных в SPF4 идей и реализация новых. Это неизбежно
>   влечет изменение многих механизмов ядра, поэтому старые расширения могут
>   быть не совместимы с новой системой, и значит, логично ему быть 5-ым.
>   3. Консенсус разработчиков предыдущих версий SPF о выполнении
>   перечисленных пунктов в отношении единственной системы (наследник короны
>   только один :)
>
>
>Система ценностей
>
>   - Человеческий труд ценней машинного. Исходый код, то, что делается
>   руками, ≈ это главное :)
>   - Долговременная выгода важней сиюминутной (т.к. работает закон
>   сложного процента ;). Поддержка, модификация и повторное использование кода
>   важней, чем время, затраченное на первичное написание этого кода.
>   - Гармония формы и содержания; это формально не описывается, и
>   ощущается сугубо человеком ;)  SPF ≈ это редкий продукт ручной выделки в
>   единственном экземпляре (поймите меня правильно :), поэтому лучше дольше
>   подумать (мы помним, что упрощать сложно :) и сделать проще и красивей, чем
>   быстро и абы как.
>
>
>Общая стуктура
>
>   1. Микроядро (типа spf5-mc.exe). Представляет собой простейший
>   интерпретатор стандартного входного потока (STDIN).
>   - Предоставляет необходимый и достаточный набор слов для расширения
>      системы до уровня базового транслятора.
>      - Задает такие параметры системы как размер ячейки, размер
>      символа, основной формат откладываемого кода, средства связи с
>операционной
>      системой или другим окружением, и т.п.
>      2. Базовый транслятор (типа spf5.exe). Форт-транслятор уровня
>   ANS (не обязательно совместимый), собираемый на основе микроядра (путем его
>   расширения и сохранения исполнимого образа).
>   3. Набор компонентов в исходном виде, включающий:
>      - расширения базового транслятора (для совместимости с ANS, с
>      SPF4, поддержки неких парадигм и т.п.);
>      - расширения микроядра (зависимые от окружения форт-системы);
>      - базовый набор библиотек (ANS-совместимых, возможно, с простой
>      прослойкой);
>      - сложные расширения (включающие компоненты разных уровней:
>      расширения микроядра, транслятора, независимый высокоуровневый код,
>      базируемый на прослойке совместимости).
>
>
>Микроядро
>
>Его принцип: для портирования базового транслятора достаточно портировать
>микроядро.
>
>Может быть несколько вариантов микроядра, различающихся такими деталями как
>размер символа, размер ячейки, хранить ли вершину стека в регистре, для
>каких целей использовать аппаратный стек, включен ли оптимизатор, совмещены
>ли хранилища кода и данных, и т.п. Далее, можно легко проводить
>сравнительные испытания, какой вариант быстрей или меньше. По идее,
>JIT-компилятор тоже на этом уровне может обитать ≈ например, при первом
>исполнении ранее отложенного кода (отложенного в виде косвенного шитого,
>например) он может длинно разворачивать его в машинный.
>
>Микроядро должно предоставить достаточный набор слов, чтобы реализация
>базового транслятора не зависела от окружения форт-системы, и в нем не
>должно быть никаких лишних высокоуровневых определений.
>
>Для минимизации микроядра оно наделено лишь умением интерпретировать слова.
>Нету STATE и режимов. Нету слов немедленного исполнения, в том числе и
>управляющих конструкций. Нету способа заглянуть вперед по входному потоку.
>Нету различия строк ( REFILL ). Нету подключения файлов ( INCLUDED ). Есть
>лишь сплошной поток слов на входе и способ маскировки однословных строк,
>все. :)   Это похоже на colorForth. Правда, писать код специфично для этого
>интерпретатора я нахожу неудобным. Удобным же нахожу транслировать
>нормальный код в упращенный поток слов для микроядра. Например, так:
>msxsl.exe spf5-index.xml spf5-mc.xsl | spf5-mc.exe  (в этом случае исходник,
>естественно, размечен в XML, например  в ForthML, о котором я писал на
>wiki),  или так: spf4.exe spf5-mc.trans.f spf5-index.f | spf5-mc.exe. На
>выходе получаем spf5.exe.
>
>Каждый, кто разбирался с исходниками SPF4, должен был заметить, что в ЦК
>(tc_spf.f) часто дублируется код из самого ядра, когда лучше было бы
>подключить имеющийся код. Эту ситуацию стоит разрулить.
>Исходники самого микроядра должны быть представлены в том же виде, что и
>исходники базового транслятора, с тем, чтобы их было легко преобразовать в
>поток исполняющихся слов. Тогда целевой компилятор будет предельно прост ≈
>это будет такой же интерпретатор, какой реализуется микроядром, и для сборки
>ЦК можно будет использовать исходники самого микроядра. Исходный код
>микроядра не должен быть завязан на ЦК ≈ что означает, что он целиком (за
>исключением, быть может, нескольких оберток) должен загружаться в
>форт-систему без всякого ЦК.
>
>
>Базовый транслятор
>
>В нем видиться развитие и реализация следующих идей:
>
>   - отделение хранилищ от списков слов;
>   - отделение трансляторов слов от списков слов;
>   - детальный постфиксный способ создания и именования статей
>   отложенного кода;
>   - поддержка различных моделей связывания при откладывании
>   (немедленное, позднее в указанном контекста, позднее в позднем контексте);
>   - по возможности, независимость представления исходного кода от того,
>   будет он исполнен немедленно или отложен (!);
>   - вложенное откладывание кода;
>   - улучшение рефлексии форт-системы (путем ведения дополнительных
>   списков объектов и др.);
>   - еще?
>
>Общии тенденции в поддержку следующих подходов:
>
>   - предпочтение именованным (тем или иным способом) объектам, которые
>   будут долго жить и многократно  использоваться, по сравнению с созданием и
>   удалением анонимных объектов каждый раз; такой подход дает некоторое
>   упрощение при отсутствии автоматической сборки мусора;
>   - использование на верхнем уровне крупных замыканий и позднего
>   связывания вместо параметризации функций; жесткая привязка кода к данным
>   упрощает код, но требует простой возможности динамически откладывать код
>   (генерить исполнимый код наравне с созданием объектов-данных).
>
>
>Далее...
>
>ToDo: сделать детализацию способов достижения поставленных планок;
>сформировать список требований, которым должно отвечать микроядро и базовый
>транслятор форт-системы SPF5; проработать и сформировать структуры
>каталогов, форматы файлов, способ сборки с тем, чтобы поддерживать
>альтернативные сборки (под различное окружение и с различной реализацией):
>куда класть код, зависимый от ОС, куда зависимый от процессора, а куда от
>того и другого.
>
>
>--
>Ruvim

--
--
Алексей

[Andrey Cherezov]

Добрый день, Alex!

Ваше сообщение от 11.12.2006 22:29:
> Извините что вклиниваюсь в Ваш спор. Но заставило несколько вещей. Точнее одна -- ЗАЧЕМ? Объясню на примере. Один из успешных проектов на Форте -- nncron -- использует spf3.16 Текущая версия 4.18, и ..... ? Мысль понятна?
>  
Николай вроде бы уже давно говорил, что переносит nnCron под SPF4. Я
тоже перешел в Eserv/3 с SPF3 на SPF4 несколько лет назад. Не очень сложно.
Вопрос "зачем" - интересный. Но тогда надо начинать с SPF3.16. Неужели
nnCron использует 3.16, а не хотя бы 3.7 ? Ведь на 3.16 очень сложно
писать такие серверные многопоточные штуки, какими являются и Eserv, и
nnCron. Последние версии 3.х в подходе к многопоточности (сопроцессам в
традиционной советской терминологии) продолжал идеологическое следование
заделам советских фортов - тех гигантов, на чьих плечах продолжаем
стоять. Но, конечно, с учетом современных реалий - раундробинов нам
клонировать уже не приходится :) Это радикально упростило реализацию
новой версии Eserv, в частности. Хотя и оказалось несовместимо с
Eserv/2.x...

Зачем SPF4 - я уже когда-то объяснял. Клонирование SPF3 в
не[полностью]совместимые форты в конце 90х стало бедой, которая
распыляла силы фортеров. Было бы глупо игнорировать этот процесс и не
попытаться объединить усилия (код :) для создания всех устраивающей
общей версии SPF. Дима сказал, что это результат тогдашней лицензии SPF.
Поэтому перелицензировались в GPL, и Дима взял на себя труд по
объединению ветвей SPF. Честь ему и хвала. И всем, кто включился. (Между
прочим мы недавно вернулись в первую тысячу самых активных проектов на
sf.net ! :)

Тем не менее я все эти годы был "слегка в оппозиции" к SPF4 - к тому,
как втрое раздулось его ядро (от 37кб последней 3.x) за счет включения
фич, ненужных в большинстве проектов (плавающей точки, например). Это не
"снобизм", а сожаление об утрате простоты. Зачем нужна простота?
Во-первых, это первая и главная фича форта :) Во-вторых, простота ядра
позволяет полностью контролировать (и доверять) каждому байту кода -
если что не используешь или не понимаешь, то всегда можешь эту фичу
отключить (не флагом, а полностью - "не носить с собой"). В таких
mission critical приложениях как Eserv это крайне важно. Тем более, что
компоненты разных авторов в принципе имеют право не быть совместимыми
друг с другом, в форте ведь можно менять/расширять даже очень "интимные"
части. В-третьих, минимизация очень упрощает портирование. dsForth это
доказал. В-четвертых, простота - это красота. (Простота - это даже
главный "критерий" красоты. Не только в программировании, но и в прочих
искусствах, в технике и в природе.) Поэтому отвязаться от идеи
построения более изящного ядра все эти годы не удавалось. И вот, похоже,
это стало общепринятой точкой зрения на будущее SPF. Вот вам и ответ про
SPF5. В какой-то степени это может быть очередным объединением ветвей
SPF. В SPF5 можно взять что-то от dsForth, что-то от LinuxSPF, что-то от
BootOS и т.д. Т.к. далеко отросшие ветки рискуют либо обломиться под
собственной тяжестью (стать совсем несовместимыми другими фортами), либо
отсохнуть от недостатка питания (поддержки разработчиков), либо врасти в
соседние деревья (миграция разработчиков на другие инструменты :).
> Недавно задал вопрос на форуме, зачем каталог ./lib ? Если честно -- нет ответа.
>
> Коллеги, реально НЕТ ответа! Андрей Черезов, Человек, благодаря которому живо наше сообщество, использует свои библиотеки. Мы их ценим? Я -- да. Но почему тогда они частные? YreK -- ( извини, хоть и рядом, но до сих пор не знаю как реально зовут :( ) сделал свою библиотеку. Тратит свое время на создание дистрибутива. Мир тебе, добрый человек!
>  
Спасибо за лестные слова, но я не так уж много делаю сейчас для SPF,
увы. Идея размежевания пользовательских библиотек по каталогам - моя.
Это и разделение сфер ответственности, и возможность программирования в
своём стиле, и исключение конфликтов библиотек, и т.д. Это очень много
раз обсуждалось. Не хотелось бы еще раз останавливаться на этом
подробно. Скажу лишь, что периодически какие-то либы отдельных авторов
(в т.ч. и некоторые мои) становятся настолько общепринятыми, что в целях
стабилизации её интерфейсов её делают "общей" и могут переносить из
авторских каталогов выше (а автор может продолжить несовместимые
эксперименты в своем каталоге, если хочет, не мешая использованию общей
либы :). Я думаю, что этот подход уже доказал свою эффективность и
удобство. Можно и между авторами библиотеки переносить - тогда не
страшна и несовместимость новых версий, и понятно, кто за новую версию
отвечает (примеры таких кросс-библиотек есть - например и Дима, и
Николай развивали некоторые мои либы в своих каталогах/проектах).
> Вопрос не в версии. Вопрос -- в ИДЕОЛОГИИ! Извините, но как не больно будет всем нам -- но ее  нет.
> Идеология -- это КАК мы решаем задачи. Как быстро решить задачу. Есть ответ? Да? Да! -- мы на коне!
>  
КАК - это не столько идеология, сколько технология. А идеология у нас
есть, давно сформулированная (в т.ч. мною в моей статье "Идеи форта"
10-летней давности, "Слово о Форте" 7-летней давности и др.), и почти
никем не оспариваемая, т.к. вцелом она совпадает с понятной идеологией
всех фортов. Если у вас есть альтернативные предложения или иная
трактовка понятия идеологии - с удовольствием выслушаем! Кстати, Alex,
вы Игрека (http://www.forth.org.ru/~ygrek/) обвиняете в анонимности, а
сами подписываетесь еще более анонимно без расшифровки ;)
> Коллеги, скажите, Вы готовы оплатить версию SPF5.00? В какую стоимость и что Вы собираетесь в ней увилеть? Я не требую делать дистрибутив коммерческим -- я просто прошу всех нас честно ответить СЕБЕ на этот вопрос. Это вопрос ценностей, всего лишь...
>  
Да, мы много лет оплачиваем разработку SPF своим временем - частью своей
жизни - что может быть дороже? :)
Насущные задачи, которые может решить SPF5, и которые трудно решаемы в
рамках текущего ядра, уже описывались.
Насколько эти задачи важны, т.е., действительно, какую часть наших
трудозатрат имеет смысл пустить на новое ядро - это вопрос
неоднозначный. В SPF не принято реализовать функции с пустой целью
"чтобы было". Поэтому SPF находится там, где находится: многое из давно
задуманного не кажется настолько привлекательным, чтобы сходу бросаться
в революцию больших перемен, идеи пылятся в подсознании и в "манифестах"
годами - некоторые так и умирают, а некоторые вдруг, бац, и воплощаются
:) Когда появляется подходящая практическая задача, обосновывающая
необходимость (и "окупающая" реализацию) нового функционала. И особенно,
когда появляется свежий мощный мотор, готовый взять на себя инициативу и
ответственность. Благо, на Руси таланты не переводятся :) Пользуясь
случаем, выражаю восхищение коллегам по SPF!
--
Андрей Черезов

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Aleksej Saushev!

Ваше сообщение от 10.12.2006 19:00:

различное окружение и с различной реализацией): куда класть код, зависимый от
ОС, куда зависимый от процессора, а куда от того и другого.
    

Надо бы предусмотреть сборку под какой-нибудь FICL или pForth.
  

Да, я тоже много раз предлагал делать новое ядро с учетом возможности выращивания SPF внутри другого форта.
Как когда-то первые SPF3 использовали для самораскрутки (или саморождения) Win32forth, т.к. мне просто нечем было больше скомпилировать SPF под виндой так, чтобы в конце уже SPF сам себя записывал в exe. В общем, опция внутриутробного развития :)

[Andrey Cherezov]

Добрый день, Dmitry Yakimov!

Ваше сообщение от 09.12.2006 21:18:
> Хочу добавить что в SPF5 должно быть ассемблера по минимуму. Основную
> задачу по оптимизации надо предоставить машине.
>  
Более того, в идеале должна быть возможность _компиляции в текст другого
языка_ -
не только в ассемблер, но и в Си (для юниксов и прочими сишными осями,
под которыми
может не быть средства запуска самокомпиляции SPF) или в .NET IL, или в
JavaScript! ;)

Это несколько иной подход, чем JIT (компиляция в платформенно
независимый бинарник,
который транслируется-исполняется платформенно-зависимой VM). На мой
взгляд, более
универсальный. Т.к. JIT (если он нужен) тоже надо чем-то компилировать
ДЛЯ целевой
платформы, и хотелось бы именно Фортом ;) Причем с возможностью его
компиляции
непосредственно НА целевой платформе инструментарием целевой платформы,
т.к. еще
есть такие платформы, на которые заказан путь любым бинарникам, а текст
передать
всегда можно.

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

[Dmitry Yakimov-2]

Привет,

Andrey Cherezov wrote:

> Добрый день, Dmitry Yakimov!
>
> Ваше сообщение от 09.12.2006 21:18:
>  
>> Хочу добавить что в SPF5 должно быть ассемблера по минимуму. Основную
>> задачу по оптимизации надо предоставить машине.
>>  
>>    
> Более того, в идеале должна быть возможность _компиляции в текст другого
> языка_ -
> не только в ассемблер, но и в Си (для юниксов и прочими сишными осями,
> под которыми
> может не быть средства запуска самокомпиляции SPF) или в .NET IL, или в
> JavaScript! ;)
>
> Это несколько иной подход, чем JIT (компиляция в платформенно
> независимый бинарник,
> который транслируется-исполняется платформенно-зависимой VM). На мой
> взгляд, более
> универсальный. Т.к. JIT (если он нужен) тоже надо чем-то компилировать
> ДЛЯ целевой
> платформы, и хотелось бы именно Фортом ;)

Тут все просто - JIT тоже будет написан на этом платформенно-независимом
форте, будет находится в том же исполнимом модуле что и форт, только в
другом словаре, и сам себя заоптимизирует :)

Естественно JIT будет сделан с учетом текущей платформы, процессора
например.

Между прочим JIT сможет делать и Ahead of time compilation - создание
exe или dll (аналог ngen от .NET), чтобы не оптимизировать в runtime -
это позволит использовать навороченные медленные методы оптимизации.

И может вместо exe или dll вполне так себе сделать Си исходный код (или
вкупе с ними) или ASM.

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

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

Кстати оптимизатор можно на первом этапе и не портировать.VM форта в
микроядре будет по умолчанию.

Best Regards,
Dmitry Yakimov

[yGREK Heretix]

Greetings,

> Коллеги, реально НЕТ ответа! Андрей Черезов, Человек, благодаря
> которому живо наше сообщество, использует свои библиотеки. Мы их
> ценим? Я -- да. Но почему тогда они частные? YreK -- ( извини, хоть
> и рядом, но до сих пор не знаю как реально зовут :( ) сделал свою
> библиотеку. Тратит свое время на создание дистрибутива. Мир тебе, добрый человек!

Тут наверное имеется ввиду какая-то конкретная либа. Если это odbc.f -
то я уже ведь исправился и вместо копии либы от ~yz оставил у себя
только расширение оной либы. И потом - что значит "частные"? Либы в
devel всеобщие! :) Может их и сложнее найти, но ведь we are working
on it - есть devel.html. А собрать все либы в одном месте - как уже
говорилось - много работы. Стандартизовать слова, расположение,
отследить наличие совместных глюков, доку итд итп. Кто будет этим
заниматься? Периодически всплывают идеи о общем форт (или SPF)
репозитарии кода - на манер CPAN - ИМХО было бы хорошо - если кто-то
начнёт делать, тогда и будет о чём говорить.

> Вопрос не в версии. Вопрос -- в ИДЕОЛОГИИ! Извините, но как не
> больно будет всем нам -- но ее  нет.

Насчёт версии - тут идеология такая - у меня ;) - раз в какой-то
период времени выпускать дистра новую версию - например раз в полгода
- просто для отчётности.

AC> Кстати, Alex,
AC> вы Игрека (http://www.forth.org.ru/~ygrek/) обвиняете в анонимности, а
AC> сами подписываетесь еще более анонимно без расшифровки ;)

Ну думаю никто меня в анонимности не обвинял. В любом случае такие
обвинения не принимаются ;)

---------
With best regards,
 ygrek   http://ygrek.org.ua

[Ruvim Pinka]

Привет!

On 12/9/06, Ruvim Pinka <[hidden email]> wrote:
> проработать и сформировать структуры каталогов

http://www.forth.org.ru/~ruvim/SPFx/SPF5-src-hierarchy.html

Стуктура каталогов, как вариант.

--
Ruvim

[Ruvim Pinka]

Привет!

On 12/9/06, Dmitry Yakimov <[hidden email]> wrote:

> Форматом словарной статьи для основного ядра предлагаю сделать прямой
> шитый код. К нему позже будет легко подключить JIT.

Если примитивы SPF4 оставить примитивами, то в микроядре будет очень
мало высокоуровневых слов, поэтому формат словарной статьи для него не
принципиален: для примитивов ведь JIT без пользы?

> Более того, можно будет реализовать ahead time compilation - собирание
> чистого exe (или dll) из приямого шитого кода с помощю JIT.

По идее да, т.к. там известно, какие примитивы были использованны, а
какие не были. Непонятно только, как этот движок поймет ситуацию,
когда xt скомпилированно как число...
Если использовать ForthML, то транслятор во многих случаях может
прозрачно добавлять необходимую инфу, т.к. имеет полноценную разметку.
Например, для xt  <xt>SomeWord</xt>.


> JIT должен знать еще о примитивах - их стековую нотацию.
>
> В тему же - WINAPI: слово должно быть с указание количества параметров.

Я бы даже сказал, в общем случае — количество входных параметров и
количество выходных. Например, нужно, если это будут слова другой
форт-системы из DLL  ;)
(Си в этом плане более ограничен, у него функция может вернуть только
один параметр ;)


> Данные предлагаю отделить от кода. Тогда SPF можно будет зашивать в ROM
> (в оптимизированном или нет виде).

> Да да, пространство имен. Предлагаю как в DSF - хранить в текстовом
> файле (с возможность брать этот текстовый файл из памяти, для ROM).

Под хранилищем я понимаю непрерывную область памяти, доступную через
слова HERE, ALLOT, "C,", ",".   Михаил его еще называет кодофайлом.

Для хранения кода и значений переменных (данных) можно использовать
два раздельных хранилища. А имена слов и их связи в списки в
приведеном случае идут в  отдельное третье, так ?

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

--
Ruvim

[Dmitry Yakimov-2]

Привет,

Ruvim Pinka wrote:

> Привет!
>
> On 12/9/06, Dmitry Yakimov <[hidden email]> wrote:
>
>  
>> Форматом словарной статьи для основного ядра предлагаю сделать прямой
>> шитый код. К нему позже будет легко подключить JIT.
>>    
>
> Если примитивы SPF4 оставить примитивами, то в микроядре будет очень
> мало высокоуровневых слов, поэтому формат словарной статьи для него не
> принципиален: для примитивов ведь JIT без пользы?
>  

Для подпрограммного шитого JIT не написать, максимум макроподстановщик и
потом щелевой оптимизатор. Я же предлагаю нормальный JIT - с
субоптимальным распределением регистров. Кстати написание такого JIT
вполне может быть кому-то темой диссертации (кандидатской если будут
использованы навороченые методы типа ПЦОС, или магистерской,
бакалаврской если просто распределение регистров известным методом).

И примитивы SPF5 будут совсем другими нежели в SPF4, и просто будет
меньше гораздо, всего 10-15.

Опять же прямой шитый код оставляет возможность писать на асме, и будет
полная совместимость с SPF4 по регистровой модели, поэтому асм
определения от SPF4 подойдут без перекомпиляции.

В общем одни преимущества от прямого шитого. Визуальная отладка опять же
в рантайме резко упрощается.
>  
>> Более того, можно будет реализовать ahead time compilation - собирание
>> чистого exe (или dll) из приямого шитого кода с помощю JIT.
>>    
>
> По идее да, т.к. там известно, какие примитивы были использованны, а
> какие не были. Непонятно только, как этот движок поймет ситуацию,
> когда xt скомпилированно как число...
>  

Как это непонятно :) Все XT адреса будут относительными. Относительно
base, вот ее и будем перемещать каждый раз при загрузке forth dll.

> Если использовать ForthML, то транслятор во многих случаях может
> прозрачно добавлять необходимую инфу, т.к. имеет полноценную разметку.
> Например, для xt  <xt>SomeWord</xt>.
>  
Писать на FortML это ломать пальцы и руки :)

>
>  
>> JIT должен знать еще о примитивах - их стековую нотацию.
>>
>> В тему же - WINAPI: слово должно быть с указание количества параметров.
>>    
>
> Я бы даже сказал, в общем случае — количество входных параметров и
> количество выходных. Например, нужно, если это будут слова другой
> форт-системы из DLL  ;)
> (Си в этом плане более ограничен, у него функция может вернуть только
> один параметр ;)
>  

Да, согласен.

>
>  
>> Данные предлагаю отделить от кода. Тогда SPF можно будет зашивать в ROM
>> (в оптимизированном или нет виде).
>>    
>
>  
>> Да да, пространство имен. Предлагаю как в DSF - хранить в текстовом
>> файле (с возможность брать этот текстовый файл из памяти, для ROM).
>>    
>
> Под хранилищем я понимаю непрерывную область памяти, доступную через
> слова HERE, ALLOT, "C,", ",".   Михаил его еще называет кодофайлом.
>
> Для хранения кода и значений переменных (данных) можно использовать
> два раздельных хранилища. А имена слов и их связи в списки в
> приведеном случае идут в  отдельное третье, так ?
> Непонятно, как тут воплощается идея временных хранилищ (под каждый тип
> заводить отдельно и независимо, или оно одно виртуальное будет
> агрегировать все три типа и создавать их само единовременно).
>  

Ну да, одно виртуальное будет все аггрегировать.
Здесь будет уровень абстракции выше чем в SPF4, можно эти пространства
делать хоть на web, хоть в БД.

Best Regards,
Dmitry Yakimov