Forth
http://fforum.winglion.ru/

Реальные преимущества языков
http://fforum.winglion.ru/viewtopic.php?f=4&t=29		 Страница 2 из 5
Автор:  WingLion [ Чт июн 01, 2006 16:17 ]
Заголовок сообщения: 
КатастрофаС писал(а):
Программист пусть отдыхает, пока Форт саморасширяется и саморекламируется


Саморасширяющийся язык - вовсе не означает, что он расширяется сам по себе. Это означает, что его программист может расширить!

Про рекламу - просто смешно. У нас тут не 1-й канал ОРТ... :))
КатастрофаС писал(а):
большинство программистов не тянут на Форт. Им подавай готовенькое, или они даже не задумывались о идеологии взаимодействия человека и компьютера.


Ну, называть таких людей программистами - роскошь.
Это описание типичного ЮЗЕРА, а не программиста.
Автор:  Hishnik [ Чт июн 01, 2006 22:03 ]
Заголовок сообщения: 
КатастрофаС писал(а):
Другие пишут: «слова транслируются в call, числа - в push, структуры управления в jmp». Они уже низвели форт-идеологию до ассемблера. Привязали к архитектуре компутера. Герои.


Вот это новости! И к архитектуре какого компьютера оказался привязан Форт? :)
Автор:  Balancer [ Пт июн 02, 2006 00:47 ]
Заголовок сообщения: 
КатастрофаС писал(а):
Они уже низвели форт-идеологию до ассемблера. Привязали к архитектуре компутера. Герои.


Я, вот, сперва возгорелся пообщаться с фортерами... Но среди тех, с кем общался, ни одного фортера пока не увидел :)
Автор:  Balancer [ Пт июн 02, 2006 00:48 ]
Заголовок сообщения: 
Хищник писал(а):
КатастрофаС писал(а):
Другие пишут: «слова транслируются в call, числа - в push, структуры управления в jmp». Они уже низвели форт-идеологию до ассемблера. Привязали к архитектуре компутера. Герои.


Вот это новости! И к архитектуре какого компьютера оказался привязан Форт? :)


Ну, например, к архитектурам компьютеров, в ассемблере которых есть call, push и jump...
Автор:  Геннадий [ Пт июн 02, 2006 11:12 ]
Заголовок сообщения: 
Как это ни "странно", но любой компилятор привязан тем или иным способом к железу. И как раз реализация этой привязки во многом определяет качество компилятора (быстродействие, размер кода). Компилирумый код должен же где-то работать (не только в уме программиста!)
Как фортер со стажем - программирую порядка 15 лет и практически только на Форте, могу точно сказать что, нюансы конкретной реализации всегда присутствуют в проекте, как ни стараешься от них избавиться.

Теперь по теме.

Главное преимущество на мой взгляд это возможность вмешательство в процесс компиляции, как один из вариантов расширяемости языка. Пример - импорт констант , структур, функций из .Header файлов предназначеных для программ языка С.
Помниться как только я перешел на программирование под Win32 на компиляторе WF32 первой проблемой стал перенос всяких #Define, Struct, WinAPI из .h файлов. Пока проекты были небольшие можно было сделать вручную. Но со временем пришлось преодолеть свою лень и написать процедуру компиляции в стиле С. А делов то было, временно переопределить слово WORD чтобы оно выделяло зарезервированные символы применяемые в С, и во вновь созданом словаре написать процедуры исполнения этих символов-слов и всё!
При этом не надо писать каких либо программ для промежуточных перекомпиляций, теперь С выражения стали родными для Форта.
Теперь назовите мне в каком из языков это возможно?
Автор:  Mihail [ Пт июн 02, 2006 13:12 ]
Заголовок сообщения: 
КатастрофаС писал(а):
Люди, вы тут, никак, решили Форт порекламировать?!


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

Цитата:
А ведь Гость писал: <Основу языка составляет механизм саморасширения в нужную проблемную область>. Программист пусть отдыхает, пока Форт саморасширяется и саморекламируется :)


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

Цитата:
Другие пишут: <слова транслируются в call, числа - в push, структуры управления в jmp>. Они уже низвели форт-идеологию до ассемблера. Привязали к архитектуре компутера. Герои.


Особо не понимаю почему, но ассемблер остается довольно широко применим.
По моему, шире Форта. По этому, представление Форта в качестве супер-ассемблера
может быть вполне приемлемо.

Цитата:
По теме: смысл Форта в том, что решения по пунктам 1 и 2 фортер принимает сам. Сам вводит ограничения (где ему удобно), сам определяет степени свободы (сознательно рискуя при этом забыть, где чего лежит). Но рядовой человек конституциев не пишет. Потому большинство программистов не тянут на Форт. Им подавай готовенькое, или они даже не задумывались о идеологии взаимодействия человека и компьютера.


Для большинства программистов ограничения могут быть уже подготовлены
в виде специализированных библиотек расширяющих форт-систему.
Автор:  Hishnik [ Пт июн 02, 2006 14:24 ]
Заголовок сообщения: 
Balancer писал(а):
Ну, например, к архитектурам компьютеров, в ассемблере которых есть call, push и jump...

Я не могу представить процессора, который не умеет выполнять переходы, вызовы подпрограмм, и класть числа на стек данных, но при этом выполняет стековый код. push может быть и макросом, jmp может иметь мнемонику jp или bra, но суть дела от этого не меняется. Чтобы конечный автомат был программируемым, он должен иметь возможность перемещения указателя.
Автор:  Hishnik [ Пт июн 02, 2006 16:07 ]
Заголовок сообщения: 
Balancer писал(а):
Я, вот, сперва возгорелся пообщаться с фортерами... Но среди тех, с кем общался, ни одного фортера пока не увидел Smile


Да где тут фортеры-то? Одни полосатые хищнические физиономии :)))
Автор:  Гость [ Пт июн 02, 2006 17:08 ]
Заголовок сообщения: 
Геннадий писал(а):
Главное преимущество на мой взгляд это возможность вмешательство в процесс компиляции, как один из вариантов расширяемости языка. Пример - импорт констант , структур, функций из .Header файлов предназначеных для программ языка С.

Я реализовал полноценную поддержку языка С.
http://forth.spb.su:8888/CinF11.rar или http://www.plati.ru/asp/pay.asp?id_d=45066

Цитата:
Помниться как только я перешел на программирование под Win32 на компиляторе WF32


Что за WF32?

Цитата:
первой проблемой стал перенос всяких #Define, Struct, WinAPI из .h файлов. Пока проекты были небольшие можно было сделать вручную. Но со временем пришлось преодолеть свою лень и написать процедуру компиляции в стиле С. А делов то было, временно переопределить слово WORD чтобы оно выделяло зарезервированные символы применяемые в С, и во вновь


Для восприятия слов с разделителями я завел слово:
MTOKEN ( CTABL -- ADDR LEN ) где CTABL строка со счетчиком содержащая символы
разделители. Я его использую в CinF. Более простой пример: http://fpauk.narod.ru/infix.f

Для большинства случаев #Define можно определить:

: #Define INTERPET CONSTANT ;

Хорошо сочетается с infix.f
Автор:  Mihail [ Пт июн 02, 2006 17:13 ]
Заголовок сообщения: 
Геннадий писал(а):
Главное преимущество на мой взгляд это возможность вмешательство в процесс компиляции, как один из вариантов расширяемости языка. Пример - импорт констант , структур, функций из .Header файлов предназначеных для программ языка С.

Я реализовал полноценную поддержку языка С.
http://forth.spb.su:8888/CinF11.rar или http://www.plati.ru/asp/pay.asp?id_d=45066

Цитата:
Помниться как только я перешел на программирование под Win32 на компиляторе WF32


Что за WF32?

Цитата:
первой проблемой стал перенос всяких #Define, Struct, WinAPI из .h файлов. Пока проекты были небольшие можно было сделать вручную. Но со временем пришлось преодолеть свою лень и написать процедуру компиляции в стиле С. А делов то было, временно переопределить слово WORD чтобы оно выделяло зарезервированные символы применяемые в С, и во вновь


Для восприятия слов с разделителями я завел слово:
MTOKEN ( CTABL -- ADDR LEN ) где CTABL строка со счетчиком содержащая символы
разделители. Я его использую в CinF. Более простой пример: http://fpauk.narod.ru/infix.f

Для большинства случаев #Define можно определить:

: #define
CREATE INTERPRET ,
DOES> @ ;

Хорошо сочетается с infix.f
Автор:  Balancer [ Пт июн 02, 2006 17:42 ]
Заголовок сообщения: 
>Я не могу представить процессора, который не умеет выполнять переходы

Не имеющих такой команды - вагон и маленькая тележка. Начиная с тех же PDP :)

>вызовы подпрограмм

Целый спектр однокристаллок.

>и класть числа на стек данных

Есть множество процессоров не имеющих стека или не имеющих стека, на который можно класть данные.

В общем, мир не исчерпывается одними x86 :)

>jmp может иметь мнемонику jp или bra

Дело может быть не только в мнемонике. Хотя если ты имеешь в виду именно принцпиальную невозможность выполнения процессором вышеуказанных операций - то те же однокристаллки без call остаются в качестве примера.

Форт, кстати, есть и для них. Хотя весьма ограниченный.

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

Но call или push к возможности перемещения указателя не относится.

...

Кстати, даже для выполнения условных операций переход нужен далеко не всегда. Пример: широкораспространённые сейчас ARM-процессоры.

...

Т.е. это всё ещё раз к тому, что все эти call/push/jmp к идеологии Форта отношения не имеют. Вообще.
Автор:  Hishnik [ Пт июн 02, 2006 17:54 ]
Заголовок сообщения: 
Balancer писал(а):
Не имеющих такой команды - вагон и маленькая тележка. Начиная с тех же PDP Smile

Серьезно? PDP не умеет управлять потоком выполнения команд? :)
Balancer писал(а):
Целый спектр однокристаллок.

Например? Чтобы не было возможности вернуться к точке вызова, но при этом выполнялся Форт. Причем даже путем программного запоминания адреса вызова на стеке с последующей передачей управления.

Balancer писал(а):
Есть множество процессоров не имеющих стека или не имеющих стека, на который можно класть данные.

И при этом выполняющие Форт? Причем которые не могут не только положить число на стек, но и организовать стек в памяти и завести указатель на него с программным сопровождением операций push/pop. Какой-то совсем странный процессор получается. Указателем инструкций вообще не управляет (и как он существует тогда?), поток исполнения только линейный, адресация памяти данных отсутствует как таковая.
Balancer писал(а):
Т.е. это всё ещё раз к тому, что все эти call/push/jmp к идеологии Форта отношения не имеют. Вообще.

Что такое "идеология Форта"? Идеология некоего абстрактного языка класса L0 по Хомскому, которому можно в процессе обсуждения приписывать каждый раз другие свойства, или безоперандный синтаксис на стековой машине? Или ANS-94? Что до call/push/jmp - дискутировать надо прежде всего с Барановым-Ноздруновым, там описано выполнение программы Форт-машиной. И делает она вызов, возврат, и переход к следующему слову. Семантика стековых операций да, не специфицирована. Как и в машине Тьюринга не специфицирована семантика операций "просмотр символа", "замена символа". Но та же МТ должна иметь перемещаемый указатель - неважно какими командами и как он перемещается.
Автор:  Геннадий [ Пт июн 02, 2006 21:37 ]
Заголовок сообщения: 
Balancer писал(а):
Не имеющих такой команды - вагон и маленькая тележка

Ёлы-палы! А ещё таких команд не было у арифмометра!

Mihail писал(а):
Что за WF32?

Это переделаный Smal32 под платформу Win32.

Mihail писал(а):
Я реализовал полноценную поддержку языка С.

Вот тут проявляется отрицательные стороны Форта, мягко говоря, "не полная совместимость различных диалектов".
Первое, что бросилось в глаза - слова на ассемблере!
Хотя попробую! Может даже тему необходимо создать - про совместимость?
Автор:  вопрос [ Пт июн 02, 2006 21:57 ]
Заголовок сообщения: 
Мне пришло в голову, что стек - главное ограничение ФОРТа по времени.
Операция помещения в стек и выемки из стека - довольно продолжительные по количеству операций. СуПЕРАССЕМБЛЕР? так ведь польза от ассемблера - скорость, отсутствие лишних движений, а тут нельзя расположить число непосредственно. только в стек... Если же писать самостоятельно передачу параметров от слова к слову через регистры (особенно если он один этот параметр), то чем это удобнее ассемблера?
и call медленне чем jmp ...
Автор:  Hishnik [ Пт июн 02, 2006 22:33 ]
Заголовок сообщения: 
вопрос писал(а):
Мне пришло в голову, что стек - главное ограничение ФОРТа по времени.
Операция помещения в стек и выемки из стека - довольно продолжительные по количеству операций. СуПЕРАССЕМБЛЕР? так ведь польза от ассемблера - скорость, отсутствие лишних движений, а тут нельзя расположить число непосредственно. только в стек... Если же писать самостоятельно передачу параметров от слова к слову через регистры (особенно если он один этот параметр), то чем это удобнее ассемблера?

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

Как язык программирования (со своей грамматикой) Форт хорош тем, что правила создания исполянемого кода получаются очень простые и однообразные.
Страница 2 из 5 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/