Все размеры проблем относительны. Форт может выступать в той же группе, что и Java - существовать на разных платформах и запускать одни и те же программы. Другое дело, что Java и МК - вещи трудносовместимые.


А если речь идет не о задачЕ, а о задачАХ, то каждый раз проходить все эти пп. 1 - 5 может и поднадоесть. Все вот эти "пишете драйверы", "переписываете его под любое желаемое железо"... Это, вобщем-то, и составляет часто основную часть работы, потому что после пятого повторения возникает стойкое ощущение дежа вю.

Речь всегда идет об одной задаче. Задача решения многих задач - тоже задача.
Что делать? Задачи на то и задачи, что их надо решать. И, вполне, может быть не "1-5", а "1-99"...

Вот это и рассматривается в качестве задачи - как ускорить написание форта для серии МК.


"Зачем думать, трясти надо"?

Не интересно. FORTH естественнее использовать в качестве средства решения задачи, чем в качестве части операционной системы/среды.
Следовательно, не "для серии МК", а "для решения определенного круга задач на серии МК".

На практике это одно и то же. Форт для МК обычно делается в настолько урезанном варианте по сравнению с PC, что где там операционная среда, а где задача - не различить. Он просто становится набором утилит и подпрограмм, с которым разработчику удобнее иметь дело. А конечная цель - сократить объем действий по сравнению с Си. Поэтому и нет никакого смысла раскручивать большой маховик исследований, анализа и написания драйверов, раз это усложняет разработку, а не упрощает ее в стратегической перспективе.

Или, наоборот, расширенном. В него добавляются средства решения задачи. Но, что резать, а что вставлять - определяется задачей. Например, у того FORTH, что я пытаюсь писать сейчас, на одном из стеков хранятся текстовые файлы (не указатели, не имена), консолью работает программа на Tcl/Tk, а кодовые слова пишутся на Perl. И мне наплевать, что это мало похоже на FORTH-язык, мне важно, чтобы FORTH-метод работал.

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

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

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

А универсальная среда, для которой надо в десяти местах прописать конфигурацию и настройки - это да, фетиш.

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

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

.
И я о том-же. Вот только с Си приходится сражаться и результат примерно как удаление гланд через задницу автогеном.


eForth написан исключительно на Асме. Все версии.

Ню, могу уточнить задачу. Хочется иметь целевой транслятор Форта который будет переносить Форт-систему представленную в исходниках на целевую платформу. Особенностью такого транслятора будет создание в результате вместо бинарника (собственно как сейчас практически на всех ЦК) ассемблерного текста который в бинарник пержуёт какой нибудь Асм.

Если выкинуть слова "целевая компиляция" будет проще. Пишете на любом переносимом языке псевдоассемблера (действительно, на том же C) исходник FORTH-системы и компилируете, куда надо.
Только это Вас не спасет. Просто лишний перевод с C на FORTH... Решайте настоящую задачу - про Ваши GPS-ы. FORTH сам Вас найдет, когда вы "язык GPS-ов" изобретете.

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


В сутках только 24 часа - на всё не хватает. Еще-бы часов 6 - было-бы в самый раз.

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