Функции - передача переменных через параметры или глобально?

[parovoZZ]

Не секрет, что адресация глобальных переменных прямая, а переменных в стеке - косвенная. Стек в AVR программный, то бишь откусывается от ОЗУ. Так вот вопрос - при передаче в функцию (и обратно) больших объемов данных (которые невозможно передать через РОН) все же что будет производительнее - через глобальные переменные или через параметры? Понятно, что в функцию вида

uint8_t My_super_function (uint8_t data);

переменные уйдут через РОН,  а вот в такую

void My_super_function (uint8_t *data, uint8_t *ret);

через стек? Так может ну его нафик, стек этот?

Изменено 24 января, 2019 пользователем parovoZZ

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[ruhi]

6 минут назад, parovoZZ сказал:

переменные уйдут через РОН

через какой нафик РОН??? Через стек параметры всегда передаются!

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[ARV]

Все эти тонкости сильно зависят от компилятора. 

Например, avr-gcc стремится все параметры передавать через регистры, пока таковые остаются доступными. Т.е. если передается до 16 (примерно) однобайтовых параметров, то все они уйдут в функцию в регистрах, а если будет, скажем, 20, то 4 пойдут через стек. Соответственно для указателей и других двухбайтных переменных используются пары регистров и т.д.

И, кстати, GCC неплохо "оптимизирует" все эти тонкости.

В связи с чем не совсем понятна цель этих разбирательств... Она нужна, имхо, в двух случаях: когда катастрофически не хватает 2-3 байт памяти и надо извратиться, чтобы их сэкономить, либо когда делается функция на ассемблере и надо точно понимать, как в нее попадут параметры из Си. В остальном на все эти тонкости можно плюнуть, и голову не забивать. Для того высокоуровневый язык и создан, в конце концов.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[parovoZZ]

2 минуты назад, ruhi сказал:

через какой нафик РОН??? Через стек параметры всегда передаются!

Мы в разделе AVR.

1 минуту назад, ARV сказал:

В связи с чем не совсем понятна цель этих разбирательств... Она нужна, имхо, в двух случаях:

Меня интересует производительность.

[ruhi]

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

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

6 минут назад, parovoZZ сказал:

Мы в разделе AVR.

в каком бы вы не были разделе, если вы пишите на С надо исходить из того что параметры передаются через стек.

[parovoZZ]

6 минут назад, ruhi сказал:

проэкт

проЕкт. Мы же на русском форуме?

7 минут назад, ruhi сказал:

в одном файле убирается

нет, не убирается. Но ради производительности готов пожертвовать всем, даже читабельностью. Даже ради инлайна готов отказаться от *.с файлов))

8 минут назад, ruhi сказал:

надо исходить из того что параметры передаются через стек.

AN говорит об обратном. Ну  и дизасм тоже. Правда, мне авторитетно заявили, что дизасм в симуляторе и дизасм готового бинарника несколько отличаются.

[ruhi]

17 минут назад, parovoZZ сказал:

проЕкт. Мы же на русском форуме?

но не на филологическом же?

[ARV]

Только что, ruhi сказал:

глобальные переменные действительно лучше с точки зрения производительности

Не безусловный факт. В некоторых случаях вообще не факт.

Только что, parovoZZ сказал:

Но ради производительности готов пожертвовать всем, даже читабельностью

Пишите на ассемблере.

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

Между передачей через стек и через регистры разница столь несущественна (в плане производительности), что я вообще не понимаю, зачем об этом думать! Честно не понимаю.

Смотрите сами: глобальная переменная доступна командой LD/LDS. Переменная в стеке добывается той же командой LD/LDS. В чем вы собираетесь выиграть? Сохраняются переменные и глобальные, и "стековые" тоже одними и теми же командами ST/STS. Выигрыш может быть лишь за счет того, что в стек надо "сохранить", чтокак бы может быть лишним... но уверяю вас: компилятор распределяет переменные по рабочим регистрам так, что к тому моменту, когда их (переменные) надо использовать, они уже там, где надо. 

К тому же, как я уже говорил, GCC раскладывает все по регистрам R16-R31, если их достаточно. Поэтому, если желаете, то просто стремитесь сократить количество передаваемых параметров...

[ruhi]

18 минут назад, parovoZZ сказал:

дизасм в симуляторе и дизасм готового бинарника несколько отличаются

да никогда они на отличались, дизасм он по определению по бинарнику ходит, авторитеты наверно у тебя филологические :).

24 минуты назад, parovoZZ сказал:

AN говорит об обратном

мы наверно главный вопрос пропустили:

А вы вообще оптимизацию включили в компиляторе? И если да то на что:

на производительность;

на размер кода;

на то и другое (компромиссную)

?

Когда оптимизация включена, не всегда вызов функции можно найти в дизасемблере, а вы какие то предположения делаете о том как параметры передаются!

[parovoZZ]

33 минуты назад, ARV сказал:

Пишите на ассемблере.

Завидую тем, кто на асме как рыба в воде, но у меня иммунитет на него.

35 минут назад, ARV сказал:

Поэтому, если желаете, то просто стремитесь сократить количество передаваемых параметров...

А через указатель? Правда, передача не возвращаемых параметров через указатель - перебор, не?

36 минут назад, ruhi сказал:

А вы вообще оптимизацию включили в компиляторе?

-O3. Другие что-то не признаю)

46 минут назад, ARV сказал:

Смотрите сами: глобальная переменная доступна командой LD/LDS. Переменная в стеке добывается той же командой LD/LDS.

LD - косвенная адресация через X/Y/Z, LDS - прямая из SRAM. Из стека можно вытянуть командой LDS?

[ARV]

Только что, parovoZZ сказал:

А через указатель? Правда, передача не возвращаемых параметров через указатель - перебор, не?

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

Еще раз повторяю свою основную мысль: ручная "оптимизация" нужна в крайне редких случаях, поому как почти всегда проигрывает "автоматической". Вам на самом деле важно сэкономить пару тактов на обращение к функции за счет манипуляций с её параметрами? Или это просто навязчивая идея? В одной теме вы ищите, чем занять ядро во время ожидания завершения передачи SPI, а тут вы озаботились скоростью передачи параметров в функцию... Там у вас времени избыток, тут нехватка... Странновато...

Вот мне лично никогда не приходилось применть оптимизацию иную, чем -Os. Вот вообще ни разу.

Изменено 24 января, 2019 пользователем ARV

[parovoZZ]

2 минуты назад, ARV сказал:

Передача указателя имеет смысл, если обрабатываемые данные велики и структурированы. Например, строки, массивы или структуры.

Есть у меня структура. Допустим, 5 байт. Я создаю массив с элементами этой структуры. Скажем, мне надо 6 таких элементов. Разумеется, что я такой массив через указатель передаю.

 

[cucumber]

Всем привет, нужна помощь, вроде тема похожая... AVR+LCD(символьный)+кнопки.  Нужно, чтобы была возможность из функции выйти в любой момент при нажатии кнопки (так как в функции длинный текст выводится бегущей строкой). Для этого я передаю в функцию переменную  через указатель.  Кнопки обрабатываются в прерывании, там же, при нажатии любой кнопки меняется переменная. Пока не добавил указатель - текст выводился, без выхода из функции разумеется. Как только добавил переменную, то вывод текста исчез , но из функции уже можно выйти нажатием на клавишу (при изменении переменной). Есть мысли, что не так? Возможно я глобально все не так делаю, может, есть какие-то варианты?

void show(unsigned  char * fl)
{
    for(unsigned char i=0; i<50; i++)     
	  {   
		 for (unsigned char j=0; j<16; j++)
		 {
		    cursor(0x80 + j);
		    if (  (i +j) < 95 ) { PORTC = text [i + j]; }
			_delay_us(40);
		    strob(); 
		 }
		 for (unsigned int x=0; x<150; x++)// Pause
		 {   _delay_us(300); if ( *fl&(1<<2)) {return; }  }
		
	   }//for
} //void 

 

Изменено 22 июля, 2019 пользователем cucumber
опечатки

[parovoZZ]

3 minutes ago, cucumber said:

Есть мысли, что не так?

не могу понять - в какой строчке реализован выход из функции? единственный return и тот закомменчен.

Просьба - Си код вставлять с подсветкой Си кода. Так тяжело читать

[cucumber]

поправил, комменты ставил, когда пытался разобраться

[cucumber]

кажется я с приоритетами напутал... * и &, ушел искать инфо

[parovoZZ]

2 hours ago, cucumber said:

if ( *fl&(1<<2))

Совсем не понимаю, что здесь происходит. Если нужно логическое сравнение, то пишется &&.

[cucumber]

что задумывалось: сначала разименовываем, затем складываем fl и 1<<2 побитно, затем результат сравниваем. Если 1, то... Добавил скобок - все не то, что-то я не врубаюсь. & побитное И вроде, && логическое. Сам принцип вылезти из функции преждевременно с помощью указателя верен?

Изменено 22 июля, 2019 пользователем cucumber

[parovoZZ]

А зачем 2 сдвигать влево на один бит? Двойка превратиться в 4.

[cucumber]

ну да, а в fl меня тоже интересует 2-й бит. 100 И fl = 0 или 1 в зависимости от 2-го бита fl. Ну да, запись извращенская, сам не понимаю, как на нее подсел. Раньше бы написал 0b00000100

Изменено 22 июля, 2019 пользователем cucumber

[parovoZZ]

А вызов функции как выглядит?

[cucumber]

show (&flags);

разнес цикл вывода текста и "паузы" с опросом fl. Текст выводится, естественно пока он выводится из него убежать никак. А из паузы можно убежать. Т.е. таким образом "все" работает, но стоит запихнуть условие с fl в цикл с выводом массива, то текст исчезает))

void show(unsigned  char * fl)
{
    for(unsigned char i=0; i<50; i++)     
	  {   
		 for (unsigned char j=0; j<16; j++)
		 {
		    cursor(0x80 + j);
		    if (  (i +j) < 95 ) { PORTC = text [i + j]; }
			_delay_us(40);
		    strob(); 
		 }
      }//for
	 for (unsigned int x=0; x<150; x++)// Pause
	 {   
        _delay_us(300); 
        if ( *fl&(1<<2)) {return; }  
	 }//for
} //void 

где-то у меня ошибка в условии  if ( *fl&(1<<2)), что-то я напортачил с флагами)) ушел курить программу

Изменено 22 июля, 2019 пользователем cucumber

[cucumber]

сорри народ, кто успел поломать мозг, это я флаг после нажатия кнопки не уследил в основной программе, и он в функцию уже приходил =1. Но получается так можно делать - выходить из функции таким макаром?  

Изменено 22 июля, 2019 пользователем cucumber

[Starichok]

кнопка обрабатывается в другой функции.

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

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

[parovoZZ]

8 hours ago, cucumber said:

Но получается так можно делать - выходить из функции таким макаром?

Раз такой механизм выхода предусмотрен, значит им можно пользоваться. Лично я return использую для возврата значения, чаще всего это булево значение-признак как отработала функция. В остальных случаях это оператор if ... else.

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

Лично мое мнение: вся работа с кнопками должна организовываться через конечный автомат. Сейчас и кнопка и её два состояния позволяют писать более-менее читаемый код. Если кнопок будет не одна, у каждой кнопки будет несколько состояний (однократное нажатие, длинное нажатие, двухкратное и т.д.), то написать читаемый код в такой манере будет всё сложнее и сложнее. Усложниться и отладка.

Вот это:

9 hours ago, cucumber said:

(1<<2)

называется маска. Логичнее всего её вынести в секцию дефайнов:

#define  switch_mask	4

и в коде писать так:

if (*fl & switch_mask)
{}

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