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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу 1, 2, 3, 4  След.

Форт развивается. Стоит ли использовать новые диалекты?
Плевать на диалекты, мне С-стиля программирования хватает! 0%  0%  [ 0 ]
Я сделал расширение Форта до ... и мне этого хватает! 13%  13%  [ 2 ]
Конечно! Люблю использовать последние достижения! 38%  38%  [ 6 ]
А что, это действительно эффективно? 25%  25%  [ 4 ]
Я вообще Форт не использую! 0%  0%  [ 0 ]
Другое. Опишите свой вариант в форуме. 25%  25%  [ 4 ]
Всего голосов : 16
Автор Сообщение
 Заголовок сообщения: Новые диалекты Форта. ColorForth и др.
СообщениеДобавлено: Пт июн 30, 2006 13:12 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Мур постоянно работал над усовершенствованием языка Форт и в какой-то момент понял, что широкораспространенные процессоры крайне неэффективны. Он приложил свой радикальный подход к созданию новых процессоров. Появление новых процессоров с минимальной системой команд привело к пересмотру языка Форт(или наоборот, Форт был пересмотрен для лучшей реализации в железе). С ним тоже проделали сокращение набора конструкций. Появился новый язык - MachineForth. Изменился стиль программирования. Но, что самое интересное, новый подход не утратил эффективности. Я попробую это показать.

_________________
With best wishes, in4.


Последний раз редактировалось in4 Вт сен 18, 2007 14:34, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 14:12 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Цитата:
Конечно! Я делаю проц и хочу удобно его програмить!


Я полагаю, что нужно использовать новые диалекты, но проц не делаю.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 14:35 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
Кстати, да, процессоры к данному вопросу привязывать как-то странно.
Ведь, если проц достаточно универсален, на нем можно любой диалект реализовать.

А на счет опроса - так в списке ответов не присутствует то, что я бы ответил :)
А именно: "Использование диалектов следует стандартизировать."
Стандартизировать, значит, в исходниках где-то должно быть явно указано, что вот "данный исходник сделан под F83", и на ANS94 он не обязан работать.

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

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 15:47 
Не в сети

Зарегистрирован: Сб май 06, 2006 18:43
Сообщения: 400
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
WingLion писал(а):
Более того, я думаю, что следует стандартизировать некое очень небольшое ядро и на нем реализовать конкретный Форт (конкретный диалект), что потом и указывать в исходниках, так чтобы при попытке его откомпилировать Форт сам сообщал, что "там чего-то не хватает".


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

_________________
http://akps.ssau.ru/forth/


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 16:47 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Внимание! Речь идет не о традиционном Форте, а о новых диалектах, ориентированных на эффективную реализацию в железе.
WingLion писал(а):
А на счет опроса - так в списке ответов не присутствует то, что я бы ответил
А именно: "Использование диалектов следует стандартизировать." Стандартизировать, значит, в исходниках где-то должно быть явно указано, что вот "данный исходник сделан под F83", и на ANS94 он не обязан работать.

Речь шла о новых диалектах. Я видел уже несколько таких. Они очень похожи, но есть разница. Как переведу статьи, ее будет видно.
Сейчас могу привести некоторые примеры.
Код:
if  который не снимает верхушку стека, неразрушающий, надо явно делать drop и использующий флаг проца
-if использующий не верхушку стека, а знаковый флаг проца
множественные точки входа  в слово определение через :  - просто адрес в коде
; множественный выход -  не прекращает компиляцию, а компилирует возврат
если ; стоит после ранее определенного слова  то компилируется переход на него ( оптимизация возврата для экономим ret-call и не заполняем стек возвратов), так реализуется оптимизация хвостовой рекурсии ;)
? - установка флагов знака и нуля по результатам тестирования литерала

И таких отличий может быть много. Даже в наборе команд. Скорость работы команд может значительно отличаться.
Например для intel swap это одна команда, а для какого-то проца это 2 или 3. И будет желательна замена по всему коду мест со swap на аналогичную более эффективную последовательность, обычно с over.
Я не знаю, как такое можно стандартизировать. По-моему, пока это можно только тщательно описать.
И, как обычно - блоки совместимости. Может, будет неэффективно, зато будет работать. А с опытом эффективность возрастет.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 16:56 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
WingLion писал(а):
Более того, я думаю, что следует стандартизировать некое очень небольшое ядро и на нем реализовать конкретный Форт (конкретный диалект), что потом и указывать в исходниках, так чтобы при попытке его откомпилировать Форт сам сообщал, что "там чего-то не хватает".

Ситуация сложнее :( Для разных задач могут быть разные (функционально полные для задачи) наборы команд.
Т.е. пробовать надо. ;) Похоже, это уже будет co-design - железо и софт разрабатываются вместе и оптимизируются с учетом друг друга.
А про нехватку "чего-то" Форт обычно пишет... ;) Только иногда непонятно, что это слово должно делать... ;) - все слова описывать надо!
Например, выражая через другие. Это поможет и при портировании.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 17:20 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
in4 писал(а):
Я не знаю, как такое можно стандартизировать. По-моему, пока это можно только тщательно описать.


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

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


forth@km.ru писал(а):
что-то типа инкрементного тестирования ? скажем к набору программ добавляется тест-исходник, который проверяет, насколько любая форт-система обеспечивает то, что используется программой ?


Нет. Я представляю это дело несколько иначе.
Есть несколько диалектов Форта. И для них есть специальные слова,
которые должен использовать исходник.
скажем, примерно так:

Код:
( F83, F94, CF, MyForth -- зарезервированные константы диалектов)
( DIALEKT - слово возвращающее код диалекта конкретного Форта)

: test DIALEKT
   DUP F83 = IF ." диалект F83 в исходнике не поддерживается" 0 SWAP EXIT THEN   
   DUP F94 = IF ." диалект F94 в исходнике не поддерживается" 0 SWAP EXIT THEN
   DUP CF = IF ." диалект CF в исходнике не поддерживается" EXIT 0 SWAP  THEN     
   DUP MyForth = IF ." диалект MyForth: Старт компиляции! " -1 SWAP  EXIT THEN
   DROP ." Неопознанный диалект - не поддерживается" 0 SWAP ;

( вызов проверки и остановка компиляции, если версия Форта не подходит)
test ?stop-

( далее - саобственно исходник)

.....


Понятно, что диалектов много, и констант на все не напасешься, можно и не константами определять, а, например, строками и использовать сравнение строк для проверки имени диалекта, которое обязан сообщать сам Форт.

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

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 17:28 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
in4 писал(а):
А про нехватку "чего-то" Форт обычно пишет... Wink Только иногда непонятно, что это слово должно делать... Wink - все слова описывать надо!


Вот, потому я и говорю, что надо Форт делать в виде минимального ядра с приложенным к нему исходником остальных слов. Тогда и портирование потребует минимальных затрат, и с действием определенных в исходнике слов вопросы исчезнут. Ну, а слова ядра и должны быть жестко стандартизированы, т.е. чтобы не возникало вопросов с такими словами как DUP, +, =, ?BRANCH и тому подобных, на основе которых описаны все остальные. Если же в ядро включены и дополнительные слова, которые в иных реализациях написаны на форте, а в данной-конкретной, на асме, то в прилагаемом исходнике включить его определение на форте как комментарий, чтобы не было неясностей.

P.S. Я свой Форт именно по такой схеме сделал, и он у меня на двух платформах работает.

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 17:45 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Мне как-то ближе ColorLessColorForth. Без сложностей с цветами. Про них надо рассказывать подробнее.
А так - перевожу фрагмент - отличие MachineForth от традиционного из журнала Forthwrite июнь 2000, автор John Tasgal.

Точка с запятой
Это не окончание определения; это означает просто "возврат". Определения идут друг за другом. И, если одно определение вызывает другое в конце, можно поставить их рядом и сэкономить на call-ret. -in4

Регистры адреса
Адреса перемещаются из стека данных в регистр, A или R. Оба регистра имеют автопостинкрементные команды. Это изменяет стиль Форта, т.к. адресная арифметика становится привлекательнее, чем использование DO...LOOP с индексами.

Неразрушающие проверки условий
В Классическом Форте IF разрушает верхушку стека. Однако, в MachineForth-е IF, и все условные констукции, основанные на нем, неразрушающие. Можно не использовать DUP, когда условия повторно проверяют флаг.
Но это может привести к бОльшему использованию DROP для удаления флагов, которые были бы удалены традиционной проверкой. Предлагается, что поведение других слов и, если необходимо, структура самой программы, оптимизировались бы для использования неразрушающих условий. Не стоит просто копировать программы, написанные с использованием разрушающих версий проверок.

_________________
With best wishes, in4.


Последний раз редактировалось in4 Вт мар 20, 2012 14:45, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 18:03 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
WingLion писал(а):
Соответственно, исходник, использующий конкретное железо должен, скажем так, об этом объявить вначале. И, выяснив, что он компилится не под то железо, сделать исправления в себе, например, переопределить тот же if так чтобы он работал так как надо данному исходнику.

Идейно неплохо. Но в случае embedded - программы обычно маленькие, особенности железа известны, лучше иметь программы попроще(и помельче) и вручную проверять. Тогда точно не нарвешься на какой-то чужой баг(непроверенную ветку проги). Меньше сложность - меньше проверок - меньше вероятность ошибок.

А так - можно сделать внешний модуль проверок. Типа раз запустил, он выдал диагностику, и смотришь, куда надо. Пишешь модули совместимости и тестишь еще раз.
Вот не уверен насчет автопроверки железа исходником! Программист должен знать, на каком типе железа прога работает!

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 18:21 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
WingLion писал(а):
Можно и не так, а просто подавать Форту строку с требуемым диалектом, и он либо сообщает о его неподдержке, либо переключается в режим этого диалекта.


По-фортовски (я очень мучительно к этому иду :( ) лучше иметь несколько простых диалектов, чем один сложный (но универсальный)!
Только вот как поддерживать несколько параллельных разных версий? ;)

Все-таки лучше описать вначале исходника, что для него требуется. Стандартная автоматика хороша для устоявшихся вещей! ;)

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 18:42 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
in4 писал(а):
Идейно неплохо. Но в случае embedded - программы обычно маленькие, особенности железа известны, лучше иметь программы попроще(и помельче) и вручную проверять. Тогда точно не нарвешься на какой-то чужой баг(непроверенную ветку проги). Меньше сложность - меньше проверок - меньше вероятность ошибок.


Проверку вначале исходника в режиме исполнения формально и можно считать "ручной". А определенные во время проверки слова просто FORGET-ить :) в начале собственно исходника. И сама проверка ни в какой результат компиляции не попадает.

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

\ Сделано для СуперПуперКонтроллера ATMega-3996, на P-XXI работать не будет!

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 18:46 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
in4 писал(а):
Все-таки лучше описать вначале исходника, что для него требуется. Стандартная автоматика хороша для устоявшихся вещей! Wink


Именно так! И, если нет стандартных средств - сделать свои, которые просто проверят, под каким Фортом компиляция проходит. Например, определит наличие необходимых слов и их "правильное" исполнение.

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

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июн 30, 2006 19:13 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Еще фрагмент - отличие MachineForth от традиционного из журнала Forthwrite июнь 2000, автор John Tasgal.

Еще пример изменения в стиле программирования.

Оптимизация хвостовой рекурсии
В любом определении завершающее действие слова перед точной с запятой и сама точка с запятой может быть всегда скомпилировано в единственный возврат.
word1 ... lastword ;
Т.к. ничего не случается между возвратом в lastword и возвратом по ;, возврат в lastword излишний.

Более сложный пример - это рекурсивный вызов в конце цикла WHILE. Если мы имеем серию вложенных вызовов, тогда последняя команда в каждом случае - это возврат. При работе это дает "; ; ; ; ;", а именно - последовательность возвратов.
Дело в том, что когда эти вызовы раскручиваются, все, что случается, это выполнение последовательности возвратов, один за другим. Ничего не выполняется между ними. Единственный необходимый возврат - это первый, размещенный в стеке возвратов (и последний выполняющийся).

Удаление этих излишних возвратов известно как оптимизация хвостовой рекурсии. Большинство компиляторов MachineForth-а (и также ColorForth-а) имеют оптимизатор хвостовой рекурсии.

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

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

Это действительно очень необычный и элегантный подход к проблеме.

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 14, 2006 17:47 
На втором курсе писал по этому делу курсовую (куратор сказал мне это дело "расчехвостить как следует"). Я "расчехвостил" в меру пониманий. Написал программку на cf. Потом он заставил по результатам написать статью. Я там чего-то кривенько-кривенько написал и сдал. Сейчас там ничего трогать не хочу, хотя следовало бы... В общем вот...

http://forth.org.ru/~profit/COLOR4th.pdf


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу 1, 2, 3, 4  След.

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


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 11


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

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