Портируемый код - миф или реальность? Опции

[CD_Eater]

Очень хочется покидать камушки в огород тех, кто пишет на Си и верит в миф о лёгком портировании кода. Нет возражающих? Ну, тогда начну.

Недавно на телесисях была поучительная ветка. Вот она
http://telesys.ru/wwwboards/mcontrol/1809/...es/173406.shtml
Прочитайте её, интересно.

Прочитали? Тогда продолжим.
Это почти классический пример - ЯВУ скрыл от программиста важнейшую деталь реализации: с виду атомарная инструкция "PORTB ^= 1" на самом деле оказалась неатомарной, и автор совершенно не ожидал, что здесь придётся заботиться о корректном доступе к общему ресурсу (порту B ) в многопоточной среде (фоновая задача + обработчик прерывания). Если бы человек писал на ассемблере, он бы легко увидел эту потенциальную "борьбу за ресурс" и принял бы обычные в таких случаях меры. Не исключено (хотя маловероятно), что автор предвидел эту возможную угрозу, но понадеялся, что компилятор достаточно умный и автоматически выберет самый оптимальный вариант реализации, то есть, "PINB = 1", сделав операцию атомарной (разумеется, компилятор сделал бы это из соображений оптимизации по скорости/размеру кода, а не из заботы об атомарности). Для нас важно одно: простые и однозначные с виду операции ЯВУ могут (в зависимости от компилятора и железа) оказаться вовсе не такими простыми и однозначными.

Теперь представьте такую ситуацию. У Вас есть Сишный исходник и Вы портируете код проекта на другой МК. Разные не только МК, но и компиляторы. Предположим, что в проекте встречается ситация, аналогичная приведённой выше: в фоновой задаче и в обработчике прерывания используется нечто вроде "PORTB ^= 1", но в предыдущей реализации (при старом МК и старом компиляторе) эта операция была атомарной, а в новой реализации (на новом МК и новом компиляторе) перестала быть атомарной. Вопрос: заметите ли Вы это???
При переносе исходника Вы успешно подправите имена портов, замените где нужно номера битов этих портов, но придёт ли Вам в голову менять стандартную Сишную инструкцию "PORTB ^= 1" на какую-то другую? Да никогда в жизни! И программа успешно скомпилируется, и на Вашем столе она заработает без ошибок, и пирожок с полки Вы возьмёте, преисполненный гордостью за умение легко портировать программы. А потом, через месяц-другой, придут недобрые вести с поля - что-то там не фурычит. Приезжай, творец, разбирайся что натворил - изредка бывают сбои. Спорим, что первое, на что Вы подумаете - это на недостаточную помехозащищённость Вашего девайса. Вероятность того, что прерывание попадёт внутрь Read-Modify-Write последовательности, достаточно мала и при тестировании обнаружена не будет, но вот в поле (помножьте эту вероятность на тысячу устройств, которые Вы уже изготовили и внедрили) уверенно даст о себе знать. Пока Вы, начиная с мыслей о помехозащищённости, дойдёте до реальной причины неисправности, пройдёт порядка месяца, не меньше, т.к. это очень труднообнаруживаемая ошибка. Вы вряд ли станете искать ошибку в софте, т.к. при портировании код фактически вообще не был изменён, а в предыдущей реализации сбоев не было. Возможно, ошибку так и не найдёте, но будете всем рассказывать сказки про плохую помехозащищённость или ужасную глючность новых МК...

Имхо:
Надеяться на лёгкую портируемость проектов с одного МК на другой - это путь в страну Грабляндию. Создавая проект, пишите его применительно к данной задаче и для данного МК. Если всё же придётся переносить на другой МК, переносите только блок-схему алгоритма, заново наращивая "скелет" деталями реализации. Чаще всего придётся даже немного изменить алгоритм работы, приспособив его к особенностям новой периферии (например, использовать не поллинг пина по таймеру, а функцию захвата и т.п.).

P.S. Сейчас меня обвинят в том, что я не люблю или не умею писать портируемые программы, что большинство программистов в мире пишут только портируемый код, и что за портируемым кодом будущее. В ответ замечу одну большую разницу - не сравнивайте программирование для PC и для МК. Легко портируются те программы, которые фактически не зависят от аппаратуры, например, математические вычисления (БПФ, фильтры и т.п.). Большинство программ для МК сильно зависят от железа. Правильный с точки зрения программирования подход к созданию легко портируемого кода состоит в том, чтобы выделять в отдельные функции (возможно, inline-функции) всё обращение к периферии, и при каждом портировании переписывать эти функции полностью. Причём для одной и той же операции, например, для "PORTB ^= 1", должны присутствовать две функции: одна реентабельная (для случаев типа нашего), другая нереентабельная, зато быстрая (для обычного однопоточного программирования). Тогда проблем будет гораздо меньше, но программы перестанут быть эффективными. Короче, стандартная ситуация с плюсами и минусами универсальности (тут очень в тему будут слова автора с ником -=Shura=- про джаву - искать гуглем по сайту телесистем фразу "anal sex")...

[_Pasha]

Почти шепотом:
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

[Прохожий]

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

Эта проблема в промавтоматике закрыта, или частично закрыта. Есть некие примитивные мета-языки LD или FBD. Ими широко пользуются. Проекты с одного ПЛК портируются на другие совершенно без проблем. Но там это дело приводили в порядок такие монстры как SIEMENS и ABB в течение 10 лет.
В области МК, на мой взгляд, это невозможно.

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

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

А зачем портировать с одного 8 битового процессора на другой?

Думаю, что ОС должны вырастать из схемы целевого устройства. Тогда и весь бардак сойдет на нет. На ОС возложить (писать на асме):
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. Вот так...

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

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

Да я просто о том, что при определенных стилях и подходах к программированию в сочетании с величиной проекта можно миновать все эти понятия и получить достаточно надежный результат. При этом человек оперирует совершенно другими абстракциями, таким как конечный автомат, состояние, функция переходов и т. д. Эти абстракции проверены временем. Их трудно испортить субъективизмом проектировщика.
Поэтому и возник вопрос насчет ОС, которую порой пытаются применять там, где в этом нет никакой необходимости. Если нет нужды в применениии монстрообразных МК, то зачем ОС? А если не предусматривается смены платформы, то и С, в общем-то, не нужен.

Ну и русский язык вытеснен в этой специфической области за неимением собственных устоявшихся терминов/понятий;(
А врачи говорят на латыни...

Хорошо, давайте попросим автора Рефлекса сделать дополнительно еще и украинский вариант .