Это дело даже не второе, а третье, ибо байты кода это еще команды которые еще исполняются, а некоторые, типа PUSH/POP нескольких регистров, еще и не за один такт.



Написать на ASM

Давайте проверим. Число -2147483647 (т.е. -(2^31 - 1), максимально допустимое для функции) Keil преобразовал за 207 тактов (сравнивал счетчик тактов перед вызовом itoad и после нее). Сколько у IAR?

Думаете дополнительные команды ускорят процесс?

Хочу знать, насколько замедлят.
MOV r2,#0x20202020 выполняется за 1 такт.

Посчитайте на пальцах.

На пальцах до 200? У меня столько пальцев нет
Я лучше на бумаге и калькуляторе.
А SDIV r0,r0,r3 выполняется за 11 тактов... upd. Не всегда! - обнаружил и 10 тактов, и 9 тактов, похоже, от чисел зависит. О! чем меньше делимое, тем меньше тактов. Видел 4 такта.
... а MLS r2,r3,r0,r2 всего за 2.

Так что на пальцах, извините, никак не посчитать.
Максимальное количество тактов для SDIV заметил 12. Где про такты написано?

2 zltigo
Ну если упорно не хотите нормальное сравнение сделать...

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

Cortex-M3 Technical Reference Manual
Divide: 2-12 Cycles
DIV timings depend on dividend and divisor. DIV is interruptible (abandoned/restarted), with worst case latency of one cycle.
When dividend and divisor are similar in size, divide terminates quickly. Minimum time is for cases of divisor larger than
dividend and divisor of zero. A divisor of zero returns zero (not a fault), although a debug trap is available to catch this case.

Перепробовал все "извращения" со сравнениями и др. в надежде уменьшить количество байтов.
Кто бы мне объяснил, почему в некоторых местах команда MOV r2,... кодируется двумя байтами, а в некоторых четырьмя? И не только эта команда.

Как-то связано с операторами перехода по результатам сравнения. Как будто учитывается конвейер.

Думаю, хуже не станет, если я доложу, что уменьшил количество тактов для преобразования -2147483647 в строку до 195. Жаль, что не байтов.

Давайте может функцию настройки PLL по-оптимизируем?

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

Я думаю, вашу функцию можно еще чуть чуть уменьшить.
Или нет?

Сообщение отредактировал rezident - Jul 10 2010, 14:34

Хорошо если по правому боку ровнять:

string += 10; или =11 или =бесконечность

А если нет, что с пр́обелами? Двигать надо будет. Лучше бы сразу на миллиард, потом на сотню лимонов...

А
*(uint32_t *)(string) = 0x20202020;
работает в любом случае? Всегда начало char массива 4-aligned (если умышленно не двигать указатель)?

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

Правда, это относится только к инструкциям, работающим с единичными словами - LDR, LDRH, STR, STRH.
Мультивордовые LDRD/STRD/LDM/STM и т.д. в случае невыравненного на границу 4 байт доступа всё равно приведут к исключению.