Здравствуйте!
Вопрос: как отлаживать программы на форт?
- Ну вот скажем, делаю я программу на форт на устройстве без защиты памяти, понятно что ошибка может мне завалить всю систему (да вобщем и на Линуксе тоже программа может вывалиться в core (аналог GPF винды), и тоже очень тяжело чего-то найти). Как эту проблему решают опытные фортеры?

Дебаггер плохо, потому что зачем-же тогда ЯВУ если отладку делать на уровне кода.

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

Или примерно так:

: квадрат DUP * ; - определили новое слово

2 квадрат . -- проверили, что оно работает правильно и печатается 4

: куб DUP DUP * * ; - определили следующее

опять проверили, что
2 куб . - печатает 8

и т.д.

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

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

то скорее всего текст придется адаптировать к конкретной системе, так как стандартизирован по сути только один вид форт-системы на, приблизительно среднем уровне. Все что ниже него или выше находится на совести создателя системы. Поэтому перенести пример, к примеру с Win32Forth на SPF и обратно не получится без серьезных переделок 8( это уже многократно отмечалось и многократно обсуждалось. Нужен качественно другой стандарт и, соответственно, соответствующие ему системы.


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

Тут язык "бестиповый". Все проверки - на откуп разработчика системы. Считается, что все мы такие умныя и организованныя, что сами догадаемся, когда нам нужно чего проверять и напишем соответствующий код...
Для тестирования кода писать надо будет раза в 3-4 больше основного алгоритма. И для проверки.
В тестах (и не токма Форта это касаемо, от языка вообще это не зависит!) я обычно выбираю пример внутри "области определения" входных данных, по краям, - граничныяе значения, и значения (на "ловлю") вне диапазонов разрешённых значений.
Написано несколько утилит для генерации тестовых наборов (машина - дура - не хай генерит по полному Декартовому произведению сочетание диапазонов указанных областей) -
- Хлопотно только первый раз!
Потом в ножки народ кланяется!

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

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

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

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

Если хочется пошаговую отладку - http://www.easy-share.com/1906074126/DBGWC11.7z

А что это?
PS и можно куда-то в другое место выложить - у меня под FF не сохраняет.

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

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

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

А в условиях, когда "характерные ошибки" у каждого свои - оно и не реально, имхо.



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

Размышления:

Труднообнаруживаемыми - это какими?
Обнаруживаемыми на этапе эксплуатации программы?
( предположу возникшими по невнимательности,
нерабочим кодом и не локально проверенным кодом, плохо понимаемым диапазоном
применимости существующего кода из-за узконапраленности применённого решения, ......
- это всё практика реального программирования и лучше пусть тест определит, что система не работает
сейчас, чем впоследствии )
Из реальных ошибок Форта может проявляться несбалансированность стека из-за
некоректного использования слов. Ещё, навскидку, есть переменные VARIABLE и VALUE .

P.S. Это лирика, а практика подсказывает, что пытаться решить "неизвестную" или
частично надуманную, без определения целевой аудитории пользователей данного
решения, проблему - проблематично. Но попробовать, всё же, стоит если есть
потребность:) Для Форта, что то подобное, Lint были разработки какой выход
не известно.
Существует миф, что Форт программы обладают повышенной надёжностью, но
подтвердить или опровергнуть его мне сложно. ( Возможно вопрос к Nasa
Близко к обозначенному вопросу - защищённость Форт систем уже обсуждался на местном форуме.
а контролировать Форт программы на предмет потенциальных ошибок - это возможно из
трудно осуществимого:) "Хороший" контроль - это изначальное ограничение возможностей
использования инструментария и другие способы к языку почти не относящиееся

Мой опыт отладки в форте - необходимо - никуда не денешься - делать собственные отладочные слова и даже модули.
Сначала отладка намного медленнее, чем в среде С
да и потом тоже
я вот задавался вопросом о таком средстве, полезном часто при отладке как
форматный вывод
http://fforum.winglion.ru/viewtopic.php?t=2069
обсуждение в теме показательно

Проход по строкам в редакторе.
Клавиша F7 - шаг дебагера
Клавиша F8 - шаг дебагера с заходом в подпрограмму
Клавиша F4 - исполнять до курсора

Команда F7_ED играет роль точки останова.

Файл DBG.BAT - запуск примера



http://uploading.com/files/XP46NL8M/dbgwc11.7z.html

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