Я просто не верю что IAR STM8 такой тупой!, Ведь это же всегда был один из самых качественных компиляторов Опции

[Эдди]

Космик только под мастдайку — не годится.

[AHTOXA]

Удивительно, но при раздутом размере IAR по тактам таки победил
19498 тактов у IAR
19929 Cosmic

Раз уж вы взялись тестировать, то укажите и полученный размер. (Ну и добавьте sdcc, для полноты картины).

[Михась]

Раз уж вы взялись тестировать, то укажите и полученный размер. (Ну и добавьте sdcc, для полноты картины).

Кейл V5

Cortex-М0 L3 2673мт
Program Size: Code=308 RO-data=224 RW-data=16 ZI-data=1152


Cortex-М3 L3 1651мт
Program Size: Code=304 RO-data=224 RW-data=16 ZI-data=1152

Сообщение отредактировал Михась - May 11 2017, 14:39

[AHTOXA]

Это немного не то, интересны именно компиляторы для STM8.

[Михась]

Это немного не то, интересны именно компиляторы для STM8.

Это да, просто хотел получить некоторую калибровочную точку на основе широко распространенной архитектуры


Компилятор RIDE51 6.4 для 8052 показал время выполнения 1,1 сек на частоте 1МГц с оптимизацией по скорости и 3,3 сек с оптимизацией по объему. Прогресс внушает!!

Keil C51 8052 L7
52 632 тактов
Program Size: data=114.0 xdata=0 code=1228

Сообщение отредактировал Михась - May 12 2017, 15:41

[sigmaN]

Странно, но космик в удобном виде размеры не выводит.
короче сравниваем .text я так понимаю
Cosmic 574 байта

Код

                               --------
                               Segments
                               --------

start 00008080 end 0000808c length    12 segment .const
start 0000808f end 000082cd length   574 segment .text
start 00004000 end 00004000 length     0 segment .eeprom
start 00000000 end 00000000 length     0 segment .bsct
start 00000000 end 00000096 length   150 segment .ubsct
start 00000096 end 00000096 length     0 segment .bit
start 00000096 end 00000096 length     0 segment .share
start 00000100 end 00000100 length     0 segment .data
start 00000100 end 00000100 length     0 segment .bss
start 00000000 end 0000036c length   876 segment .info.
start 00000000 end 000003ca length   970 segment .debug
start 00008000 end 00008080 length   128 segment .const
start 0000808c end 0000808f length     3 segment .init

IAR 635байт

Код

"P3":                                 0x27b
  .near_func.text  ro code  0x008080  0x14c  main.o [1]
  .near_func.text  ro code  0x0081cc   0xcc  long.o [4]
  .iar.init_table  const    0x008298    0x8  - Linker created -
  .near_func.text  ro code  0x0082a0   0x1e  init_small.o [4]
  .near_func.text  ro code  0x0082be   0x17  init.o [4]
  .near_func.text  ro code  0x0082d5   0x13  cstartup.o [4]
  .near_func.text  ro code  0x0082e8    0x5  cexit.o [4]
  .near_func.text  ro code  0x0082ed    0x3  interrupt.o [4]
  .near_func.text  ro code  0x0082f0    0x3  low_level_init.o [4]
  .near_func.text  ro code  0x0082f3    0x3  exit.o [4]
  .near_func.text  ro code  0x0082f6    0x3  unhandled_exception.o [4]
  .near_func.text  ro code  0x0082f9    0x2  xxexit.o [3]
                          - 0x0082fb  0x27b

SDCC что-то не сдюжил....
D:\Poligon\FIR_TEST\sdcc>sdcc -lstm8 -mstm8 --out-fmt-elf main.c
main.c:126: error 9: FATAL Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCopt.c' line number '805' : 0
Contact Author with source code
Странно, строка 126 в тестовом файле это for (i=0;i<N;i++)

в общем тут в этом посте есть исходник теста, каждый может по развлекаться и сравнить лично https://electronix.ru/forum/index.php?s=&am...t&p=1498198

Вот даже готовые проекты для IAR, STVD и AVR Studio 7 Можно с опциями оптимизации поиграться на досуге
https://drive.google.com/file/d/0B7dMRxCEo4...iew?usp=sharing

[sigmaN]

Мой товарищ сделал задержку 1us вот таким не хитрым способом

Код

#define ONE_US_DELAY nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop();nop()

Этот nop() есть ни что иное как макрос разворачивающийся в asm("nop")

Ну а я себе на асме сделал C Callable функцию с пустым циклом и предложил ему отказаться от его метода, который занимает 17байт на каждую задержку(коих в коде у него было около десятка). В пользу моего более гибкого варианта, дающего задержки от микросекунд до миллисекунд.
Но.... Внимание. Когда он заменил это на вызов моей функции - размер кода даже незначительно увеличился! О___о
Расследование показало удивительный факт: его макрос превратился в вызов функции и если шагнуть в вызов то, внимание, барабанная дробь


Вы представляете, IAR даже посчитал оверхед на CALL / RET и уменьшил кол-во нопов в теле этой автогенерированной функции!

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

[jcxz]

Расследование показало удивительный факт: его макрос превратился в вызов функции и если шагнуть в вызов то, внимание, барабанная дробь

Не понятно - что именно IAR заменил?

[Den64]

Не понятно - что именно IAR заменил?

Несколько nop * 16 на подпрограмму.

[jcxz]

Несколько nop * 16 на подпрограмму.

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

[Den64]

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

Их количество такое что выполнение подпрограммы займёт 1мкС. Хотя такое впечатление что NOPов маловато. Хотя может быть и достаточно.

Не заметил что подпрограмма вызывается дважды. Тогда выполнение займёт больше 1 мкС.


Это из игры fallout. Что это за приложение для stm8?

[sigmaN]

Это из игры fallout. Что это за приложение для stm8? biggrin.gif

Да кто ж его знает, они там игровую муть всякую делают.....

Хм, кстати да, там же откуда-то второй CALL еще взялся.
Короче надо будет исследовать это дело. Но то что он превратил макрос в функцию и вызывал ее - это 100%. По поводу уменьшения кол-ва нопов точных подсчетов я не проводил, но то что их меньше чем 16шт было - это тоже очевидно. Кажется на CALL/RET оверхед должен быть тактов 8, если мне не изменяет склероз. Соответственно нопов должно быть тоже 8 штук.

Add: блин, были ссылки на фотки из vk. Что-то там умерло, скриншоты пропали В самом vk эта фотка тоже щас не открывается. Что-то упало у них там...потом думаю восстановится само.

[AHTOXA]

Мне фотки видны.
Он заменил 16 nop-ов на два вызова подпрограммы, которая содержит 8 nop-ов. Так что времянка не соблюдена, тут чуда не произошло. (А я уж сначала подумал, что IAR освоил телепатический режим)

[sigmaN]

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

[jcxz]

Короче надо будет исследовать это дело. Но то что он превратил макрос в функцию и вызывал ее - это 100%. По поводу уменьшения кол-ва нопов точных подсчетов я не проводил, но то что их меньше чем 16шт было - это тоже очевидно. Кажется на CALL/RET оверхед должен быть тактов 8, если мне не изменяет склероз. Соответственно нопов должно быть тоже 8 штук.

Я Вас просил привести макрос, из которого был сгенерён тот листинг с NOP-ами, приведённый Вами. Иначе просто вообще непонятно оценить, что и из чего Вы получили.
Вы утверждали (как я понял), что IAR якобы уменьшил количество NOP-ов Вашего макроса так, чтобы в результате при оформлении их в п/п, общая задержка этой п/п была == задержке всех NOP-ов исходного макроса. Это крайне сомнительно. Так как для этого IAR-у нужно понимать назначение данного макроса, думать за программиста.
Поэтому и просил привести исходный макрос. Чтобы например можно было повторить у себя и убедиться (или не убедиться).

Их количество такое что выполнение подпрограммы займёт 1мкС. Хотя такое впечатление что NOPов маловато. Хотя может быть и достаточно.

Мой вопрос был вообще не про это. См.выше.