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

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

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

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

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

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 перезаписей- не предел, флэш данных живёт и дольше. Негарантированно, конечно ж.

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

А почему кросс-компилер не подходит?

Knightmare>На камне 128K памяти для программ, 4K RAM и 4K - EEPROM

Если нехватает и того, и другого и третьего - лучше ищи другой процессор. Обычно нехватает ОЗУ, а это лечится прикручиванием к ATMega внешней SRAM — до 64Кбайт.

ЗЫ. Flash в ATMega-ах гарантировано перезаписывается минимум 10000 раз (по даташиту), ЕМНИП.

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

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

>>> Так вот вопрос - можно ли организовать для такой архитектуры Forth-машину с компилирующими словами и какие будут ограничения ?
61284> А почему кросс-компилер не подходит?
61284> Andrew Sterian [»]
Нужно иметь компилятор внутри камня. Поэтому кросс-компилер не подходит. За ссылку - большое спасибо

2 Knightmare
На самом деле в форт-программе кода нет - сплошь данные Код нужен только для базовых слов.
И вообще, можешь сделать один из битов адреса слова флагом, указывающим в какой памяти надо работать

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, что конечно не так
Ну иногда это действительно так
Sap> Или явас не правильно понял ? у того ARMа и память и все переферия на кристалле, так что из обвязки только кварц и питание. ATMega вещь не плохая, но со снижением цен на на ARMы смысла в ней всё меньше - при той же цене производительность в разы меньше. На ATMELе уже висят пресс-редлизы о сворачивании линейки MEGA.

Вроде ARMы делают все кому не лень. Не подскажешь ссылку на даташит ARMа у которого есть встроенная флешка ?

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

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 типах платформ и сколько их будет дальше - не понятно. Т.е. желаю минимизировать расходы на портирование [»]
В основном цикле матиматика с плавающей точкой, протокол обмена и т.п. ))

Форт для AVR имеется на http://www.tinyboot.com/ff302.zip

Мне он очень пригодился для создания форта для PDP-11
переработка минимальная для любого контроллера. В качестве примера
мою адаптацию для PDP-11 можно посмотреть на

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

Тут. Compiler/Forth