Kopa

Врать не буду т.к. ответ достаточно очевиден ОЗУ (оперативное запоминающее устройство). Но при включении характер значений в ячейах памяти, если не записывать в них ничего должен носить определённый характер, предположу определяемый технологией изготовления. P.S. На время отключения питания поставьте батарейку и контролируйте её разряженность.

А есть ли какие "следы" в i-nete этих проектов? (хоть намёком) Не без этого:) (это не первый Вы подметили)

Это только привычки (мозга) уже приобретённого опыта. Например, скажите китайцам, что их язык полное "г.." и цивилизацию, вообще с ним не построишь:) (да качественного свободного инструментария может не хватать, но для Форта это не такая "глобальная" проблема, а профессионалы,при необходимости, могут и купить себе коммерческие средства разработки) Из своих "пристрастий" долго "подлавливаю" себя на том, что ассемблерные команды для меня привычнее в "классической" записи, а не Фортовском стиле, но при этом есть понимание, что идёт потеря в гибкости и возможностях. (потеря небольшая т.к. ассемблерная команда достаточно "мелкое" понятие). Поэтому использую, хоть и классического вида ассемблерные команды, но с расширенными возможностями по повышению уровня асемблера в Фортовском стиле и управлении Фортом всей дополнительной макро структурой. В терминале для повышения эффективности работы, желательно иметь функционал текстового редактора. P.S. Ваш пост на "изиэлектронике" очень большой, пространный, но "абсолютно" пустой. (с моей точки зрения). Кто осознанно использует Форт и решает на нём мелкие и не очень задачи, предположу что, наверное имеют какие то критерии выбора для используемых иструментов? Остальной "оффтопик" поcта мне понятен и близок. Все мы "заложники" искусственно выстроенных и принятых на веру "принципов", но хорошо бы эти принципы понять и объяснить и подумать что действительно важно, а что наносное. Форт уже (или ещё) не Ваш путь, то это не повод притягивания своего опыта, для обоснования "единственно" правильного и беспорочнего. Прочитал недавно, что на советских Агатах, в отладчик кода, Форт "внедряли" в виде sys драйвера и узнал о том, что такие компьютеры были:) Истинные Форт джедаи следуют своему пути:) и занимают призовые места на конкурсе производителя. (не считайте рекламным ходом) PbjTech.com (ссылку вроде уже приводил) Заблуждениям не счесть числа :1111493779: Форт системе, как языковому средству, "глубоко индеферентно" где и как будут строить выполняемый код. Эти моменты интересны разработчику конкретной Форт системы (в применении к контроллерам) для улучшения эргонометрических характеристик. На этапе отладки небольших слов, наверное удобно использовать ОЗУ для их размещения, а если программа при старте грузится из флеш в озу и работает, то зачем тогда использовать флеш для разработки, а не для заливки окончательной версии. Сама же программа на Форт, как это может показаться не парадоксальным, расходует ОЗУ в очень небольших размерах. (количество же глобальных переменных "катастрофически" мало приходится использовать, только в силу "непреодолимых" обcтоятельств) Добавьте в уровень ядра возможность дописывать и "хакать" флеш программу и станет значительно лучше, но не говорите об этом пользователю данного устройства или закрывайте канал на всякий случай. (что бы чего не вышло, и был контроль над действиями пользователя), а "ключевые" процедуры определите с возможностью менять вектор расположения выполняемого ими кода. Возможно я "мамонт", но мне никогда не нравился цикл ("ввод текста -> "длительная" компиляция -> возможнсть пошаговой отладки " кода функции-> в начало) сверясь с отладчиком в правильности использования возможностей конкретного языкового средства. Наверное, всё таки умеет делать "классическую" форт компиляцию. Для данного "осязаемого" использования - этого достаточно, но можно использовать и другие варианты. Всё это уже придумано за нас. Мы только можем развивать или нет это направление и использовать или нет "придуманные" подходы. +1 Мне это подходит лишь бы была возможность "простой" заливки кода без необходимости покупать отладчик. :cranky:

А в этот германский репозитарий не заглядывали? Немецкая и голандские Форт группы одни из наиболее активных и "отметились" неплохими Форт системами, на их сайте есть и Wiki наполнение. P.S. Например для генерация Форт кода amForth системы для AVR используется тулза g4.fs запускаемая из под gforth и wn32forth

Насколько "глубоко" может быть внедрён, например, в компиляторы, трансляторы, интерпритаторы, треба пробовать. т.к. ещё нет "открытых" и "свободных" оптимизаторов Форт кода и определения какой уровень "абстрагирования" необходимо генерировать для дальнейших вариантов его использования. Читать статьи интересно и постепенно первоначальные знания предмета дополняется новыми гранями понимания. Обсуждаемую конструкцию IF ... ELSE ... THEN можно генерировать и как описано в статье не привязываясь к необходимости учитывать применимость команд длинного/короткого перехода при статическом построении кода (такое есть в динамических стековых языках), только куда "выкладывать" адреса перехода, чтобы они "не мешали" остальному Форт коду (на стеке данных им не очень место, на стек возвратов тоже вроде ни к чему) а так сами слова IF ELSE THEN - это слова немедленного выполнения и они сами знают как строить команды перехода для применяемого "железа" Учитывая это процедуры кода на ассемблере принимают/отдают данные через стек данных. (какие аппаратные возможностиь механизма поддержки двух стеков и где они будут распологаться можно выбирать на своё усмотрение) такие процедуры легко тестировать локально, а запрограммированы они могут быть как на ассемблере, си или форте.

Ага, что только и какие подходы не используют профессионалы с использованием Форт. Например, что бы "увеличить" прозрачность и гибкость создания кода есть один из вариантов поверх TCL, JAVA ... сделать вариант "Форт IDE" и генерировать код этих языков из Форт ориентированного синтаксиса/семантики используя возможности целевых языков. Forth to TCL A Forth to Java Compiler Простенько и со вкусом. P.S. Что тут ещё можно сказать:) Форт многогранен. (из сериала 1000 и один способ применения Форт)

"Нежданно-негаданно" Форт тематика пополнилась ещё одной "игрушечной" темой предположу что,близкой к контроллерам и может "приглянуться" местной embedded "тусовке". Forth в игре, или Red Power 2 Control для MineCraft P.S. Виртульные технологические миры всё ближе и ближе:) дальше не развёртываю тематику складывающихся моментов...( У кого то детки играют в эту игру?)

.

Думаете нет? Может sourceforge.net "пошерстить" по данному предмету. Дракон только и пиарится авторами на выделенном подфоруме http://forum.oberoncore.ru Проблема думаю немного шире - в осмыслении эффективного пользовательского интерфейса при создании подобных средств и undersand C/C++ уверен выведет кучу всевозможных диаграмм не выдав дополнительной семантической информации по дизайну функциональным решений реализованных в диаграммах (так называемую мета информацию исходя на основе которой создавалось конкретное воплощённое решение) P.S. Есть проект Thyrd эксперимента в озвученном вопросе, а насколько перспективен или нет и в какой степени предложенный подход покажет время. Самому данная тема интересна, но понимания ещё не сложилось и пока видится что текстовый ввод пока наиболее эргономичен при создании прораммного кода. И сказано было им, что придёте вы к плиточным графическим интерфейсам или накрайняк табличным :)

Форт при реализации через шитый код даже не использовал инструкцию RET число, а сразу передавал управление (NEXT), на следущее слово в цепочке. давая возможность программисту решить кто будет и как обрабатывать "мусор"

т.е. сначала была CISC, но микропрограмма не давала "чудесным" способом уменьшить растактовку? и RISC решило эту проблему? (вспоминая тормоза древнего 51-го ядра и быстый AVR :smile3009:, но при этом существовала MISC которая обходила, как минимум CISC архитектуру) А вспомнив законы диалектики, что если где то прибыло, то в другом месте убыло всё встает на место т.к. и в цирке все фокусы объяснимы. P.S. Всю описываему Вами цепочку выполнения кода 0-операндной машины (не вдаваясь в её корректность) можно ускорить если прочитать эти команды в группе, как обычную CISC команду на выполнение, потеряв частично в энергоэффективности архитектуры) как и проиcходит, в общем то, при сравнении AVR и MSP430 (к тому же при проектировании MSP430 инжнеры оказались гораздо "изворотливее" в принятых решениях) :) Ага передаём между функциями указатель на данные, а сами данные "чудесным" способом обрабатываются минуя регистры:) Правильно я это понял :crying: И прочие нормальные языки больше не используют стек для передачи параметров? Может и к лучшему? Накой он это вообще стек нам сдался И это правда. Залихватский порядок - это ни что иное как упорядочивание "трафика" прохождения данных между словами (подпрограммами). Но стек не идеальное средство решения этого т.к. требуются всё же дополнительные команды вносящие некоторый "мусор" в код т.к. и "трассировка" вручную (головой) не являтся гарантом правильности выстраивания потока данных (может со временем только это навык приобретаетcя?)

Похвальное желание "закопать" Форт поглубже. Есть, например, и такие экспериментальные площадки разработки http://thyrd.org Форт всегда присутствовал и присутствует на нише встроенных приложений. (если кто то не в курсе) P.S. Хenia. Предлагаю Вам написать корректирующий пост на весь "пафос" высказанный постом выше. (короче полный пипец и суши вёсла) C описываемыми Вами перспективами по оперированию информацией можно стать "инвалидом" программерского труда, а ситуация с компиляторами которые только и занимаются в RISK архитектуре "считыванием" информации для ппрограмм в "мусорные" регисты вообще плачевна. (поэтому возможно стековый код и "уделывал" Си регистровую оптимизацию компиляторами (по обсуждению с RSDN) до появления Pentium процессоров?) Прозвучавшее слово обязательный забудьте в применении к Форт (там больше правит анархия программиста разработчика, который может установить свои "правила игры" исходя из ситуации) и не смешивайти языковые возможности Форта и результирующий нативный код который будет выполняться на целевом процессоре. По Вашему Java, MSIL байт код (в основе стековая модель) вообще один сплошной тормоз?

Весь пост, пока нет желания комментировать (слишком длино написано и бросающееся в глаза недостаточное владение материалом описываемого предмета (без оскорблений откуда "почерпнули" информацию?) Одна только констатация, что стек (служит для хранения также адресов возвратов характеризует уровень знания темы (хотя на стеке данных и могут появляться при необходимости адреса кода слов, но в Форте есть ещё стек возвратов (управления) где и "осядают" адреса возврата и например управляющие переменные циклов) + есть ещё механизм локальных именованных переменных(если уж совсем невмоготу) При реализации модели САLL вызовов слов они не прерывается операторами PUSH. если специально не вынесено действие PUSH при построении кода вне CALL (это модель реализации Форта называется подпрограмный шитый код, есть и другие модели вплоть до генерации нативного кода см.например SP-FORTH) Попутный вопрос - вы отлаживаете вручную Си код на уровне ассемблерных команд процессора? Искривление сознания приводит к тому, что вклчается и "проcтранственое" мышление 10 BEGIN ... бла бла бла 1- ?DUP UNTIL (инкрементируется в цикле и служит счётчиком число положенное в начале цикла 10 не куда не деваясь, как это не страшно может выглядеть) P.S. Как то особо и не замечаю, что "думы" о стеке занимают львинную долю создания кода (больше проблем с пониманием архитектуры решения самой задачи, почему то). В особо мелких и "извращённых" словах это наверное так и есть. (примеры пока не привожу, но понимаю что Си код в этом случае ничем не выглядит лучше - таже "мозгодробилка", только вид сбоку.) Например кое что проясняет обсуждение на RSDN Почему Форт никогда не был популярен среди мэйнстримовых разработчиков (гораздо информативнее чтиво) Вряд ли это действенный метод. Как например такой пример Qt-Forth - это засчитывается? :rolleyes: Чаще всего интересует вопрос - а смогу ли я на данном средстве-языке-инструментарии решить 90% типовых задач не прилагая "особых" усилий? Ответ в отношении Форта может звучать так - нет т.к. на нём не решены какие то прототипы из этих 90% задач, а смогу ли, при наличии терпения и желания - да. Например сейчас решил "добить" частично решённую ранее задачу - компилятор из Си в Форт. Зачем? Скажу просто. например чтобы було:) а дальше видно будет. можно, наверное, использовать для переоса Си кода в Форт вариант или иметь вариант интерактивного Си со средой выполнения и например оптимизации Форт... Если С/С++ врос в Вас "всеми корнями", то может быть Форт и не рассматривать. Почему нельзя? На С/C++ данное изделие (Форт в контроллере) тоже сделано много реализаций. P.S. Пока ленюсь и не программирую (работа тоже не с программированием) есть время вести дискуссию.

+

Сейчас, если посмотреть на определение "мелкий контроллер" критерии у производителя несколько изменились и даже используя встроенный Форт (современные Форт системы, чаще всего компилируемые и с убиранием избыточного кода) можно этим контроллером решить большое количество "всевозможных" задач. Да необычен, но востребован или невостребован это критерий относительный если посмотреть на применимость в индустрии. Вы, Я применяете в своей практике тогда почему делать вывод, что это пригодно "только" для Вас или меня? Удачный опыт это хороший критерий дальнейшего использования. Как показывает практика, если задачу можно решить с помощью "тощего" контроллера, то зачем "переплачивать"? Но для меня и не только - это, прежде всего, эффективное удобное средство в деле "программинга" (есть конечно и "костыли"), а на определённое мнение кем то о неактуальности мне как бы это помягче выразиться...:) Если бы это было так, как Вы описываете, то например можно было сделать вывод, что и реализация больших программ даже на ассемблере не приводит к компактности кода? Форт система в контроллере - это один из языковых базисов (подходов) для решения необходимой задачи, а "уменьшить" результирующее решение или взять контроллер "побольше","побыстрее" или реализовать, например в ПЛИС, это уже вторично. Но реализации например BIOS-а на Форте для PC и самих Форт систем может служить некоторым показателем компактности решений на идеях заложенных в язык. Сейчас выбор всевозможных интересных по возможностям Форт и Форто подобных систем для контроллеров и настольных ПК очень большой (просто огромный и есть даже некоторый переизбыток), можно использовать популярные Форт системы, или подобрать по своему усмотрению и уже наверное неактуально изобретать свой велосипед, хотя "неопробованные" идеи ещё остались для реализации.(как бы намёк) И не только. P.S. Помимо Форта на базовой идеи явного использования и доступности стека для программиста (в Форте есть и другие идеи) построено и появляется (например Factor) другие языки из серии конкатенавных (цепочечных). Не секрет, что в UNIX системах мощный подход для решения задач "сцепление" вход/выход разных программ.

Предлагаю для ознакомления один из ресурсов где есть "определённое" обсуждение данного и смежных вопросов по вашей теме Форт форум Читайте, обсуждайте если сочтёте полезным экспериментируйте и делайте выводы.

Хотелось купить в ближайшем магазине промэлектроники (с "относительно" небольшой, для "разовой" покупки переплатой, смотрел ~249р), но возможно лчше сделать заказ у производителя. Спасибо. Хорошая новость и статья, и обозначен интерес к "развёртыванию" тематики в данном направлении. На Форте, вроде, в детском кружке при ЦКБ "Родник" делали робо-пса. (Подумал интересно, наверное сделать и робо-черепашку) P.S. Примерно с этого момента Похожие эксперименты на Форте для AVR на робофоруме (автор Chu зарегистрирован и на местном форуме) Форт может составить серьёную конкуренцию текущему Ардуин направлению и снять некую "элитарность" в умении программирования. P.S. А комментарии в коде ( // ) специально обозначены в Си варианте? (а не \ принятому в Форт) Ещё, вначале, можно показать использование булевой алгебры изменив систему счисления на двоичную, 2 BASE ! и как изменяются биты в ячейках (CELL) при использовании операций AND OR ХОR т.к. целевая аудитория читателей может быть разная. При использовании дополнительного интерфейса отладки, например в IDE (комфортная скорость, в моём случае, была в пределах 38кбит./с при перезаливке целевого образа программы в контроллере во флеш или ОЗУ) Самих статей может быть очень много и получится неплохой учебник по Форт применению. Интересно как будет изменяться ("прогрессировать") понимание возможностей применения Форт в МК и не только у "массового" читателя:)

Десятикратно вряд ли и вряд ли фатальные, но наверное будут при использовании компактного шитогого кода. При этом использование ассемблера в Форте по реультатам профилирования никто не запрещает использовать. Следуя Вашей логике место применения MSP430 должно быть ограничено автономными датчиками, приборами аналогами цифровых мультиметров-тестеров и не как не управление "железом" т.к. тогда условно сверх-низкое потребление не будет востребовано в полной мере. (У MISC архитектуры, кстати, ещё меньшее потребление!!!) P.S. В НГУ на базе MSP430 проектировали проект сенсорного узла с использованием форт подхода "Метеор-Форт". Статья по результатам для ознакомления доступна.

Сложностей нет. Можно использовать имеющиеся знания и библиотеки (например лексический анализатор). Есть популярный курс по построению компилятора от Креншоу с кодом на Форт (начальный на Pascal). А если остановится на Форт ориентированном синаксисе, то это даже не вопрос. "куча" материалов и ссылок на "любой вкус и цвет" представлена на русскоязычном форуме по Форт тематике http://fforum.winglion.ru.Начав изучать разные реализации можно определиться со своими "пристрастиями":) Есть и на ВАТ файле форт подобные реализации "Менее грамотные" специалисты, что очень хорошо, имеют возможность реализовывать свои знания в программном коде! без необходимости начального углублённого изучения "сложного" каркаса языка и возможностей создания программ с помощью него. Форт осваивается достаточно быстро. Из кирпичиков-форт слов можно построить достаточно грандиозные "здания". Форт первый расширемый конкатенавный язык, но есть и другие его "потомки" И слов, и строк, и выражений т.к. Форт язык достаточно локаничен и не "перегружает" количеством кода внимание разработчика, пользователя, но реализации каких то алгоритмов могут "казаться" абсолютно не читаемыми и сравнимы, отчасти, с реализациями на ассемблере. Код программы минимальный в классическом варианте из-за использования интерпритатора "адресных ссылок" (т.е. фактически ассемблер виртуального стекового процессора с фиксированной длиной команд, например 16, 8 бит) Компактность стековой арифметики использовалась в программируемых калькулятарах. (контроллеры могут быть самыми не ресурсоёмкими, если задаче хватает времени для своего выполнения.) Сам Форт не предаставляет в стандарте парралелизм, но и никак не ограничивает расширение "себя" необходимыми возможностями. Учитывая хорошую реентерабельность стекового кода можно создавать требуемые решения вплоть до использования в ассемблере Форта. (ассемблер тоже часто одно из расширений Форта с зарезервированными словами CODE ... ENDCODE).Часто, в Форте используют реализацию кооперативной мультизадачности, а если Форт выполняется в рамках заданной ОСИ то используются её сервисы (например с использованием потоков в PC версиях) Есть и проекты Форт-осей, но "продвинутость" их неочевидна. Есть и многоядерный ассинхронный Форт контроллер (пиковая частота переключений в ядре где-то 700МГц при работе ядра, асинхронизм 144 ядер очень сильно "рагружает" потребление ) На SP-Forth реализованы eserv и nncron программы. По вашему вопросу посмотрите nncron и почитайте форум на её сайте. На sourceforge.net есть н-ое количество Форт проектов прикладного характера. P.S. Пожалуй пока так. Остальные пояснения по мере прояснения Форт тематики при изучении. На MSP430 пока не работал с Фортом (нет железки), но Форт для PDP-11 процессора "юзал" интенсивно, вплоть до симуляции программно данного процессора. поэтому и интересна данная тема. (При этом можно использовать самые недорогие контроллерные "камни")

В этом есть некоторая правда, но намного меньше чем это может представляться. По своему опыту "переделывания" некоторых Форт проектов трудности в пределах нормального восприятия. Обычно сразу выделяется тот "кусок" кода который необходимо изменить P.S. Создание программ на Форте может казаться "магией", но не нужно забывать, что "кажущаяся" необычность Форт или другого малоизвестного инструментального языка - это лишь первый и достаточно быстро преодаливаемый барьер. (вся программерская работа происходит в "голове" наиболее эффективном средстве к комбинаторной деятельности + простой единообразный синтаксис и мощная внутренняя семантическая модель языкового средства с быстрым получением результата - это всё мощные стимулы для активизации работы мозга) Посмотрите ещё на новые конкатенавные языки и в частности Factor:), You agree with it

Ночные сборки У меня сейчас от 29 сентября 2012г. Очередной релиз. похоже ещё "недопилили" и наверное существуют разные проблемы. Опциональные пакеты Ссылки на софт OsDrawer.net haikuware.com zeta-games.om bebits.com Кто разберётся какая "учебная политика" у разных университетов? P.S. В своё время мелкософт похоже посодействовал для перекрытия "кислорода" BeOS

По информации Гибридное (модифицированное микроядро) Стек TСP похоже в ядре. P.S. Столкнулся с какой то ошибкой (svn genode архив c sourceforge через браузер в Haiku OS не может скачаться циклит и перезапускает загрузку идентифицируя неправильную длину скачиваемого файла:) , а на Git скачался.

Для Haiku OS уже есть порт QT со всеми вытекающими последствиями. (Java 1.4.2 тоже вроде портирована в каком то варианте) P.S. Хочется оценить есть ли другие открытые рабочие "легковесные" варианты Осей достойные внимания из альтернатив Win, Linux BeOS была, всё же закрытой операционной системой Git исходники на сервисе google доступны через zip образ ~170Mb и столько же GCC инструментарий для сборки (всё ли открыто? возможно есть закрытые исходники для участников разработки) @"Если нет разницы, зачем платить больше?":) Или всё же есть? (кроме необходимости устанавливать, переносить и обживать какой то софт самостоятельно) В чём могут быть "грабли"? Есть предположение, что Haiku изначально "лучше" спроектирована т.к. разрабатывалась гораздо позже. Есть также "надежда", что освоение архитектуры Haiku более простое,чем Linuх (Win даже не обсуждаю) Русские пользователи BeOS в i-netе года 3-4назад прекратили её обсуждать (по дате сообщений на одном из форумов) Android на моём PC не запустился и стоит ли с ним "заморачиваться" на PC в текущих реалиях.

Хотелось бы использовать не только для "повседневyных" задач, но и как возможность, например, создавать "простой" софт для своих "задумок" в рамках "простой" ОСИ. О безопасности данной Оси трудно судить, но думаю и существующие "песочницы" не безопасны. (запускаю, кстати, Haiku на образе Vrtuall USB HDD с отключением в BIOS, родного диска - сохраняя его ресурс. Слетит переустановлю за ~5минут или запущу LiveCD хочется "максимально" безопасный i-net, в первую очередь или чтоб "гадости" оcтавались в "песочнице") P.S. Puppy Linuх, периодически запускал,( "не впечатлился" хотя размер там ~70Мб был)

Разве было сказано что существует готовый 100% порт на какой то конкретный ARM? (портирование её- настоящее продолжительное незаконченное действие:) на PC тоже ещё не все "косяки" убрали и что с этого? Применять уже нельзя? Мне пока, что нравится то что есть, но "заморочки" и в этой системе наверняка есть. P.S. Интересны "объективные" (субъективные) мнения, а не придирки к "недопонятой" информации.:) Выключается данная ОС за 2-3секунды. Слабые процессоры M68 и др отмечены в репозитарии исходного кода, а что сделано не выяснял.