Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пн окт 21, 2019 17:24

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Сравнительную табличку разных систем для мелких процов
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
"А в это время в замке..."

Тем временем автор вопроса пытается разгребать бесценное наследие сторонников ФОРТа и потихоньку начинает приходить в ужас.

Изобретать свое, как обычно, не очень хочется, поскольку в недрах моего компа и так уже спят где-то давним сном "свои" интерпретаторы разной ерунды, верхом совершенства из которых (на мой личный взгляд) являлся LISP с возможностью замыкания списков в колечки или, может, скрипт-язык для управляющих неизвестно чем программ в POSIX-системах. Но теперь я уже старенький, ленивый... Это в школьно-студенческие годы хорошо "новые ОСи" придумывать и "новые компиляторы" крича на всех углах, что все старое надо сбросить с парохода современности.

По нескольким последним темам на форуме заинтересовался, в частности, eForth а также статьей о портировании ФОРТа. Впрочем два варианта eForth относящиеся к 8051 процам, которые я скачал чтобы посмотреть "как оно" с упорством достойным лучшего применения виснут, правда немецкий не сразу. Посмотрел уж заодно CamelForth/51 и 51forth.zip, однако обнаружил что оба из них в общем-то не кросс-компиляторы, а прям таки хочут внедриться в проц. Забавно, но не сказал бы, что очень мне нужно.

Продолжаю думать дальше.

Основная мысль в том, что прежде чем делать что-то свое, хотелось бы потщательнее изучить наследие (обычно внимательное рассмотрение существующих наработок обеспечивает 30-70% успеха, в зависимости от сферы деятельности, на мой взгляд). Поэтому продолжаю искать какой-нибудь приличный кросс-компилятор.
Сообщение Добавлено: Вт сен 01, 2009 04:24
  Заголовок сообщения:   Ответить с цитатой
Kopa писал(а):
Т.е. есть возможность увидеть Форт код в программном симуляторе и осуществить пошаговую отладку по словам?
( например в Proteus-е?)

Тут надо немного разделить. Если симулятор делается изначально под Форт, то почему бы нет. Тем более что в Форт-процессоре пошаговая отладка по командам и будет эквивалентна отладке по форт-словам. Но речь, насколько я понимаю, идет о создании Форта для широко распространенных МК, которые могут иметь симуляторы, работающие по командам процессора, иллюстрируемые ассемблерным кодом соответствующего МК. В данном случае требовать еще и отладки по словам Форта - совершенно лишнее. Я не говорю, что бесполезное, но это наслаивание требований, когда еще и базовой реализации-то нет.
Сообщение Добавлено: Пн авг 31, 2009 22:02
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Kopa писал(а):
Наверное сформировать отладочный код для отладчика из
Форт исходника, например, в формате псевдо Си и иметь
возможность пошаговой отладки

А зачем такие полумеры, если можно работать непосредственно с кодом? Даже программные симуляторы, как правило, могут загрузить готовый образ памяти МК и моделировать его исполнение. Безотносительно того, через какую цепочку инструментов оно прошло. Я уже не говорю о том, что вместо разнообразного моделирования надежнее брать реальный МК.


Т.е. есть возможность увидеть Форт код в программном симуляторе и осуществить пошаговую отладку по словам?
( например в Proteus-е?)
Сообщение Добавлено: Пн авг 31, 2009 16:26
  Заголовок сообщения:   Ответить с цитатой
Kopa писал(а):
Наверное сформировать отладочный код для отладчика из
Форт исходника, например, в формате псевдо Си и иметь
возможность пошаговой отладки

А зачем такие полумеры, если можно работать непосредственно с кодом? Даже программные симуляторы, как правило, могут загрузить готовый образ памяти МК и моделировать его исполнение. Безотносительно того, через какую цепочку инструментов оно прошло. Я уже не говорю о том, что вместо разнообразного моделирования надежнее брать реальный МК.
Сообщение Добавлено: Пн авг 31, 2009 16:16
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Стоп, это о чем? Формируется образ памяти целевого процессора в соответствии с требованиями программатора/эмулятора.

Это о том, что целевой код будет реально верно исполняться (программатор прошьет корректно), а в процессе отладки на симуляторе-эмуляторе
(в который также код грузится корректно) отображение этого кода, а иногда и ход по программе будет неадекватным(особенности кода сформированного
фортом в связке с особенностями анализа этого кода в симуляторе-эмуляторе скажутся).
Сообщение Добавлено: Пн авг 31, 2009 16:14
  Заголовок сообщения:   Ответить с цитатой
MrYuran писал(а):
То есть система такая: платформо-зависимые и критичные по времени места пишем не на ассемблере, а делаем что-то типа
Код:

    ... с code ...
c]

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

Михаил так и предлагает:) Asm лучше Си тем, что для него
не существует никаких семантических моделей высокоуровневых языков.
Си код во вставке необязательно должен поддерживать
весь синтаксис и семантику Си языка, а только необходимую
в реализации Форт системы.
Например, в Форте могут присутствовать слова
Код:
if( do(  while( for(
Сообщение Добавлено: Пн авг 31, 2009 16:11
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
chess писал(а):
Формат литералов может не поддерживаться симулятором-эмулятором, например, хотя для Форта все будет корректно.
Ну ладно, в данном случае можно извернуться и привести формат литералов в форму понятную симулятору

Стоп, это о чем? .

Наверное сформировать отладочный код для отладчика из
Форт исходника, например, в формате псевдо Си и иметь
возможность пошаговой отладки:)
Сообщение Добавлено: Пн авг 31, 2009 15:59
  Заголовок сообщения:   Ответить с цитатой
MrYuran писал(а):
То есть система такая: платформо-зависимые и критичные по времени места пишем не на ассемблере, а делаем что-то типа

Форт можно и так писать сразу на Си.
Сообщение Добавлено: Пн авг 31, 2009 15:16
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Формат литералов может не поддерживаться симулятором-эмулятором, например, хотя для Форта все будет корректно.
Ну ладно, в данном случае можно извернуться и привести формат литералов в форму понятную симулятору

Стоп, это о чем? Формируется образ памяти целевого процессора в соответствии с требованиями программатора/эмулятора. Литералы там, или команды, разницы уже никакой. Никаких листингов, списков или прочих полуфабрикатов. В идеальном варианте должна быть возможность отослать в МК файл, содержащий "слепок" всей памяти. В этом случае задачей целевого компилятора будет создать такой слепок.
Сообщение Добавлено: Пн авг 31, 2009 15:14
  Заголовок сообщения:   Ответить с цитатой
Может, не совсем по теме, но мне показалось по итогам моего беглого обзора фортов (который так и не окончен по причине глобального завала на работе), что очень не хватает инлайн-си.
То есть система такая: платформо-зависимые и критичные по времени места пишем не на ассемблере, а делаем что-то типа
Код:

    ... с code ...
c]

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

По-моему, это существенно улучшило бы переносимость и совместимость разных систем, поскольку потребовалось бы только унифицировать интерфейсы.
А также открывается доступ ко всему богатству накопленных возможностей, имеющихся в других языках и средах.
Сообщение Добавлено: Пн авг 31, 2009 14:45
  Заголовок сообщения:   Ответить с цитатой
Формат литералов может не поддерживаться симулятором-эмулятором, например, хотя для Форта все будет корректно.
Ну ладно, в данном случае можно извернуться и привести формат литералов в форму понятную симулятору
(при этом нужно будет пожертвовать компактностью форт-кода - правда, потом, после отладки, можно отыграть назад
и восстановить исходный фортовский формат литералов)
Кроме того не будет адресной поддержки слов форта на уровне симулятора-эмулятора - но это обходится листингом,
который должна выдавать форт-система.
Хищник писал(а):
Это закрывается пунктом 8.

В общем - да, но не автоматически, а с некими издержками.
Сообщение Добавлено: Пн авг 31, 2009 14:23
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Я бы еще один пункт добавил:
Нужен ли какой-либо отладочный интерфейс с существующими симуляторами
и эмуляторами данного МК (хотя-бы на уровне ассемблерного кода).

Это закрывается пунктом 8.
Сообщение Добавлено: Пн авг 31, 2009 13:54
  Заголовок сообщения:   Ответить с цитатой
Я бы еще один пункт добавил:
Нужен ли какой-либо отладочный интерфейс с существующими симуляторами
и эмуляторами данного МК (хотя-бы на уровне ассемблерного кода).
Сообщение Добавлено: Пн авг 31, 2009 13:42
  Заголовок сообщения:   Ответить с цитатой
вопрос писал(а):
Это сколько ж повторной работы получилось

Для Форта достаточно хорошо подходят модели жизненного цикла, подразумевающие итерации. Так что никакой лишней повторной работы тут не видно. Написать один раз всеобъемлющее ТЗ, и потом закопаться в него, выдав через полгода-год Суперфорт Для Всех Микроконтроллеров - это чревато мощнейшим промахом. Форт-то будет... вот только окажется никому не нужным.
Я могу предложить навскидку группу вопросов, которые могут помочь очертить круг требований к кроссплатформенному транслятору для МК
1) Совпадает ли разрядность данных с разрядностью каждого процессора? Является ли она фиксированной? (Хуже - когда МК имеют разные разрядности, и каждый должен работать с "естественной" разрядностью)
2) Какая память и какого вида доступна? Есть ли отдельное адресное пространство памяти данных? Может ли процессор модифицировать память программ в процессе работы, или это возможно только с помощью внешнего программатора? (Лучше - когда память модифицируется, есть флеш программ большого объема, и SRAM для данных)
3) Можно ли указать минимальные требования к объему памяти (которым должен удовлетворять каждый МК, используемый совместно с транслятором).
4) Будет ли использоваться только кросс-компиляция, или МК должен интерпретировать входной поток? Должен ли он также компилировать новые слова (см. также п.2 по поводу возможности модификации памяти), или во входном потоке достаточно исполнять команды? (Проще - когда используется только кросс-компиляция)
5) Требуется ли тесная интеграция в систему сложных интерфейсов (например, требуется ли работа с USB и TCP/IP, что требует реализации поддержки на протокольном уровне)? (Лучше - когда не требуется, или с помощью библиотек от производителя сложные интерфейсы могут эмулировать более простой протокол - например, виртуальный последовательный порт)
6) Являются ли требования к производительности жесткими? (Лучше - когда от Форта не требуется уметь компилировать исключительно быстрый код, а критичный код выносится в ассемблерные вставки или подключается из языков высокого уровня)
7) Требуется ли предельная компактность программы на Форте? (От этого зависит целесообразность использования шитого кода в одном из компактных представлений)
8) Имеется ли простой и документированный формат загрузки для каждого из используемых МК? (Лучше - когда сгенерированный образ памяти МК может быть загружен в МК без преобразований, что позволяет прошивать непосредственно результат работы кросс-компилятора)
9) Насколько интенсивным будет доводка и сопровождение продукта, для которого предполагается МК+Форт? (Лучше - если интенсивным, с частыми правками логики работы, чтобы проявились положительные качества проблемно-ориентированного языка, который можно написать на Форте для сопровождаемой задачи)
10) Есть ли показательное применение для Форта и резерв по времени до передачи в производство/эксплуатацию? (Желательно - в районе полугода спокойной доводки)
Сообщение Добавлено: Вс авг 30, 2009 15:07
  Заголовок сообщения:   Ответить с цитатой
RodionGork писал(а):
привлечением потусторонних сил) - табличку, перечисляющую какое-то количество более-менее популярных и работоспособных вариаций ФОРТа с указанием основных особенностей, сравнительных характеристик и т.п.


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

RodionGork писал(а):
АВР, ПИК, МСП и т.п

АВР и МСП есть
Создать версию для другой платформы относительно легко.
Я предлагаю попробовать самому. А мы поможем.
Сообщение Добавлено: Вс авг 30, 2009 14:01

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


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