Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
mOleg писал(а): кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;) по крайней мере запросы делать. Ну, это называется "зелен виноград" mOleg писал(а): да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п. Еще раз. Речь идет о регулярно используемых инструментах. Вон одна из первых рабочих сборок IDE для кросс-форта на Дельфи имеет дату от 2004 года. И что значит "либу навесить"? Дельфи упомянуто не один раз, там ничего не навешивается, там форма рисуется, а редактор так и вообще ставится одним компонентом. mOleg писал(а): Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда). Ерунда какая. Текстовый редактор с кнопкой "загрузить в процессор" - это красивости? И просто "приятно для работы"? Не повышает (реально) производительность разработчика, а вот так просто "приятно"? А можно узнать - с чего это вдруг я за этой красивостью заметил уже человек 10 работающих, причем почти все берут эту IDE просто как данность? "Почти" - потому что некоторые еще и собственные ветки делают, на тех же принципах.
[quote="mOleg"]кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;) по крайней мере запросы делать.[/quote] Ну, это называется "зелен виноград" :) [quote="mOleg"]да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п.[/quote] Еще раз. Речь идет о регулярно используемых инструментах. Вон одна из первых рабочих сборок IDE для кросс-форта на Дельфи имеет дату от 2004 года. И что значит "либу навесить"? Дельфи упомянуто не один раз, там ничего не навешивается, там форма рисуется, а редактор так и вообще ставится одним компонентом. [quote="mOleg"]Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда).[/quote] Ерунда какая. Текстовый редактор с кнопкой "загрузить в процессор" - это красивости? И просто "приятно для работы"? Не повышает (реально) производительность разработчика, а вот так просто "приятно"? А можно узнать - с чего это вдруг я за этой красивостью заметил уже человек 10 работающих, причем почти все берут эту IDE просто как данность? "Почти" - потому что некоторые еще и собственные ветки делают, на тех же принципах.
|
|
|
|
Добавлено: Пн апр 19, 2010 11:17 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Хищник писал(а): mOleg писал(а): не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;) по крайней мере запросы делать. Хищник писал(а): mOleg писал(а): Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок? А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни? да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п. Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда).
[quote="Хищник"][quote="mOleg"]не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? [/quote] А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? :)[/quote] кстати да, уверен, что текстовый интерфейс (вместо используемого графического) дал бы определенные преимущества форуму;) по крайней мере запросы делать.
[quote="Хищник"][quote="mOleg"]Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок? А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни?[/quote][/quote] да всегда так было. Текстовую консоль в Форте мы уже имеем как данность, т.е. достаточно создать отдельный словарь с нужными понятиями и дать им пользоваться. А для графики нужно еще либу навесить, да еще кнопочки придумать как обозвать и как нарисовать и т.п. Вобщем, это красивости, которые хороши для презинтаций и домохозяек, а для работы не обязательны (хотя и приятны иногда).
|
|
|
|
Добавлено: Пн апр 19, 2010 10:15 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
вопрос писал(а): Ага, вот о протоколе обмена я не подумал, ну что ж - тут подразумевается, что должен быть отдельный файл с описанием протокола обмена, видимо
Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК При разработке конструкции в ПЛИС достижение максимальной эффективности "по всем фронтам" - непростая задача. Внимание фокусируется на ключевых аспектах, и загрузка программы в процессор здесь является вспомогательной операцией. Соответственно, проектирование загрузчика производится по принципу "чтобы в нем было поменьше возможностей ошибиться". Я не могу сказать, что в моих системах плохой загрузчик, просто он максимально прост - чтобы в ситуации "ничего не работает" можно было быстро убедиться, что дело не в нем. Но когда программа на Дельфи уже содержит процедуру отсылки программы в определенном формате, этот формат "прилипает" к системам. Как провести переход на другой протокол? Что при этом делать с уже работающими системами - ведь перекомпилированная среда разработки не сможет их запрограммировать? С другой стороны, другая аппаратная реализация загрузчика также требует программной поддержки. Вот и получается, что в среде разработки нужен какой-то переключатель протокола, а это лишний пунктик в настройках и повод к ситуациям "ничего не работает, а почему - знает только ограниченное число людей". Вот и получается, что программе желательно таскать загрузчик с собой. Не ради постоянных изменений, а просто потому, что так надежнее.
[quote="вопрос"]Ага, вот о протоколе обмена я не подумал, ну что ж - тут подразумевается, что должен быть отдельный файл с описанием протокола обмена, видимо
Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК [/quote]
При разработке конструкции в ПЛИС достижение максимальной эффективности "по всем фронтам" - непростая задача. Внимание фокусируется на ключевых аспектах, и загрузка программы в процессор здесь является вспомогательной операцией. Соответственно, проектирование загрузчика производится по принципу "чтобы в нем было поменьше возможностей ошибиться". Я не могу сказать, что в моих системах плохой загрузчик, просто он максимально прост - чтобы в ситуации "ничего не работает" можно было быстро убедиться, что дело не в нем. Но когда программа на Дельфи уже содержит процедуру отсылки программы в определенном формате, этот формат "прилипает" к системам. Как провести переход на другой протокол? Что при этом делать с уже работающими системами - ведь перекомпилированная среда разработки не сможет их запрограммировать? С другой стороны, другая аппаратная реализация загрузчика также требует программной поддержки. Вот и получается, что в среде разработки нужен какой-то переключатель протокола, а это лишний пунктик в настройках и повод к ситуациям "ничего не работает, а почему - знает только ограниченное число людей". Вот и получается, что программе желательно таскать загрузчик с собой. Не ради постоянных изменений, а просто потому, что так надежнее.
|
|
|
|
Добавлено: Пн апр 19, 2010 02:01 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Хищник писал(а): вопрос писал(а): Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре? Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается протокол обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору. Ага, вот о протоколе обмена я не подумал, ну что ж - тут подразумевается, что должен быть отдельный файл с описанием протокола обмена, видимо Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК
[quote="Хищник"][quote="вопрос"]Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?[/quote] Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается [i]протокол [/i]обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору.[/quote] Ага, вот о протоколе обмена я не подумал, ну что ж - тут подразумевается, что должен быть отдельный файл с описанием протокола обмена, видимо :?
Если протокол обмена часто изменяется, то как можно вкомпилировать его в код ЦК :?:
|
|
|
|
Добавлено: Вс апр 18, 2010 23:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
вопрос писал(а): Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре? Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается протокол обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору.
[quote="вопрос"]Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?[/quote] Целевой процессор - это конфигурация в ПЛИС. У нее нет никаких специальных загрузчиков (программирование самой ПЛИС не в счет). Вот протянут шнурок от COM-порта до выводов ПЛИС, по нему бегут импульсы (даже пока не байтики). Можно сделать контроллер со стороны ПЛИС, он будет делать из импульсов байтики. Что дальше? Как понять, что вот это - начало программирования, вот это - данные, а вот это - конец программы и сигнал на старт исполнения? Вот и придумывается [i]протокол [/i]обмена с форт-процессором, который должен быть реализован и со стороны программы на Дельфи. А раз он туда вкомпилирован, то, чтобы его поменять, надо либо постоянно держать открытой саму среду разработки Дельфи, либо ставить кучу переключателей "режим 1", "режим 2"... и постоянно сверяться, в том ли формате кросс-транслятор передает программу процессору.
|
|
|
|
Добавлено: Вс апр 18, 2010 21:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Хищник писал(а): вопрос писал(а): формат загрузки 1. кода в целевой процессор (?) Ну ясно же, что в целевой процессор. Что, интересно, может быть за формат загрузки исходного кода в программу на Дельфи? Кроме текстового-то... Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?
[quote="Хищник"][quote="вопрос"]формат загрузки 1. кода в целевой процессор (?)[/quote] Ну ясно же, что в целевой процессор. Что, интересно, может быть за формат загрузки исходного кода в программу на Дельфи? Кроме текстового-то...[/quote] Вроде бы понятно, тогда что за сложности с загрузкой (видимо я не ловлю какой-то этап)? Сложности с загрузкой в целевой процессор, т.к. он начинает иначе воспринимать код? или сложности с загрузкой кода, который должен быть сделан в другой структуре?
|
|
|
|
Добавлено: Вс апр 18, 2010 21:46 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
mOleg писал(а): не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? mOleg писал(а): Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок? А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни?
[quote="mOleg"]не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? [/quote] А зачем вот на форуме кнопочки? Может, проще набирать слово в консоли для отсылки сообщений и составления ответов? :) [quote="mOleg"]Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?[/quote] А с каких пор разработка графического интерфейса к часто используемым инструментам стала усложнением жизни?
|
|
|
|
Добавлено: Вс апр 18, 2010 21:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
вопрос писал(а): формат загрузки 1. кода в целевой процессор (?) Ну ясно же, что в целевой процессор. Что, интересно, может быть за формат загрузки исходного кода в программу на Дельфи? Кроме текстового-то...
[quote="вопрос"]формат загрузки 1. кода в целевой процессор (?)[/quote] Ну ясно же, что в целевой процессор. Что, интересно, может быть за формат загрузки исходного кода в программу на Дельфи? Кроме текстового-то...
|
|
|
|
Добавлено: Вс апр 18, 2010 21:41 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Хищник писал(а): Дело в том, что при эксплуатации форт-процессоров для Xilinx стихийно сложилась ситуация, когда основным требованием к кросс-транслятору стало наличие редактора (ну и кнопочек "компилировать", "загрузить"). не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?
[quote="Хищник"]Дело в том, что при эксплуатации форт-процессоров для Xilinx стихийно сложилась ситуация, когда основным требованием к кросс-транслятору стало наличие редактора (ну и кнопочек "компилировать", "загрузить"). [/quote] не понятно, почему обязательно кнопочку надо. Может проще набирать слово в консоли? Не, я понимаю, что это несколько сложнее, но нафига себе усложнять жизнь, когда можно нажать пару кнопок?
|
|
|
|
Добавлено: Вс апр 18, 2010 19:46 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Хищник писал(а): На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки. Ага, я так и предполагал где-то. А как, собственно, теперь непонятно, жёсткость Дельфи влияет на результирующий код? для меня это звучит так. как "написанный на медленном языке компилятор выдаёт медленный код" ("сделанный на фиолетовом языке компилятор будет выдавать только фиолетовый код" - пробую цвета) формат загрузки 1. кода в целевой процессор (?) 2. исходного кода в сделанный на Дельфи компилятор?
[quote="Хищник"] На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки. [/quote]Ага, я так и предполагал где-то. А как, собственно, теперь непонятно, жёсткость Дельфи влияет на результирующий код? для меня это звучит так. как "написанный на медленном языке компилятор выдаёт медленный код" ("сделанный на [color=#BF00FF]фиолетовом[/color] языке компилятор будет выдавать только [color=#BF00FF]фиолетовый[/color] код" :shock: :o - пробую цвета) формат загрузки 1. кода в целевой процессор (?) 2. исходного кода в сделанный на Дельфи компилятор? :?:
|
|
|
|
Добавлено: Вс апр 18, 2010 19:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
вопрос писал(а): Цитата: Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора. ничего не понял. Можно не для самых проницательных? Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки.
[quote="вопрос"][quote] Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора.[/quote] ничего не понял. Можно не для самых проницательных? Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор[/quote] На Дельфи написано приложение, в котором есть редактор и кросс-компилятор. Получается массив с кодами форт-процессора, который уходит в него по COM-порту. Поскольку на Дельфи все компилируется жестко, сложно перестраивать формат загрузки.
|
|
|
|
Добавлено: Вс апр 18, 2010 19:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: От кросс-ассемблера к кросс-Форту для форт-процессора |
|
|
Цитата: Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора. ничего не понял. Можно не для самых проницательных? Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор
[quote] Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора.[/quote] ничего не понял. Можно не для самых проницательных? Что написано на Дельфи, где оно запущено, что сделано на форте... как это попадает в целевой процессор
|
|
|
|
Добавлено: Вс апр 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[]). Вот примерно на этом оно все и летает.
Решил слегка обобщить разработки по кросс-ассемблеро-форту. Дело в том, что при эксплуатации форт-процессоров для Xilinx стихийно сложилась ситуация, когда основным требованием к кросс-транслятору стало наличие редактора (ну и кнопочек "компилировать", "загрузить"). Соответственно, на первый план вышли решения на Дельфи (и ему подобных) системах разработки, поскольку в них можно достаточно просто положить редактор и кнопочки на форму, ну и как-то привязать к ним несложные действия по компиляции и загрузке. В одной из оболочек даже имел место разбор файла конфигурации системы команд, в котором были перечислены мнемоники и опкоды. Это позволяло, по меньшей мере, добавлять к процессорному ядру вспомогательные полезные команды, не переписывая для этого саму программу. Однако есть ряд операций, которые так просто не делаются: 1) Загрузка конфигурации и последующее общение с процессором Проблема состоит в компилируемом характере программы на Дельфи - все варианты настройки могут появиться только в результате установки каких-то полей, флажков и нажатия кнопок. Невозможность смены формата загрузки без перекомпиляции программы в конце концов заморозило работы по модулю конфигурирования процессора. 2) Смена формата управляющих конструкций и литералов. Все это компилируется отдельно, и этим все сказано.
Почему не было сделано на Форте? Сделано. Только см. выше - поскольку нет встроенного модуля редактора, кросс-транслятор лег мертвым грузом. Хотя общаться с процессором через Форт не в пример удобнее, скриптики пишутся очень быстро.
Как организован транслятор. Сначала компилируется переход "куда-то вперед". Появление слова-метки MAIN: как раз и отвечает на вопрос "куда именно вперед". Такая метка одна, и обрабатывается отдельно. Дальше все достаточно просто - команды берутся из списка, числа - это числа, и есть конструкции управления.
[code]IF ELSE THEN BEGIN AGAIN UNTIL WHILE REPEAT[/code]
В зависимости от наличия в ядре процессора аппаратного стека циклов делается. [code]DO LOOP I[/code]Его же можно сделать и программно, выделив кусок памяти и переменную - указатель глубины. Тактов больше, места меньше. Пока было аппаратно, сейчас склоняюсь к программной реализации. Еще есть VARIABLE и ARRAY, который, вследствие реализации на Дельфи, шел в стиле ARRAY X[] 1024 (а не 1024 ARRAY X[]).
Вот примерно на этом оно все и летает.
|
|
|
|
Добавлено: Вс апр 18, 2010 18:48 |
|
|
|
|