avn Feb 22 2011 at 07:26

Запретный плод GOTO сладок (версия для микроконтроллеров)!

8 min

13K

Programming microcontrollers*

+17

Comments 70

bobermaniac Feb 22 2011 at 07:46

Логика программы без goto оперирует абстракцией «блок». Я вижу — блок ветвления, блок циклов, блок переключателей. Я могу в уме следить, какие из блоков будут выполняться и быстро анализировать программу.

Логика программы c goto спускает меня на уровень абстракции «инструкция». Я вынужден читать каждую инструкцию и пытаться понять, куда пойдет выполнение программы в следующей строке. Я не могу охватить взглядом весь метод, потому что он связан внутри себя миллионом безусловных переходов, передающих управление в самое неожиданное место.

В вашем первом примере, в частности, если бы блок-схема была для реального процесса, а переменные назыаны по-человечески (а не одной буквой), то логика была бы гораздо понятнее.

BiSeTrojanov Feb 22 2011 at 10:37

А вы не лепите 20 гото, сделайте goto входной точкой перед блоком, и вы опять сможете разделять программу на блоки, а не на инструкции

Nashev Feb 23 2011 at 11:50

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

BiSeTrojanov Feb 23 2011 at 12:22

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

avn Feb 23 2011 at 12:26

Для недлинных программ такое сойдет. Но когда строк кода под тысячу… У меня программы, как правило, разбиты на много файлов и кучу функций. Плюс — reusability (или как там по аглицки :-)? ...)

7vies Feb 23 2011 at 13:10

Да какая разница кто сколько лет как пишет? Интереснее вопрос, общались с людьми, которые должны ваши программы поддерживать, и не предпочли ли они заново переписать вместо того чтобы с вашим подходом разбираться.

avn Feb 23 2011 at 14:12

Этого не знаю, т. к. я работаю в основном сольно :-)

BiSeTrojanov Feb 23 2011 at 14:20

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

avn Feb 23 2011 at 12:23

return требует больше — значительно больше! — тактов контроллера, чем простой goto. Во-первых, операция перехода и выхода. Во-вторых, работа со стеком. В-третьих, передача параметров.
В противоположность goto — одна операция.

Nashev Feb 23 2011 at 13:03

inline-функции спасут

avn Feb 23 2011 at 14:13

inline-функция — это рекомендация компилятору, в особенности для микроконтроллеров. Visual Studio поддерживает что-то вроде __forceinline, но он тоже гарантированно в inline не превращает

Nashev Feb 23 2011 at 22:40

он игнорирует её просто так, или из соображений оптимизации скорости?

avn Feb 24 2011 at 07:59

Не знаю, честно говоря… Самому непонятно почему

Nashev Feb 24 2011 at 08:13

А вот только что в соседней теме увидел: например, в случае рекурсивной функции inline разворачивать без толку. Хотя, я б предпочёл, чтоб мне компилятор в этом случае ошибку выдал, а не просто проигнорировал inline.

Nashev Feb 23 2011 at 13:06

UPD: Именно для этого нужен компилятор — чтоб человеко-читаемую структуру кода развернуть в цепочку команд процессора. Обернуть неограниченные возможности goto в короткий ряд отдельных конкретных и легче понимаемых способов применения.

7vies Feb 23 2011 at 13:15

Вам ведь и в предыдущей теме точно так же на такой же коммент ответили, «инлайн функции» :)
Или хотите сказать для микроконтроллеров нет нормальных компиляторов, которые умеют оптимизировать? С gcc я бы не стал соревноваться на эту тему, уж больно крутым надо быть и немало времени потратить на каждый случай чтобы его переоптимизировать.

avn Feb 23 2011 at 14:14

Опять же — не весь код можно превратить в inline.

7vies Feb 23 2011 at 14:43

С современными C++ компиляторами сложно бороться, чтобы функция не превратилась в инлайн. Я честно не знаю, как с этим дело в си и в микроконтроллерах в частности.

DIHALT Apr 28 2011 at 14:32

Уделать GCC для AVR (с другими не пробовал) на ассемблере раз плюнуть. Он конечно, хорошо оптимизирует по сравнению с другими Си компилерами для AVR, но нативный асмовский код все равно получается короче.

BiSeTrojanov Feb 23 2011 at 14:31

Это, кстати, одна из причин (но не единственная) из-за которой я пользуюсь goto вместо функций. Я люблю говорить «стэк не резиновый», обычно мне на это отвечают «сейчас на дворе XXI век, а ты пишешь программы, будто до сих пор под DOS'ом сидишь» (хотя я никогда не сидел под Досом, компа ещё не было). На мои слова про кол-во тактов все вообще не обращают внимания, прикрываясь тем же самым «XXI веком на дворе» и «парой наносекунд выигрыша».
Люди отвыкли писать тонкие шустрые аскетичные вещи и ленятся добавить пару строк кода, что бы сохранить мегабайт оперативной памяти. Из-за таких мы и имеем программы, жрущие по 500 МБ и это только во время инициализации.

avn Feb 23 2011 at 14:36

Да, я лично тоже стараюсь писать программы в первую очередь оптимальные. И если для PC с таким подходом можно поспорить — из-за тогое XX1 века,- то для микроконтроллеров это очень и очень важно

BiSeTrojanov Feb 23 2011 at 15:47

Научившись писать неоптимизированные программы для PC, программист не научится писать оптимизированные для какого-нибудь Cannoo, а там его с подходом «ой да ладно, чё там какой-то МБ ОЗУ» ждёт печаль.

avn Feb 22 2011 at 07:48

Я согласен с тем, что бездумное раскидывание goto ведет к трудности чтения алгоритма.
Приведенная блок-схема условна — просто какой-то пример. Поэтому и имена там такие же :-)…

thecarpetman Feb 22 2011 at 07:49

А как насчет примера из учебника:

 if (a > 0) {goto inner};

 ... // команды

 {

 X ax = X(a);

 ... // команды

 inner:

 // Сюда произойдёт переход по goto

 ...

 // По завершении всех команд блока компилятор вызовет 

 // деструктор ~X() для переменной ax.

 }

А конструктор для этой переменной не вызывался ведь?
Мне всё равно кажется, что использование GOTO без сильной необходимости разрушает принципы структурного программирования, но в одном вы правы точно — нельзя просто вычёркивать этот оператор из языка.

bobermaniac Feb 22 2011 at 07:51

Можно и нужно. Goto не дает ничего, чего нельзя было бы достичь другими средствами, зато ухудшает восприятие.

avn Feb 22 2011 at 08:00

Мы говорим о микроконтроллерах — так ведь? И о С

SADKO Feb 22 2011 at 08:15

А если мы говорим о контроллерах, то там GOTO в порядке вещей, ибо код получается компактнее и быстрее, и в реалиях микроконтроллеров это гораздо важнее православности сионизма!

avn Feb 22 2011 at 08:38

православности сионизма

Супер! Надо запомнить и козырнуть

7vies Feb 23 2011 at 13:19

Тот же вопрос — оптимизирующих компиляторов для микроконтроллеров нет что ли? Под gcc оптимальность и компактность кода будет связана не с количеством goto, а совершенно с другими факторами, и оптимизирует он во многих случаях лучше, чем усреднённый программист может с наскока.

DIHALT Apr 28 2011 at 14:35

По крайней мере GCC флажковую конструкцию не может развернуть в один переход, как того требует логика алгоритма, она так и остается флажковой конструкцией.

no_smoking Feb 23 2011 at 15:34

О боже я только что написал программу для AVR на с++ и не разу не использовал оператор goto и представьте она делает то что мне нужно.

qehgt Feb 22 2011 at 20:04

>// Сюда произойдёт переход по goto
Не произойдёт. Компилятор выдаст ошибку ещё на этапе компиляции.

no_smoking Feb 23 2011 at 15:39

специально проверил в WinAVR скомпилировал однако :)

7vies Feb 23 2011 at 13:29

Ололо, деструктор, goto. Хреновый пример из учебника, не пишите такое в реальном проекте, т.к. будут больно бить по пальцам. В си++ центральная концепция — блоки (scope), и не нужно их вот так вот превращать в лапшу странными переходами. Перед тем, как написать goto в си++ нужно очень хорошо подумать, а зачем оно здесь.

ThePretender Feb 22 2011 at 09:48

Полностью поддерживаю, отказываться от GOTO из-за эстетических соображений — это маразм. И если при программировании под PC все эти костыли прокатывают без проблем, то в МК левые флаги и проверки в момент сожрут всю память и такты. Надо думать головой в каждом конкретном случае, фанатизм не рулит :)

З. Ы. Подписался на камменты и запасся попкорном :)

avn Feb 22 2011 at 09:50

Тут как раз обсуждение идет вяловато — по сравнению с версией для PC

borisko Feb 22 2011 at 19:21

А в чём отличие версии для микроконтроллеров и версии для PC?

zetroot Feb 22 2011 at 19:39

У микроконтроллеров есть существенный момент — СИЛЬНО ограниченная RAM/ROM/MIPS. Так что иногда да, на флагах стоит поэкономить. Да и на размере прогибается — тоже. Иногда 10-20 байт — критично.

DIHALT Apr 28 2011 at 14:38

Несколько иная архитектура (очень много регистров РОН, что облегчает локальные переменные). Доступ в байт из ОЗУ только через загрузку его значения в регистр и сохранение его обратно (редко бывает иначе).

Крайне неглубокий стек, особенно на PIC (что то около 7 уровней чтоль). Всего десяток килобайт флеша и пара сотен байт ОЗУ.

UFO landed and left these words here

avn Feb 23 2011 at 06:47

Главное — чтобы в пределах заданных условий она корректно выполняла алгоритм. Хотелось бы — максимально оптимально. И мечтается — чтобы код был максимально красив.
А какие средства для этого используются — это уже дело десятое.

UFO landed and left these words here

7vies Feb 23 2011 at 13:34

«Главное» зависит от задачи. В больших проектах главное — это поддерживаемый код, который несложно расширить и пофиксить баги. А если весь код написан в таком стиле, как демонстрируется в статье, для того чтобы что-то менять придётся потратить немало времени на понимание что же на самом деле происходит, и почему если поменять что-то в одном месте, ломается в другом.

avn Feb 23 2011 at 14:15

Если операция goto сугубо локальна, то проблемы если и возникнут, то в отдельно взятом коде.
Еще раз для тех, кто не вчитывается — я не призываю весь код фаршировать

7vies Feb 23 2011 at 14:33

Локально — не вопрос, если это необходимо. Главное, чтобы потом не возникло соблазна чуть пошире использовать, потом ещё пошире… ;)
В частных случаях-то и устройство Даффа применимо, если шибко хочется :]

avn Feb 23 2011 at 14:16

… обилием goto! Он нужен в отдельно взятых случаях! Их немного — по пальцам одной руки пересчитать можно. Но именно там он спасает положение

Melz Feb 22 2011 at 23:38

Ну куда же в микроконтроллерах без goto :)

/*
* For PIC18 devices the low interrupt vector is found at
* 00000018h. The following code will branch to the
* low_interrupt_service_routine function to handle
* interrupts that occur at the low vector.
*/

#pragma code low_vector=0x18
void interrupt_at_low_vector(void)
{
_asm GOTO low_isr _endasm
}

#pragma code /* return to the default code section */
#pragma interruptlow low_isr
void low_isr (void)
{
/*… */
}

Pilat Feb 23 2011 at 00:23

Перепишем вариант с goto немного, XXX и YYY — какой-то код:

if (a)
{
A;
goto L3;
}
L1:
XXX;
if (b)
{
YYY;
L2:
B;
L3:
C;
goto L1;
}
else if (!c)
{
D;
goto L2;
}
E;

Впрыгивание L2 внутрь блока пропускает какой-то код YYY, потенциально влияющий на код после L2. Я думаю, как раз для устранения таких случаев, — а при нескольких goto может быть и больше пропущенного кода, — и стараются запретить goto вообще, чисто из профилактических соображений.

OasisInDesert Feb 23 2011 at 05:51

В функции с множественными проверками на ошибочность выполнения проще использовать Goto для выхода из блока или вызывать исключение…… ИМХО

NoWeekOff Feb 23 2011 at 06:33

GOTO должен остаться в забвении не потому что он плох сам по себе, а потому что он плох в руках идиота. Как топор — можно и сруб смастерить, а можно и жизни лишить.

lalaki Feb 23 2011 at 07:32

можно попробовать вывести критерии, «когда точно нельзя GOTO».

Самый простой и в принципе достаточный: не используем низкоуровневый язык — пишем без GOTO.

Но для этого нужно не смешивать рассуждения для высокоуровневых и низкоуровневых языков — к сожалению, в этом посте смешение наблюдается, хотя это два разных холивара: аргументы совсем разные, да и по низкоуровневому случаю специалистов гораздо меньше, смысла спорить нет (кроме "в интернете кто-то не прав"

lalaki Feb 23 2011 at 07:45

Предлагаю явно разделить случаи высокоуровневого/низкоуровневого программирования, и поспорить отдельно для высокоуровневого, готов развернуто выступить против GOTO

gnomeby Feb 23 2011 at 08:10

Что за копипаста предыдущей статьи?

avn Feb 23 2011 at 08:20

Не совсем copy-paste — дело в том, что, как оказалось, не надо мне было в одной статье совмещать разные стили программирования — С++ для PC и C для микроконтроллеров. Поэтому я выделил сюда относящееся именно к микроконтроллерам. А в предыдущей статье я уже не стал удалять микроконтроллерную часть — чтобы у новых читателей не возникало недоумения от некоторых комментариев.

avn Feb 23 2011 at 08:18

Для тех, кто следит за темой — я в конце статьи вставил плюсы и минусы использования goto. Если кто хочет добавить/исправить — пишите в ответы сюда

lalaki Feb 23 2011 at 09:03

добавьте в плюсы самое важное: экономит память/такты при правильном использовании — это бесспорно, по-моему. это требования «от машины», приоритетные при низкоуровневом программировании

все остальное — приоритеты «от человека», которые сводятся к слову «сопровождаемость», здесь все сложнее.

avn Feb 23 2011 at 11:18

Согласен

Derailed Feb 23 2011 at 09:07

Надуманные примеры, которые Вы применяете в пользу goto, ИМХО не нужны, в реальной жизни такого не бывает.

То, что Вы пишете про for, do, switch, что это «банальный goto, если использовать break и return» — передергивание. Испортить можно все что угодно, даже самым хорошим инструментом. Выходы из цикла через break привязаны именно к этому циклу, поэтому логику выполнения отследить легче, в отличие от оператора goto, который имеет право перейти куда угодно.

goto стали нелюбить с тех пор, как появились функции и блоки (куски кода между begin end и {}) в программах. Пусть эти блоки мало отражают действительность (реальное выполнение ассемблерного кода), но зато именно с помощью этих блоков стало возможным применить метод «разделяй и властвуй», т. е. код стал наглядным, читабельным и понятным (по крайней мере в умелых руках можно его сделать таким). То есть, не применяя goto, можно быть уверенным, что внутри блока идет линейное выполнение нужного алгоритма. Если Вы начинаете в своих программах применять goto, то Вы потенциально теряете такое удобство. Умные люди не любят goto за то, что справедливо считают — выигрыш от его использования намного меньше вреда, который оператор goto может принести.

avn Feb 23 2011 at 11:18

Я в «минусах» уже отметил то, что Вы говорите,- нарушение презумпции линейности кода

7vies Feb 23 2011 at 13:40

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

avn Feb 23 2011 at 14:18

Ну естественно по-своему! Ведь это же я пишу :-)!
«Линейность» в моем понимании — это отсутствие непредсказуемых скачков вперед-назад. Все случаи циклов, switch, if — это предсказуемо. А вот как раз exception в C++ — не всегда предсказуемо.

7vies Feb 23 2011 at 14:40

Исключения неизвестно где будут пойманы, но кроме этого они вполне даже подчиняются законам блоков, и известно что деструкторы будут позваны и т.п. Они умеют «выпрыгивать» только из блоков, но не умеют запрыгивать в середину блока, превращая код в месиво. Кроме того, исключения — необходимость, потому что нет другого способа сообщить об ошибке из конструктора. Это можно обойти и писать без исключений, но это будет уже другой подход.

Ещё раз, имхо важны именно блоки а не «скачки вперёд-назад» или нелинейность. Блок — сущность с хорошо определёнными точками входа и выхода, и goto эту определённость уменьшает.

BugEater Feb 23 2011 at 12:46

Реализация алгоритма, описанного в статье, без goto:

void l1() { if (b) { l2(); B(); l3(); } else if ( c ) { E(); } else { D(); l2(); } } void l3() { C(); l1(); } // Entry point. if (a) { A(); l3(); } else { l1(); } * This source code was highlighted with Source Code Highlighter.