Изучаем STM32 Cortex M3

[Hives]

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

[tempora]

Код:

void int2hex3(int value, char *str, int digits) { char i,hexTable[] = "0123456789ABCDEF"; *str-- =0; for(i=digits;i;--i,value=value››4) *str-- =hexTable[value & 0x0F]; }

Сильно не исследовал, ...
Поправьте меня, ...

1. hexTable[] действительно, объявлена неудачно. Но глобальные переменные - штука обязывающая, лучше объявить статической.
2. Вычисление конца массива/строки ("int2hex3(0xABCD, &hexvalue[digit], digit);") лучше внести внутрь функции.
3. Оператор простановки терминирующего нуля нужен тогда, когда конец строки имеет переменное положение, а здесь он - лишние накладные расходы.
4. Постдекременты - нехорошая практика.
5. Оператор запятая работает с точностью до наоборот, поэтому цикл будет управляться не значением digits, а нибблами value - если value не превышает 15, цикл не исполнится ни разу, от 16 до 255 - один раз и так далее.

[Hives]

tempora ‹ох%евший смайлик›

[tempora]

‹ох%евший смайлик›

Да не, ничего особенного. =GM= имел ввиду вот такой принцип, с точностью до шестнадцатиричности и переменного числа знаков.

[_Артём_]

1. hexTable[] действительно, объявлена неудачно. Но глобальные переменные - штука обязывающая, лучше объявить статической.

static мало - нужно volatile, как минимум...

PS. Локальные переменные - штука не обязывающая?

1. hexTable[] действительно, объявлена неудачно.
4. Постдекременты - нехорошая практика.

Чем плоха такая практика? Работать не будет или будет, но медленно?

[tempora]

нужно volatile, как минимум...

Ну, тогда уж и в капслоке.
Локальные - не обязывающая. Пост-инкременты или -декременты такие, как в коде у GM, вводят компилятор в заблуждение, тем и плохи.

[=GM=]

2. Вычисление конца массива/строки ("int2hex3(0xABCD, &hexvalue[digit], digit);") лучше внести внутрь функции.
3. Оператор простановки терминирующего нуля нужен тогда, когда конец строки имеет переменное положение, а здесь он - лишние накладные расходы.
4. Постдекременты - нехорошая практика.
5. Оператор запятая работает с точностью до наоборот, поэтому цикл будет управляться не значением digits, а нибблами value - если value не превышает 15, цикл не исполнится ни разу, от 16 до 255 - один раз и так далее.

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

3. Может и не имеет значения, но digits у автора - это переменная, значит, может принимать спектр значений, скажем от 1 до 8. Если в дальнейшем автор захочет просто распечатать строку, то у него отпечатается не 1-8 символов, а много больше (до 255?), зачем закладывать потенциальную ошибку. В принципе, если завершающий ноль не нужен, то можно вообще отказаться от вызова подпрограммы, а просто вставить такую строчку там, где необходимо:

for(i=digits;i;i--,value››=4) *str-- =hexTable[value & 0x0F];

Да тут вообще можно от i избавиться:

for(;digits;digits--,value››=4) *str-- =hexTable[value & 0x0F]; //в кейле работает

4. Постдекременты и постинкременты - это симметричные операторы, их нужно применять там и так, где это удобно и компактно. Что за запреты такие непонятные?

5. Тут вы немного погорячились. Переменную цикла i никто не отменял, цикл повторяется digits=4 раз. А вот оператор запятая, в данном случае, указывает компилятору проводить вычисления третьего выражения слева-направо, но нам сиё до фени. В приведённом примере видно, что вызов подпрограммы идёт с value=0xABCD=43981 (в десятичке) и, несмотря на ваши предсказания, всё прекрасно работает.

Поскольку в предложенном варианте сдвиг value осуществляется всегда на 4 позиции вправо, то код выполняется быстрее (цикл короче на 2 команды).

К слову сказать, обнаружилось приятное: сдвиг в стмке делается аппаратно на любое количество разрядов. Но если переносить эту программу на другие МК, на чём все немного подвинулись, ну скажем, на 8-битные стм8 или атмеги, то сдвиг 32-х бит value на 28, 24, 20, 16, 12, 8, 4, 0 перерастёт в трагедию о потерянном быстродействии

[Boba_spb]

Да для быстродействия пиши таблицу байт в Hex (всего то 512 байт при нынешних то флешах) и нет сдвигов никаких и счастьяяяяяяяя ... ))
Только с указателяи играйси ))

[tempora]

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

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

но digits у автора - это переменная, значит, может принимать спектр значений, ... отпечатается не 1-8 символов, а много больше (до 255?), зачем закладывать потенциальную ошибку

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

Постдекременты и постинкременты - это симметричные операторы

Вы не поняли, речь о разнице не между inc-/dec-, а между пре- и пост-, а вот они-то совершенно не симметричны.

Тут вы немного погорячились.

Да, не разглядел одну из ';', отчего думал, что выражение с запятой стоит на месте условия цикла:

[Boba_spb]

Господа, компилятор выполняет только то, что написали. Поэтому
while(str[i++]) и while(str[++i]) переводятся в код именно так как Я ХОЧУ !!!

в первом случае взять str[i], инкрементировать i , затем сравнить взятое с 0 и т.д
во втором случае инкрементировать i , взять str[i] , затем сравнить взятое с 0 и т.д И никаких чудес .

Но !!!! - если я доверяю оптимизатору и включаю его, то тут он и начинает изголяться. И код будет сгенерирован уже в зависимости от качества оптимизатора.
Так что симметричность "пре" и "пост" - это вопрос к оптимизации.
У всех компиляторов отключается оптимизатор !!!