Господа!
А заметили ли Вы, что программирование на асме - в современном смысле слова это не программирование. Лично я, владея огромным уже количеством ассемблеров, программистом себя не считаю.
Призываю всех не приветствовать впредь бессмыленную полемику не тему "Что лучше - С или асм"

Просмотрел указанную Вами ветку еще раз. Там ни автор ни его оппоненты не остановились на том, что алгоритм, выраженный в терминах языка, представляет собой совокупность автоматов. Т. е. процесс - это и есть элементарный автомат. Вся программа - это их совокупность.
Насчет санскрита - тут я с Вами согласен на все 100% - есть определенные правила и их надо выполнять. Но у автора есть и нормальный вариант.
Позволю себе не согласиться с тем, что этот язык нельзя притянуть к МК. Если рассматривать "чистое" железо МК как данность, некую среду, то почему бы и нет? Чем отличается (в логическом плане) железо МК от железа какого-нибудь промышленного агрегата. Те же регистры, биты, входы, выходы. На самом деле очень похоже.
К сожалению, автор делает акцент именно на пром. автоматику. Там ему однозначно ничего не светит...

Посмотрел ЧаВО - действительно упоминается. Но в доке только русские буквы. На сайте слить кроме доки нечего.

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

Сообщение отредактировал Прохожий - Oct 7 2007, 18:10

)) Регулярно поднимаются вопросы о борьбе с выравниванием и упаковкой структур - классика 8-D

Нет таких! НЕТУ!!!
Для меня ЯВУ - средство автоматизации труда программиста (извините за банальность). И вот, дебильные макросредства всех асмов, которые не содержат IRP, IRPC, REPT и т.д. надо компенсировать чем-то. А на "С" пишутся именно аппаратно - независимые вещи.
З.Ы. И не дергайте вы ногами в Си

Сообщение отредактировал _Pasha - Oct 7 2007, 18:29

[attachment=14256:attachment] - вот методичка для студентов, простите - это без всяких намеков .
Просто это единственное место, где есть английская нотация - в конце опуса.
Но я лично имел ввиду Рефлекс просто, как концепцию программирования в real-time.
На мой взгляд, ему действительно далеко до реального заместителя ОС при реализации крупных проектов на навороченном МК.
А вот для микро- и мини- проектов - было бы неплохо. Правда, для этого ему опять же кое чего не хватает - инкапсуляции смены состояния процесса непосредственно в обработчике прерывания, например. Опять же непонятно наличие ярко выраженных временнЫх переменных, сведенных в отдельное понятие ТАЙМАУТа. В МЭК 61131-3 - это все как-то более логично.
И последнее, применение языка затрудняет полное отсутствие компиляторов на известные платформы типа AVR, PIC, ARM. Боюсь, что до этого не дойдет никогда...


Да не кричите Вы так громко . Объясните, лучше, чего нету. А то я оглох и ничего не понял...


Аппаратно независимые вещи пишутся в стандартах и учебниках на различных языках. А уж на чем они будут воспроизведены в коде - дело десятое. К стати, есть еще масса способов обеспечения абсолютной переносимости кода, в том числе и аппаратно-программные. Тот же МЭК 61131-3 для промавтоматики, к примеру. Причем это все реально работает лет 30.


Нет буду. Назло...

спасибо, взглянул. (и у меня, оказывается, в свалке загруженного оно уже было) Если заменить FOR ALL на public (использую #define __public extern // с подчеркиваниями чтоб с плюсами не дралось если что), а FOR LOCAL - на private (использую #define __private static), то замечу, что достаточно давно подобные конструкции (TIMEOUT и т.п.) использую и языком не называю (придумывал не я, но использую). С первого взгляда типов для "защищенных" (или чего там надо?) переменных не заметил

А мне лично локальные переменные не нравятся (видимо не умею их готовить ). Потому как приводят к излишней возне со стеком. Хотя, использую их достаточно часто.
Насчет TIMEOUT - отдельная тема. Чем таким временнЫе переменные заслужили отдельного понятия в виде функций типа delay(Time) или TIMEOUT(Time)?
А основная причина, по которой я упоминал Рефлекс, в том, что там отражена достаточно близкая мне модель программирования, позволяющая обеспечить многозадачность без привлечения ОС даже на языках низкого уровня.


Автор при личной переписке утверждал, что это дело у него формализовано и инкапсулировано внутрь компилятора. Если это в реальности так, что косвенно подтверждается рядом реализованных автором проектов, то это неплохо.

Хочу предложить посмотреть на всё это с другой стороны.

То есть если рассматривать такой аспект, что использование СИ или другого ЯВУ предполагает появление новых для программиста ошибок, то с этим можно согласится. Это и ошибки преобразования типа, и ошибки связанные с использованием указателей, и ошибки связанные с порядком следования переменных в операторе и т.д. Но не надо забывать, что исчезают некоторые ошибки связанные с использованием АСМа. Это различные инициализации, ошибки связанные с совместным использованием регистров, ошибки связанные с громоздкостью программы и невозможности охватить её в рамках одного экрана и т.д.

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

С другой стороны длина аналогичной программы на СИ меньше. И это объективно. От этого никуда не уйдёшь. Переменные - более обособлены. Программа более структурирована. В связи с этим время отладки будет меньше. Я беру средне статистический случай. Можно сделать трудновылавливаемую ошибку в любой программе на любом языке. В среднем время отладки будет меньше. Что и подтверждает практика.


По поводу портирования мне кажется всё сказано. Даже если на Си она будет трудно портируема, то на АСМе она вообще не будет портируема. Здесь просто нет альтернативы. Как минимум пока нет.

Ой, не разобрался видно я в этом Рефлексе, ну да и ладно.
Насчёт многозадачности и ОС - я бы это обсуждал в соответствующей теме соответствующего раздела. Но пару слов скажу. Вспомним ДОС и появление Виндовс - во главу угла при появлении Виндовс ставились удобство работы (красота-масота и т.п.) и МНОГОЗАДАЧНОСТЬ. Но тот же ДОС обслуживал (и много ещё где живёт и обслуживает) несколько ПРОЦЕССОВ (ввод-вывод, распределение памяти и т.д.) и аж одну ЗАДАЧУ пользователя. Такой задачей (но крутой) была и Windows3.1. "Обычные" ОС для встраиваемых решений на микроконтроллерах, например, uCOSII, предлагают незамысловатое упрощение - и процессы и задачи становятся равнозначными и сливаются в одно - task - всё-таки в задачу (зато система называется многозадачной). Оно вроде и пофиг, но всё-таки есть нюансы. Особенно различия заметны во временной базе задач/процессов. (это отдельная тема).
Если Вам нужно только переключение задач, то это одно. Если одна задача может "неукоснительно рекомендовать" другой выйти из неактивного состояния, то уже возникают вопросы (когда будет доставлена рекомендация, ограничен ли срок её жизни, как она соотносится с другими рекомендациями, и когда она начнёт выполняться) (т.е. шедулер может понадобиться), но если нужно общение между задачами/процессами, то получится ОС. Как бы Вы реку не назвали, течь от этого она не перестанет. Но в то же время определений ОС много, какое верное - не знаю

Да оно то и не надо. Просто пример...


А если Вы изначально при проектировании оперируете такими понятиями как "процесс", "обмен данными между процессами", "время реакции", "защищенные данные"? То, что вы пишете уже изначально работает как ОС. Вопрос нужна ли она в этом случае? Не окажутся ли такие понятия, как мьютекс, семафор, очередь задач, контекст задачи, тот же шедулер немного лишними?
Ладно, действительно не в тему...

Вот и ответ на все ваши вопросы выше. У вас появился собственный ОС, вы прекрасно знаете как он работает, распространите его на несколько платформ и пишите под него легко переносимые "процессы". Портируемость как для Вас будет обеспечена. Без доли иронии.

Почти шепотом:
IAR большой, ему видней...
На фоне дебилизации ассемблеров в "С" портируются жизненно-важные вещи типа TCP/IP стека, IEEE754, библиотеки поддержки LCD и прочее.
После чего очевидное преимущество в скорости разработки привлекает новых пользователей. Проблема остается. Проблема в том, что детерминированный результат получается разными способами.
Теория назначений, способная давать решение проблемы, до сих пор развивается.

Зримая аналогия дилеммы ЯВУ-АСМ - это автоматическая трассировка платы. Совершенно неприемлема для 80% устройств.

Абстракции...
JMP, CALL,ADD, XOR(EOR), RET(RETURN), NOP в конце концов, есть во всех контроллерах. Так на хрена же в одном случае пишется RJMP, а в другом GOTO, JP, JMP ? Получается, что из-за отсутствия мета-мнемоник мы ищем абстракции, перепрыгивая довольно солидный пласт абстракций, содержащийся в кодах операций и операндах?

Еще один прикол - появление псевдо-сишных директив в ассемблерах. Не менее смешно, чем написать TCCR1B+=0x01; и думать, что таймер запустится за 3 цикла.

Целесообразность портирования. Например умножение двух signed int на меге - 19 тактов, на пике -35 . Смысл плавно умирает. Но, если не знать этого - все зашибись!

Думаю, что ОС должны вырастать из схемы целевого устройства. Тогда и весь бардак сойдет на нет. На ОС возложить (писать на асме):
1. Инициализацию всего хозяйства,
2. Все прерывания,
3. Поддерживаемый набор функций через таблицы адресов (как продолжение таблицы векторов прерываний),
4. Сами базовые функции. Конечно, чем меньше их, тем лучше
5. Даже арифметику. Как-то заглянул в листинг Mikroelectronika Pascal for dsPIC. Написал (Паскаль):
var A,B,C:real;
begin
B:= 1.0; A:= 3.1415926; C:= A+B+ B*B;
end.
***** Ё-моё, какая там баранина !!! *****
Ничего DSP-шного не используется. Куча кода в режиме совместимости с PIC18. Вот так...

Сообщение отредактировал _Pasha - Oct 8 2007, 00:09

Дело в том, что эти понятия формализовано описывают некие механизмы и объекты. Яркий случай - очередь задач. Очередь - объект, явно описанный или неявно, а выполнение последовательности задач (каждой задачи из очереди) - механизм, в зависимости от описания объекта выполняющийся по-разному (что первично, яйцо или курица - отдельный вопрос). Изменение порядка и состава очереди также механизм. Если он явный, то выполняется планировщиком (по причине - некоему событию/сообщению) или/и сопрограммой. И т.д.
Ну и русский язык вытеснен в этой специфической области за неимением собственных устоявшихся терминов/понятий;(
А врачи говорят на латыни...