На 16-битном микропроцессоре я должен использовать тип данных short вместо int?

Question

Я читал, что использование short против int фактически создает неэффективность для компилятора, так как ему необходимо использовать тип данных int независимо от целочисленного продвижения на языке C.Верно ли это для 16-разрядных микропроцессоров?

Еще один вопрос: если у меня есть массив 1 и 0, наиболее эффективно ли использовать uint8_t или unsigned char в этом 16-разрядном микропроцессоре?Или все еще есть проблема с его преобразованием обратно в int ..

Пожалуйста, помогите мне прояснить эту грязную проблему в моей голове.Спасибо!

Answer 1

1. Это действительно проблема? На большинстве 16-битных систем, о которых я слышал, int и short имеют одинаковый размер (16 бит), поэтому на практике не должно быть различий.

2. Если в системе существует uint8_t, это будет синонимом unsigned char. unsigned char будет самым маленьким типом без знака, доступным в системе. Если оно больше 8 бит, не будет uint8_t. Если оно меньше 8 бит, значит, оно нарушает стандарт. Разницы в эффективности не будет, поскольку одно должно определяться в терминах другого.

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

Answer 2

На Blackfin, вероятно, непросто ответить, будут ли 32 или 16-битные типы генерировать более высокую производительность в целом, поскольку он поддерживает 16-, 32- и 64-битные инструкции и имеет два 16-битных MAC.Это будет зависеть от операций, но я полагаю, что вы доверяете своему оптимизатору компилятора принимать такие решения, он знает больше о сроках и расписании инструкций процессора, чем вы, вероятно, заботитесь.ваш компилятор int и short в любом случае имеют одинаковый размер.Обратитесь к документации, не тестируйте с sizeof или посмотрите в заголовке limits.h числовые диапазоны, которые будут определять ширину или различные типы.

Если вы действительно хотите ограничить размер типа данных, используйте stdint.h типов, таких как int16_t.

stdint.h также определяет самые быстрые целочисленные типы минимальной ширины , такие как int_fast16_t, это гарантирует минимальную ширину, но будет использовать больший тип, если он будет быстрее на вашей цели,Это, вероятно, самый переносимый способ решения вашей проблемы, но он зависит от разработчика, который принял правильные решения относительно подходящих типов для использования.На большинстве архитектур это мало что меняет или не меняет вообще, но на архитектурах RISC и DSP это может быть не так.Также не может быть так, что конкретный размер является самым быстрым при любых обстоятельствах, и это, вероятно, особенно верно в случае Blackfin.

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

Answer 3

На 16-разрядном или более мощном процессоре, если вам все равно, сколько места займет хранилище, используйте int вместо short или char со знаком. Если вас не интересуют требования к хранилищу или поведение переноса, используйте «unsigned int» вместо «unsigned short» или «unsigned char». На 8-битном процессоре типы 'char' могут быть быстрее, чем 'int', но на 16-битных и более крупных процессорах, где 16-битная математика быстрее, чем 32-битная математика, 'int', вероятно, будет 16 бит, поэтому нет необходимости использовать «short» или «char» для скорости.

Кстати, на некоторых процессорах «unsigned short» намного медленнее, чем «unsigned int», потому что стандарт C требует, чтобы операции с типами без знака «wrap». Если в регистре хранится короткая переменная без знака "foo", типичный компилятор ARM генерирует код для "foo + = 1;" сгенерирует одну инструкцию для выполнения приращения и две инструкции для усечения значения до 65535 [BTW, оптимизирующий компилятор, который заметил, что 'foo' никогда не может превышать 65536, может сбрить инструкцию, но я не знаю, будет ли какой-либо реальный компилятор ]. Подписанное short не должно быть медленнее, чем подписанное int, так как стандарт не требует усечения; Однако я не уверен, что какие-либо компиляторы пропустят усечение для подписанных типов.

Answer 4

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

typedef uint8 char
typedef uint16 short
typedef uint32 long

Для любых типов данных.

Любые проблемы преобразования должны быть определеныво время компиляции.Они будут зависеть от процессора и компилятора.

Конечно, добавление 2-х 32-битных чисел на 16-битном процессоре повлечет за собой некоторую путаницу со стороны компилятора.Могут также быть забавные вещи, когда вы загружаетесь из памяти, в зависимости от ширины слова памяти и от того, можете ли вы загрузить с любого адреса, или если байты должны быть загружены с заданной границы

In shortYMMV и оптимизировать после профилирования.