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

[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")...

[defunct]

Недавно на телесисях была поучительная ветка. Вот она
......
Прочитайте её, интересно.

"программу на C для Tiny13" я вообще не понимаю.

Но если абстрагироваться от t13, достаточно только глянуть на код чтобы сказать - будут проблемы.
Для обеспечения портируемости полностью соглашусь с sensor_ua - надо:
1. разделять код на портируемый участок и аппаратно записимый.
2. описывать функции ввода/вывода.

Легко портируются те программы, которые фактически не зависят от аппаратуры, например, математические вычисления (БПФ, фильтры и т.п.).

Если работа с аппаратурой - не самоцель портируемой программы, то может так случиться что при переходе с платформы на платформу вообще ничего не переписывается... пример - IP стек.

А для работы с аппаратурой есть небольшая прослойка - ОС, которая и затачивается под требуемые платформы.

[Прохожий]

"программу на C для Tiny13" я вообще не понимаю.

Но если абстрагироваться от t13, достаточно только глянуть на код чтобы сказать - будут проблемы.
Для обеспечения портируемости полностью соглашусь с sensor_ua - надо:
1. разделять код на портируемый участок и аппаратно записимый.
2. описывать функции ввода/вывода.
Если работа с аппаратурой - не самоцель портируемой программы, то может так случиться что при переходе с платформы на платформу вообще ничего не переписывается... пример - IP стек.

А для работы с аппаратурой есть небольшая прослойка - ОС, которая и затачивается под требуемые платформы.

Т.е., обобщая по-порядку:
1. Подбираем подходящую ОС и с помощью напильника в виде смеси С и АСМ (или С в чистом виде?)подгоняем ее под желаемую функциональность.
2. Опять же разделяем софт на 2 части - аппаратно-зависимый и нет (тоже работа).
3. Аппаратную часть пишем на смеси С и АСМ (или С в чистом виде?).
4. Независимый кусок пишем на С или С++.
Поправьте, если что-то пропустил.
И что, такой подход однозначно гарантирует отсутствие обсуждаемых ошибок? Или уменьшает затраты на их поиск?

[Petka]

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

Совсем нет. Ошибки ошибками, а переносимость переносимостью. При переносимости переносится как работающий код, так и ошибки в нём.