LINUX.ORG.RU

Новый релиз SP-Forth


0

0

На днях вышла новая версия компилятора языка Forth -- SP-Forth. Примечателен тем, что полностью разработан нашими ребятами. На нем реализовано несколько коммерческих проектов -- e-serv, nnCron. Что говорит о зрелости и стабильности интерпретатора.

>>> Подробности

anonymous

Проверено: Shaman007 ()

Интересно... Когда-то я с Фортом сталкивался. Дааавноооо это было... Скачал. Буду вспоминать, что там и как.

Sergey_T ★★★★★
()

а может кто-нибудь развеет темноту вокруг меня?

для чего предназначен Forth?
hello word на нем?

anonymous
()

Блин каких только языков нет ужос вычислительной техники всего то лет 50 а что только не напридумывали, единственно жалко что все это не мы сделали а всякого рода "китайцы"

anonymous
()
Ответ на: комментарий от RSM

дааа, очень похоже что магистр Йода был на форте программистом просто.

vahvarh ★★★
()
Ответ на: комментарий от Davidov

Я когда-то давно смотрел на SP-Forth, который был как раз в nnCron. Довольно забавная штука (они расширили язык дополнительными вызовами). А главная фишка форта как такового (ну, насколько я понимаю) --- это обратная польская нотация (все операции совершаются с данными положенными на стек). То есть чтоб записать (17+18)*19-33 надо записать что-то вроде:

17 18 + 19 * 33 -

(отсюда и вытекает: "йоды магистра речи тайна раскрыта, оказывается, на форте программист старый есть он просто")

Такой подход сильно упрощает интерпретатор (и компилятор), поэтому он довольно низкого уровня считался.

(Всё выше ИМХО)

Davidov ★★★★
()
Ответ на: комментарий от Davidov

>отсюда и вытекает: "йоды магистра речи тайна раскрыта, оказывается, на форте программист старый есть он просто")

ЛОЛ!

Sergey_T ★★★★★
()
Ответ на: комментарий от Davidov

RE: главная фишка форта как такового

> А главная фишка форта как такового (ну, насколько я понимаю) это обратная польская нотация

нифига ты не понимаешь, остаётся констатировать...

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Sergey_T

> Вообще-то Форт - интерпретируемый язык

просто новость как то криво написана - начато про компилятор а заканчивается про интепретатор.

Tester ★★★
()

>Что говорит о зрелости и стабильности интерпретатора.

Всё-таки _транслятора_ :) На ряде тестов программы на SP-Forth получаются более быстрыми, чем у VC7, не говоря уже о GCC :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>hello word на нем?

." Hello world"

или

S" Hello world" .

или ещё десятком способов.

KRoN73 ★★★★★
()
Ответ на: комментарий от Sergey_T

>Вообще-то Форт - интерпретируемый язык

В режиме интерпретации - интерпретируемый. В режиме компилляции - компиллируемый. При исполнении часто ещё и виртуальная машина сама в себе :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Да. И при этом крохотного размера. Помнится, я трогал форт еще в RT-11. Это был Fig-Forth, кажись.

Alphaer ★★
()
Ответ на: комментарий от KRoN73

>На ряде тестов программы на SP-Forth получаются более быстрыми, чем у VC7, не говоря уже о GCC :)

А где можно увидеть тесты и результаты?

anonymous
()
Ответ на: комментарий от anonymous

>На ряде тестов программы на SP-Forth получаются более быстрыми, чем у VC7, не говоря уже о GCC :)

>А где можно увидеть тесты и результаты?

Это наверное таже байка что существуют java программы быстрее своих сишных аналогов

anonymous
()
Ответ на: комментарий от anonymous

Если не ошибаюсь, когда его создавали он использовался для управления телескопом в какой-то обсерватории. Говорят программы по эффективности машинного кода могут сравниться с ассемблером и в то же время нет такой привязки к железу.

kenneth ★★★
()
Ответ на: комментарий от anonymous

>>На ряде тестов программы на SP-Forth получаются более быстрыми, чем
>>у VC7, не говоря уже о GCC :) 

>А где можно увидеть тесты и результаты?

Ну, вот пример. Сорри, SP-Forth только под Win настроен, так что результаты только с неё.

Ну, например, тупо: рекурсивное 40-е число фибоначчи. Заново
пересчитывать влом, так что результаты прошлогоднего теста под виндой:

SP-Forth 4 Build 8 - 3.7сек
O'Caml 3.07 - 4.3
C++ (VC7) - 4.5
C# - 5.2
Java2 1.4 - 5.4
F# - 0.6.4 - 5.5сек

код Си++:
#include <stdio.h>

int __fastcall fib(int n)
{
    return n<2 ? 1 : fib(n-1)+fib(n-2);
}

void main(void)
{
    int f42=fib(40);
    printf("%d",f42);
}

компилляция с cl /Ox /O2 /Fa /FAsc /G6 /Gr

SP-Forth:

: FIB ( N1 -- N2 )
    DUP 2 < IF DROP 1 EXIT THEN
    DUP
    1- RECURSE
    SWAP
    2- RECURSE
    +
;

: MAIN 40 FIB . BYE ;

' MAIN TO <MAIN>  S" fib.exe" SAVE  BYE

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>А особенно хотелось бы взнлянуть, как выглядит код перемножения матриц на форте :)

всё зависит от степени абстракции. Не забывай, что Форт - метаязык.

KRoN73 ★★★★★
()
Ответ на: комментарий от kenneth

>Говорят программы по эффективности машинного кода могут сравниться с ассемблером и в то же время нет такой привязки к железу.

По компактности связки код+виртуальная машина Форт может капитально обставить чистый ассемблер. Я помню ещё реализаци Форт-ядра в 512байт.

По реальной эффективности - всё сильно зависит от архитектуры процессора, от опыта программиста.

Хотя, безусловно, если пересчитывать по критерию надёжность*скорость_программы/время_разработки то Форт может оказаться в очень большом отрыве от многих языков. Но - асбтрактно. На практике Форт губит ... его гибкость. Ну, вот, пример.

Полноценный ООП-механизм на Форте пишется в несколько килобайт исходников и реализуется и отлаживается с нуля за несколько дней. (Сколько вам потребуется времени, чтобы ввести полноценные объекты в Си? Сборку мусора в ассемблер? Интерпретируемые скрипты в O'Caml?). Поэтому, как это ни парадоксально, у каждого разработчика... своя личная ООП-библиотека (там, где она нужна).

ANS-комитет вводить новые стандарты не спешит, потому что они будут дополнительными ограничениями. А гибкость и расширяемость - это один из главных китов, на которых сидит Форт...

...

А по практическому использованию - Форт сегодня живёт во встраиваемых системах, в управлении автономным железом (пресловутые спутники), в экспертных системах. В наследниках - Java, например, внутри использует стековую машину характерную для Форта, многие "Java-процессоры" разрабатывались изначально как Форт-процессоры; Postscript - это вообще практически оригинальный, хотя и сильно кастрированный Форт. Ну и в загрузчике FreeBSD :D

KRoN73 ★★★★★
()
Ответ на: комментарий от sin_a

>matrix1 matrix2 * 
>? :)

Это только если Форт до объектного опущен :)
Так же, скорее, matrix1 matrix2 matrix* :)

Вообще же, например, на моём JBForth это может выглядеть так:
{
  { 1 0 0 }
  { 1 0 0 }
  { 1 1 1 }
} matrix value m1

{
  { 1 1 1 }
  { 0 0 1 }
  { 1 1 1 }
} matrix value m2

m1 m2 matrix*

:)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Ну, например, тупо: рекурсивное 40-е число фибоначчи. Заново пересчитывать влом, так что результаты прошлогоднего теста под виндой:

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

anonymous
()
Ответ на: комментарий от anonymous

>Т.е. измерялась скорость работы данной программы, включая загрузку?

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

В принципе, я и 43-е (кажется) число считал со временем расчёта в десятки секунд, пропорции примерно те же.

Если интересно, вот цифры по трёхпараметрической функции Аккермана (там, в отличии от Фибоначчи, от рекурсии в полной мере избавиться невозможно):

+ X+1, если N=0 | X, если N=1, Y=0, | 0, если N=2, Y=0, A(N,X,Y)= | 1, если N=3, Y=0, | 2, если N=>4, Y=0, + A(N-1,A(N,X,Y-1),X), если N#0, Y#0;

где N,X,Y - целые неотрицательные числа.

Считал для (3,8,9): O'Caml - 19сек. SPF4 - 21сек. VC7 - 24сек. asm - 26сек. C# - 27сек.

asm - лобовое решение для x86, без поточной оптимизации. В C# пришлось патчить exe-шник, на предмет объёма стека, а то катастрофически не хватает (там объем стека до сотен мегабайт нужен).

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Пардон, форматирование...

>Т.е. измерялась скорость работы данной программы, включая загрузку?

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

В принципе, я и 43-е (кажется) число считал со временем расчёта в
десятки секунд, пропорции примерно те же.

Если интересно, вот цифры по трёхпараметрической функции Аккермана (там, в отличии от Фибоначчи, от рекурсии в полной мере избавиться невозможно):

              + X+1,                 если N=0
              | X,                   если N=1,  Y=0,
              | 0,                   если N=2,  Y=0,
    A(N,X,Y)= | 1,                   если N=3,  Y=0,
              | 2,                   если N=>4, Y=0,
              + A(N-1,A(N,X,Y-1),X), если N#0,  Y#0;

     где N,X,Y - целые неотрицательные числа.

Считал для (3,8,9):
O'Caml - 19сек.
SPF4 - 21сек.
VC7 - 24сек.
asm - 26сек.
C# - 27сек.

asm - лобовое решение для x86, без поточной оптимизации. В C# пришлось патчить exe-шник, на предмет объёма стека, а то катастрофически не хватает (там объем стека до сотен мегабайт нужен).

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Кстати, решение аккермана на O'Caml очень красиво, прямо в лоб :)

let rec a n x y =
   match (n, y) with
      (0, y) -> x+1
    | (1, 0) -> x
    | (2, 0) -> 0
    | (3, 0) -> 1
    | (n, 0) -> 2
    | (n, y) -> (a (n-1) (a n x (y-1)) x)
;;

print_int(a 3 8 9);
print_newline();;

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> для чего предназначен Forth?

Для программирования свежеспроектированного 8-битного микроконтроллера, для которого ещё нет (и возможно никогда не будет) никаких других средств разработки, даже ассемблера.

anonymous
()
Ответ на: комментарий от anonymous

> все это не мы сделали

Рефал

anonymous
()
Ответ на: комментарий от Sergey_T

> Вообще-то Форт - интерпретируемый язык

Чушь вещаете-с.

anonymous
()
Ответ на: комментарий от KRoN73

> Интерпретируемые скрипты в O'Caml?

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

anonymous
()
Ответ на: комментарий от anonymous

>Для программирования свежеспроектированного 8-битного микроконтроллера, для которого ещё нет (и возможно никогда не будет) никаких других средств разработки, даже ассемблера.

Это - да. Транслятор Форта под любую систему пишется за считанные дни :) Помню, Форт-ассемблер под 32-х битный i386 я в своё время за две ночи написал. С отладкой. С возможностью линкинга на лету (в рантайме) .obj-файлов от других 32-х битных сред. Интересно, сколько это всё (особенно с отладкой и в условиях нехватки документации) будет писаться на Си++? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>> Интерпретируемые скрипты в O'Caml?

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

М... В функциональных языках я, конечно, ламер, но неужели на O'Caml так легко тащить с собой готовый транслятор из исходников в исполняемый код? Почему же тогда пакеты с O'Caml столько весят? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Код на Си вычисляющий число фибоначи намерено сделан хуже чем код на форте. Сравните код на форте с вот такой рекурсивной программой на Си:

int fib2(int n, int f1, int f2) { if ( n == 2 ) return f1 + f2; else return fib2(n-1, f1+f2, f1); }

int main() { return fib2(40, 1, 1); }

У такой программы компилятор сможет заменить рекурсию циклом точно так же как это делает транслятор форта.

anonymous
()
Ответ на: комментарий от KRoN73

Ты не понял. Не надо в исполняемый код (а если надо - то юзай Common Lisp, в нём компилятор - неотрываемая часть runtime). Надо в замыкания.

Если хочешь пример - могу показать. Всё тривиально.

anonymous
()
Ответ на: комментарий от Davidov

>>>>>>Такой подход сильно упрощает интерпретатор (и компилятор), поэтому он довольно низкого уровня считался.

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

anonymous
()
Ответ на: комментарий от anonymous

>>>> Это наверное таже байка что существуют java программы быстрее своих сишных аналогов

только это не байка, а реальность. скорость фортпрограм сравнима с макроасемблером.

anonymous
()
Ответ на: комментарий от anonymous

>только это не байка, а реальность. скорость фортпрограм сравнима с макроасемблером.

Странно только, что на таком прекрасном языке почти никто не пишет. Короче, академически оно интересно, а вот на деле - никому нафиг не надо.

anonymous
()
Ответ на: комментарий от anonymous

>только это не байка, а реальность. скорость фортпрограм сравнима с макроасемблером.

Сколько времени займет написать на этом чудоязыке B+Tree для произвольного типа данных, у элементов которого определены операции LESS и EQUAL, и какова будет стоимость поддержки такого кода?

Также интересует вопрос линковки полученной библиотеки к существующим проектам на C / C++ / Python или Java (на выбор).

anonymous
()
Ответ на: комментарий от anonymous

Как же надоели любители забивать гвозди микроскопом!

Каждой задаче - свой язык!

anonymous
()
Ответ на: комментарий от anonymous

> У такой программы компилятор сможет заменить рекурсию циклом точно так же как это делает транслятор форта.

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

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

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

=> всё, что происходит в системе, есть ответственность программиста.

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

Далее, отсутствие средств контроля передачи параметров и вообще, поисходящего на стеке, делает крайне сложной задачу отладки сколь-либо больших проектов. Средства создания пространтств имён -- зачаточны (vocabulary + переключение контекста по месту). Не стоит забывать, что язык создавался, как замена ассемблеру в задачах автоматизации эксперимента, в условиях микромашин с катастрофически малыми ресурсами. Концепция расширяемости изящна, но чтобы язык можно было бы широко использовать в современных условиях и в общем случае, а н только для частных задач, необходимо очень основательно переработать концепцию форт-транслятора, как компактного интерпретатора текста в шитый код, без средств жёсткого контроля и оптимизации.

Интересующимся стоит прочитать классическое описание идеологии форт систем (знаменитая Лениниградская реализация, позволившая сделать полноценную среду програмирования в памяти дисплейных терминалов ЕС, начало 80-ых): Баранов С.Н., Ноздрунов Н.Р., Язык ФОРТ и его реализации, Ленинград, Машиностроение, 1988. В своё время, не поленился отсканировать, могу выложить.

anonymous
()
Ответ на: комментарий от anonymous

forth.org.ru - там много литературы. хотя Баранова первого читать не стоит, сложновато. проще Спайса+Келли.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.