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

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

Обзор темы - От кросс-ассемблера к кросс-Форту для форт-процессора
Автор Сообщение
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
mOleg писал(а):
кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;)
по крайней мере запросы делать.

Ну, это называется "зелен виноград" :)
mOleg писал(а):
да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п.

Еще раз. Речь идет о регулярно используемых инструментах. Вон одна из первых рабочих сборок IDE для кросс-форта на Дельфи имеет дату от 2004 года. И что значит "либу навесить"? Дельфи упомянуто не один раз, там ничего не навешивается, там форма рисуется, а редактор так и вообще ставится одним компонентом.
mOleg писал(а):
Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда).

Ерунда какая. Текстовый редактор с кнопкой "загрузить в процессор" - это красивости? И просто "приятно для работы"? Не повышает (реально) производительность разработчика, а вот так просто "приятно"? А можно узнать - с чего это вдруг я за этой красивостью заметил уже человек 10 работающих, причем почти все берут эту IDE просто как данность? "Почти" - потому что некоторые еще и собственные ветки делают, на тех же принципах.
Сообщение Добавлено: Пн апр 19, 2010 11:17
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хищник писал(а):
mOleg писал(а):
не понятно, почему обязательно кнопочку надо.
Может проще набирать слово в консоли?

А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? :)

кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;)
по крайней мере запросы делать.

Хищник писал(а):
mOleg писал(а):
Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?
А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни?

да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п.
Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда).
Сообщение Добавлено: Пн апр 19, 2010 10:15
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
вопрос писал(а):
Ага, вот о протоколе обмена я не подумал, ну что ж - тут подразумевается, что должен быть отдельный файл с описанием протокола обмена, видимо

Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК


При разработке конструкции в ПЛИС достижение максимальной эффективности "по всем фронтам" - непростая задача. Внимание фокусируется на ключевых аспектах, и загрузка программы в процессор здесь является вспомогательной операцией. Соответственно, проектирование загрузчика производится по принципу "чтобы в нем было поменьше возможностей ошибиться". Я не могу сказать, что в моих системах плохой загрузчик, просто он максимально прост - чтобы в ситуации "ничего не работает" можно было быстро убедиться, что дело не в нем. Но когда программа на Дельфи уже содержит процедуру отсылки программы в определенном формате, этот формат "прилипает" к системам. Как провести переход на другой протокол? Что при этом делать с уже работающими системами - ведь перекомпилированная среда разработки не сможет их запрограммировать? С другой стороны, другая аппаратная реализация загрузчика также требует программной поддержки. Вот и получается, что в среде разработки нужен какой-то переключатель протокола, а это лишний пунктик в настройках и повод к ситуациям "ничего не работает, а почему - знает только ограниченное число людей". Вот и получается, что программе желательно таскать загрузчик с собой. Не ради постоянных изменений, а просто потому, что так надежнее.
Сообщение Добавлено: Пн апр 19, 2010 02:01
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хищник писал(а):
вопрос писал(а):
Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?

Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается протокол обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору.

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

Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК :?:
Сообщение Добавлено: Вс апр 18, 2010 23:14
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
вопрос писал(а):
Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?

Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается протокол обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору.
Сообщение Добавлено: Вс апр 18, 2010 21:52
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хищник писал(а):
вопрос писал(а):
формат загрузки
1. кода в целевой процессор (?)

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

Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?
Сообщение Добавлено: Вс апр 18, 2010 21:46
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
mOleg писал(а):
не понятно, почему обязательно кнопочку надо.
Может проще набирать слово в консоли?

А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? :)
mOleg писал(а):
Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?

А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни?
Сообщение Добавлено: Вс апр 18, 2010 21:43
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
вопрос писал(а):
формат загрузки
1. кода в целевой процессор (?)

Ну ясно же, что в целевой процессор. Что, интересно, может быть за формат загрузки исходного кода в программу на Дельфи? Кроме текстового-то...
Сообщение Добавлено: Вс апр 18, 2010 21:41
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хищник писал(а):
Дело в том, что при эксплуатации форт-процессоров для Xilinx стихийно сложилась ситуация, когда основным требованием к кросс-транслятору стало наличие редактора (ну и кнопочек "компилировать", "загрузить").

не понятно, почему обязательно кнопочку надо.
Может проще набирать слово в консоли?
Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?
Сообщение Добавлено: Вс апр 18, 2010 19:46
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хищник писал(а):
На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки.
Ага, я так и предполагал где-то. А как, собственно, теперь непонятно, жёсткость Дельфи влияет на результирующий код? для меня это звучит так. как "написанный на медленном языке компилятор выдаёт медленный код" ("сделанный на фиолетовом языке компилятор будет выдавать только фиолетовый код" :shock: :o - пробую цвета)
формат загрузки
1. кода в целевой процессор (?)
2. исходного кода в сделанный на Дельфи компилятор?
:?:
Сообщение Добавлено: Вс апр 18, 2010 19:43
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
вопрос писал(а):
Цитата:
Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора.

ничего не понял. Можно не для самых проницательных?
Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор

На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки.
Сообщение Добавлено: Вс апр 18, 2010 19:38
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Цитата:
Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора.

ничего не понял. Можно не для самых проницательных?
Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор
Сообщение Добавлено: Вс апр 18, 2010 19:31
  Заголовок сообщения:  Re: От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Хм. Может, и вправду, на дельфях слепить то что у меня на форте пока не получается?
Сообщение Добавлено: Вс апр 18, 2010 19:07
  Заголовок сообщения:  От кросс-ассемблера к кросс-Форту для форт-процессора  Ответить с цитатой
Решил слегка обобщить разработки по кросс-ассемблеро-форту. Дело в том, что при эксплуатации форт-процессоров для Xilinx стихийно сложилась ситуация, когда основным требованием к кросс-транслятору стало наличие редактора (ну и кнопочек "компилировать", "загрузить"). Соответственно, на первый план вышли решения на Дельфи (и ему подобных) системах разработки, поскольку в них можно достаточно просто положить редактор и кнопочки на форму, ну и как-то привязать к ним несложные действия по компиляции и загрузке. В одной из оболочек даже имел место разбор файла конфигурации системы команд, в котором были перечислены мнемоники и опкоды. Это позволяло, по меньшей мере, добавлять к процессорному ядру вспомогательные полезные команды, не переписывая для этого саму программу. Однако есть ряд операций, которые так просто не делаются:
1) Загрузка конфигурации и последующее общение с процессором
Проблема состоит в компилируемом характере программы на Дельфи - все варианты настройки могут появиться только в результате установки каких-то полей, флажков и нажатия кнопок. Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора.
2) Смена формата управляющих конструкций и литералов.
Все это компилируется отдельно, и этим все сказано.

Почему не было сделано на Форте? Сделано. Только см. выше - поскольку нет встроенного модуля редактора, кросс-транслятор лег мертвым грузом. Хотя общаться с процессором через Форт не в пример удобнее, скриптики пишутся очень быстро.

Как организован транслятор. Сначала компилируется переход "куда-то вперед". Появление слова-метки MAIN: как раз и отвечает на вопрос "куда именно вперед". Такая метка одна, и обрабатывается отдельно. Дальше все достаточно просто - команды берутся из списка, числа - это числа, и есть конструкции управления.

Код:
IF ELSE THEN
BEGIN AGAIN UNTIL
WHILE REPEAT


В зависимости от наличия в ядре процессора аппаратного стека циклов делается.
Код:
DO LOOP I
Его же можно сделать и программно, выделив кусок памяти и переменную - указатель глубины. Тактов больше, места меньше. Пока было аппаратно, сейчас склоняюсь к программной реализации.
Еще есть VARIABLE и ARRAY, который, вследствие реализации на Дельфи, шел в стиле ARRAY X[] 1024 (а не 1024 ARRAY X[]).

Вот примерно на этом оно все и летает.
Сообщение Добавлено: Вс апр 18, 2010 18:48

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


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