По поводу реализации Forth на AVR

Реконструктор> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. [»]

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

Knightmare> Программирую для камня ATMega128 на C++. Естественно, через какое-то время встал вопрос об эффективном расходе ресурсов. На камне 128K памяти для программ, 4K RAM и 4K - EEPROM.
Knightmare> В погоне за эффективностью наткулся на Forth. О чудо ! такой маленький и такой эффективный. В общем, мне он понравился и я загорелся реализовать Forth на этот камень и прямо в этот камень затолкать компилятор ! НО, есть следующие проблемы: гарвардовская архитектура, (т.е. данные и код - раздельно) и память для программ ограничена на количестов перезаписей - всего 1000 раз и к тому же писать можно только страницами (256 байт). Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ? [»]

Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/

Balancer> Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных. Но соотношение код/данные 128/4 будет в таком случае категорически не в пользу Форта :-/ [»]
Код считывать, конечно можно. Дело в том, что код и данные лежат в разных адресных пространствах. Даже инструкции для считывания и записи для этих пространств - разные, т.е. единого указателя в данной архитектуре нет и камень принципиально не может выполнять инструкции из пространства данных. Хочешь исполнить код - нужно записать его в область кода, и никак по другому. Все это не тяжелые ограничения, а вот ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?

Knightmare> ИМХО настоящие "вилы" - то что записывать в пространство кода можно только по страницам (256 байт) и количество перезаписей равно 1000. [»]

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

Knightmare>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.
И другие процессора есть Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить.
A.P.> ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП. [»]

И в правду 10 000 раз, спасибо (просто помню - что для программирования через загрузчик - хватает, а для рабочих нужд программы - изотрется быстро) B) . Но всеравно - при добавлении нового слова в словарь перезаписывать целую страницу - роскошь.

>>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
61284> А почему кросс-компилер не подходит?
61284> http://claymore.engineer.gvsu.edu/~steriana/Software/ [»]
Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо

Knightmare>>>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM
A.P.>> Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.
Knightmare> И другие процессора есть Но интересно именно для этого камня, уж больно он хорош по рабочим характеристикам, да и недорогой. По поводу внешней памяти - всеравно код записанный в нее нельзя будет исполнить.
[»]
Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?!

Sap> Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Sap> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! [»]
Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно.

Sap>> Угу, посмотри AT91SAM32 - кажется так стоит чуть дороже, но это уже настоящий 16/32 бит ARM7 (55 MIPS @ 50 МГц) со всеми своими наворотами плюс программирование через UART. )) И пиши себе на C++ ))
Sap>> Хотя если честно то это изврат какой-то - для контроллеорв такие языки использовать - не эффективно получается. ЧТо C++, что форт очень и очень не фээективны на данной архитектруре, а уж если учесть какие задачи обычно приходится решать так и вообще не ясно ЗАЧЕМ ВСЁ ЭТО ТУТ ?! [»]
Knightmare> Хех. Если бы дело было только в наворотах. А нужна еще надежность и пригодность для полевых условий , т.е. читай: чем меньше всякой периферии в устройстве - тем оно кошерней. Идеальный случай: камень, питание и развязки для входов/выходов. ATMega приближается к идеальному варианту.
Knightmare> По поводу C++ - не хочу я на нем писать, портабельность требует усилий. И по поводу языков - компиляторы сейчас хорошие делают. Нет особого смысла писать на ассемблере. Ну разве что из любви к искусству, чтобы применить "особые приемы". А вот во времени - запросто можно раз этак в 5 больше потратить. Ну и про переносимость можно забыть, конечно. [»]
Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так
Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы ))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)

Sap>> Насчтё чем меньше перефирии - это бабушка на две сказала. По такой логике нет ничего лучше старого доьброго 8051 или даже 8049, что конечно не так
Knightmare> Ну иногда это действительно так
Sap>> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.
Knightmare> Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?
Sap>> Температурный диапазон и там и там нормальный, а ядро ARM оно гораздо более обкатаное чем AVR. Про хорошие компиляторы ))) Да, если у вас там общая логика работы, то компилятор с оптимизирует, а если нужно подсчёт импульсов с антидребезгом на прерывания >10000 раз в сек сделать, то разница между C ассемблером уже значительное Что конечно не значит, что на ассемблере писаться надо - задачи для ассемблера весьма редкая вещь обычно C всё же за глаза хвататет:)
Knightmare> Более, менее обкатанная - это все неизмеримо. ATMega - тоже заслуженные камни. Про дребезг : с такой частотой (10000) лучше сидеть в основном цикле и считать, а не то вся производительнось уйдет на обработку этого прерывания Мои задачи проще по времени - время реакции на события от 0.1 до 1 секунды. Но нужно запускать код на 4 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование [»]
В основном цикле матиматика с плавающей точкой, протокол обмена и т.п. ))

Реконструктор>> Люди понаделали уже. И не мало. Но я по прежнему упрямо не воспринимаю форт как полноценный язык, близкий к программисткой логике. [»]
Knightmare> Ссылку, пожалуйста, если видел. Не воспримаешь как полноценный язык близкий к программистской логике ? Ну-ну...Не воспринимаю подобное рассуждение, как полноценное и близкое к программистской логике [»]

Тут. Compiler/Forth

Knightmare>Естественно, встает вопрос - как реализовывать компилирующие слова и ассемблер (в Forthе я новичок) и вообще, возможно ли такое сделать для этого камня ?

Я успешно реализовал Форт для смарткарты AtMega163+24c256.
З.Ы. У моего камня 16 кило флеш. Много меньше чем у твоего. Форт занял меньше половины этого объема. И ОЗУ меньше. И все работает на ура. Словарь я разместил отдельно в 24с256, чтобы его стирать когда приложение доделано. Код во флеш. Данные в ОЗУ. Шитый код подпрограммный. Компилирующие слова перезаписывают флеш. Все пучком.

Balancer> Расскажи про разделение кода и данных. Код что, считывать вообще нельзя? Тогда Форт-код придётся хранить в области данных.

Почему нельзя ? У меня в Форте примитив DUMP дампит ОЗУ, [F]DUMP дампит флеш, [E]DUMP дампит внутренний EEPROM, [EE]DUMP дампит внешнюю 24с256. Просто ВСЕ приходится делать в четырех вариантах для разных областей памяти : например иметь пару CREATE DOES> и пару [F]CREATE [F]DOES> , определить четыре вида занесения слова ! [F]! [E]! [EE]! , причем [F]! будет перезаписывать флеш. Нужно только код слов [F]! и [F]C! размешать в области бутлоадера. И тогда перезапись в остальном флеш делается на лету.

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

Временный буфер НЕ НУЖЕН ! Хотя стирать/писать приходится страницами по 256 байт, но временный буфер не нужен. Страницу можно переписать из самой себя, подменив при этом только один байт или слово. Хотя из даташита на AtMega это и не очевидно.

Dem_anywhere> 2 Knightmare
Dem_anywhere> На самом деле в форт-программе кода нет - сплошь данные Код нужен только для базовых слов.

Это если шитый код прямой, косвенный или свернутый. А вот если он подпрограммный, то код есть. Правда выглядящий как rcall rcall rcall rcall ... но все-таки есть.

Balancer>>Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
Можно. Ограничения - имеешь один процессор, который ты будешь сношать постоянной перезаписью флеш во время написания/отладки. А на готовое устройство ставишь нулевый процессор и твое готовое и отлаженное приложение флеш уже сношать не будет. Вот и все ограничения.

Работать с твоим устройством во время отладки придется через терминальную программу и RS-232. Зато отлаживать будет - одно удовольствие. Потому-что через терминал твоим устройством можно будет управлять как хочешь. Включить то, выключить это, запустить такой-то код, посмотреть что в результате получилось в ОЗУ и регистрах. Нашел ошибку - тут-же убрал старый код по FORGET и докомпилировал исправленный, не трогая всего остального. Интерпретатор, компилятор (скорее перекомпилятор на лету) и отладчик на железе в одном флаконе.

Knightmare> Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо
Именно это я и сделал. Форт систему внутри камня. На будущее планирую применять ее не только в смарт-картах и сделать ее многозадачной методом Раунд Робин. Но это пока в проекте.

Balancer>>>Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
amForth не то?

P.S. на fforum.winglion.ru ещё есть разработка кросс компилятора для AVR Очередной AVRForth
и страничка автора oco