[jcxz 184]

12 минут назад, Сергей Борщ сказал:

Пишите тестовый пример, проверим и будем говорить опираясь на факты.

long x, y, z;
long volatile k;

static long sine(long x)
{
  return ...; //вычисление синуса x; не имееет обращений к памяти x, y, z
}

long f2(long, long, long, long);
void f3(long);

void f1()
{
  ...
  long y = f2(k, sine(x), sine(y), sine(z));
  f3(y);
  y = f2(k, sine(x), sine(y), sine(z));
  f3(y);
  ...
}

[_pv 52]

19 minutes ago, jcxz said:

В дизассемблере будет инициализация массива hex[] при каждом вызове вашего кода. Скорее всего - при помощи memcpy(). Что скорее всего будет медленнее, чем полезная часть кода.

шлангу как-то без разницы, он даже вот это прожевал, без static и даже const, а gcc (для АВРов особенно) скорее всего тупить будет.

  str[0] = (char[]){"0123456789ABCDEF"}[(TWSR>>4) & 0x0F];

  str[1] = (char[]){"0123456789ABCDEF"}[(TWSR   ) & 0x0F];

 

  ldr r0, .LCPI0_0

  ldrb r1, [sp, #3]

.LPC0_0:

  add r0, pc, r0

  ldrb r1, [r0, r1, lsr #4]

  ldrb r2, [sp, #3]

  strb r1, [sp, #3]

  and r1, r2, #15

  ldrb r0, [r0, r1]

  strb r0, [sp, #3]

  add sp, sp, #4

  bx lr

.LCPI0_0:

  .long .L.str-(.LPC0_0+8)

.L.str:

  .asciz "0123456789ABCDEF"

 

[Сергей Борщ 119]

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

long x, y, z;
long volatile k;

И где тут несколько файлов для LTO? Где здесь main(), чтобы компилятор не выкинул все это как неиспользуемый код?

[jcxz 184]

54 минуты назад, _pv сказал:

шлангу как-то без разницы, он даже вот это прожевал, без static и даже const

...и на выходе получился мусор.    В мусорку такой компилятор.

Ну или вы что-то не правильно ему указали. Или привели не весь код.

54 минуты назад, _pv сказал:

, а gcc (для АВРов особенно) скорее всего тупить будет.

  str[0] = (char[]){"0123456789ABCDEF"}[(TWSR>>4) & 0x0F];

  str[1] = (char[]){"0123456789ABCDEF"}[(TWSR   ) & 0x0F];

 

  ldr r0, .LCPI0_0

  ldrb r1, [sp, #3]

.LPC0_0:

  add r0, pc, r0

  ldrb r1, [r0, r1, lsr #4]

  ldrb r2, [sp, #3]

  strb r1, [sp, #3]

  and r1, r2, #15

  ldrb r0, [r0, r1]

  strb r0, [sp, #3]

  add sp, sp, #4

  bx lr

.LCPI0_0:

  .long .L.str-(.LPC0_0+8)

.L.str:

  .asciz "0123456789ABCDEF"

 

если это всё, то - печалька  

28 минут назад, Сергей Борщ сказал:

И где тут несколько файлов для LTO?

Вроде очевидно где:

1 час назад, jcxz сказал:

long f2(long, long, long, long);
void f3(long);

специально написал.

28 минут назад, Сергей Борщ сказал:

Где здесь main(), чтобы компилятор не выкинул все это как неиспользуемый код?

Компилятор это не может выкинуть по той простой причине, что ему не известен код функций f2(), f3(). Странно что для вас это не очевидно.  

[_pv 52]

8 minutes ago, jcxz said:

...и на выходе получился мусор.

что не так-то?

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

[jcxz 184]

4 минуты назад, _pv сказал:

что не так-то?

У вас там идёт чтение из стека, инициализации читаемых данных в котором не видно. Нет инита - значит читается мусор.

4 минуты назад, _pv сказал:

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

Потому что в данном конкретном случае ваш компилятор это оптимизировал. А у вопрошавшего не факт, что так сделает.

[Сергей Борщ 119]

1 час назад, jcxz сказал:

Компилятор это не может выкинуть по той простой причине, что ему не известен код функций f2(), f3(). Странно что для вас это не очевидно.  

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

[_pv 52]

22 hours ago, jcxz said:

У вас там идёт чтение из стека, инициализации читаемых данных в котором не видно. Нет инита - значит читается мусор.

из стэка там volatile переменная TWSR читается и туда же пишется, просто чтобы он это целиком не заоптимизировал.

https://godbolt.org/z/Wr1s7ob7E

и тем не менее без const и static, а массивы в памяти никто не создаёт.

[EdgeAligned 53]

А зачем это нужно? 

[Arlleex 131]

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

[jcxz 184]

В 22.09.2023 в 13:39, _pv сказал:

и тем не менее без const и static, а массивы в памяти никто не создаёт.

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

[EdgeAligned 53]

А как указанное в начале темы поможет (может помочь) не терять производительность и/или размер? 

Ну а почему бы не сделать вот так:

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

Делать #include "file.cpp" - нууу не знаю как в ++, не пробовал, но в Си это был крайне дурной тон, да и компилятор не вывозил такого изврата, насколько помню.

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

Изменено 25 сентября, 2023 пользователем EdgeAligned

[VladislavS 29]

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

[Arlleex 131]

20 часов назад, EdgeAligned сказал:

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

1. Я не за размером кода гонюсь, а за скоростью его выполнения.
2. У меня нет совершенно никаких планов переписывать LwIP
3. Я провел некоторые тесты интенсивных обменов короткими пакетами в LwIP и пришел к выводу, что МК нужен пошустрее, но имею то, что запаяно - F407.

При портировании low-level драйвера Ethernet сейчас для себя нужно сделать выбор в пользу одного из:

• главное принять сырые ethernet-кадры в ОЗУ-буфер, а обработает их (успеет ли) LwIP или нет - дело второе;
• либо главное чтобы LwIP "побыстрее" разгребал очередь этих входных кадров, при этом DMA-поток может терять небольшое кол-во входящих кадров.

А я хочу пнуть стек, чтобы он, по возможности, пошустрее все делал. Получится - отлично, не получится - жаль, переживем.
 

45 минут назад, VladislavS сказал:

В плюсах всё гораздо проще. Код можно в описании класса писать прямо в заголовочных файлах.

Можно... Только Вам самому нравится, как это все выглядит? Мне - нет, т.к. интерфейс и реализация перемешаны и одним взглядом не охватываются возможности класса.

[EdgeAligned 53]

А интерфейс в ×× вообще делается на абстрактном классе, потому как чисто понятия интерфейса в ×× нету. 

Ну и да, если делать по-сишному, то реализации методов втамже, где и объявления визуально выглядят хреново