Размер unsigned int или int Keil4.5 Опции

[TAutomatic]

Добрый день, коллеги.
Месяц использую LPC1768 и только сейчас с "ужасом" заметил, что под переменные unsigned int и int компилятор отводит по 4 байта.
Использую среду Keil 4.5 и постоянно плююсь даже не по причине ее скудости, а по причине неудобности документации на нее и компилятор. Как установить "нормальный" размер этих типов данных размером в 2 байта?
И второй вопрос. Я был уверен, что в Cortex-M3 отсутствует необходимость выравнивания разноразмерных типов данных.
Об этом написано тут
Тем не менее, у себя в реале я этого не вижу. Если за однобайтовой переменной следует четырехбайтовая, то она все равно выравнивается по границе 32 разрядного слова, тоесть остается неиспользуемый промежуток в 3 байта. Что тут не так?

[andrewlekar]

Ребята, я вас умоляю, не делайте так в рабочем коде. Придёт после вас человек и не поймёт нифига, что вы там наоптимизировали.

[TAutomatic]

Ребята, я вас умоляю, не делайте так в рабочем коде. Придёт после вас человек и не поймёт нифига, что вы там наоптимизировали.

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

Герберд Шилдт. Полный справочник по C. (в электронном виде не имею на русском языке, в книжке на русском еще понятнее).
Page 144 - 145

Все правильно, спасибо за цитату Теперь попытаюсь Вам концептуально разъяснить в чем дело. Язык С был создан в эпоху микропроцессоров, у которых память была сегментирована. Это процессоры чуть до Intel286 и 386 и в том числе эти процессоры. Так вот, что бы получить доступ к исполнительному адресу, нужно было еще опереровать с сегментным регистром. Вполне вероятно, что два массива по 10 байт оказались бы на границе сегмента. Физически это последовательные адреса, но вот логические уже нет. И тогда последовательное обращение к 20 байтам на самом деле бы привело не к обращению к двум последовательным массивам, а в пределах одного секмента 64кБ. Давайте жить реалиями сегняшнего дня. В основном все уже имеют дело с микроконтроллерами с линейным адресным пространством. В пределах этого пространства компилятор не занимается перестановкой переменных и оптимизацией их размещения, если на то нет особых инструкций, указаний и т. д. Тоесть, компилятор оптимизирует код с обязательным требованием сохранения его идентичности по функционалу исходному коду и не занимается оптимизацией памяти данных

[Dron_Gus]

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

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

Более того, при определенных настройках тот же GCC может перекладывать данные из секции .data в .bss

[TAutomatic]

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

Более того, при определенных настройках тот же GCC может перекладывать данные из секции .data в .bss

Послушайте, чесговоря нет времени на такого рода диспут, но когда пишут совершенно непонятные для меня вещи, хочется всегда спросить: откуда вы это взяли?!!! Ну откуда вы взяли что время доступа может быть разны, если переменные размещаются в ОЗУ? Мы же не ведем речь о переменных и сразу о константах, которые размещаются в адресном пространстве кода? Ну я вот хочу знать того, чего не знаю. Покажите мне не на пальцах, а на конкретном примере. И еще, какие такие настройки компилера позволят две однородные переменные без инициализации на стадии линковки или обе с инициализацией, расположенные в одном программном модуле последовательно друг за другом разнести по разным секциям? Пожете показать, как Вы это делаете?

[jcxz]

Ну откуда вы взяли что время доступа может быть разны, если переменные размещаются в ОЗУ? Мы же не ведем речь о переменных и сразу о константах, которые размещаются в адресном пространстве кода? Ну я вот хочу знать того, чего не знаю. Покажите мне не на пальцах, а на конкретном примере.

Позвольте встрять?

Кроме внутреннего ОЗУ, к контроллеру может быть подцеплено внешнее, с другим временем доступа.
Даже если есть только внутреннее, то в некоторых процессорах есть разные RAM с разным быстродействием, расположенные на разных шинах.
Или, к примеру: внутреннее ОЗУ разбито на банки (непрерывно расположенные в адресном пространстве), и одна из переменных - в одном банке, другая - в другом, а во второй банк как раз идёт интенсивное DMA (с приоритетом контроллера DMA) - здесь разница во времени доступа может быть ОЧЕНЬ большой.
Даже если банки ОЗУ в несмежных областях - линкер (при соотв. опциях) может разбить выходные секции на неск. несмежных областей.
Для каких-то областей может быть включено/выключено кеширование.
Или (типичная оптимизация IAR for ARM): функция работает с неск. статическими переменными - IAR заносит в некий базовый регистр указатель на область памяти, которая включает большую часть этих переменных и адресует их через этот базовый + смещение, а одна переменная - далеко от остальных, разрядности смещения не хватает и для обращения к ней компилятору приходится вставлять доп. инструкции загрузки адреса этой переменной в регистр - соответственно доступ к этой переменной будет дольше.

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

[TAutomatic]

Позвольте встрять?

Кроме внутреннего ОЗУ, к контроллеру может быть подцеплено внешнее, с другим временем доступа.
Даже если есть только внутреннее, то в некоторых процессорах есть разные RAM с разным быстродействием, расположенные на разных шинах.
Или, к примеру: внутреннее ОЗУ разбито на банки (непрерывно расположенные в адресном пространстве), и одна из переменных - в одном банке, другая - в другом, а во второй банк как раз идёт интенсивное DMA (с приоритетом контроллера DMA) - здесь разница во времени доступа может быть ОЧЕНЬ большой.
Даже если банки ОЗУ в несмежных областях - линкер (при соотв. опциях) может разбить выходные секции на неск. несмежных областей.
Перетасовка переменных оптимизатором - это большой гуд. ПО не должно привязываться к взаимному расположению переменных (конечно это не касается внутри структур).

Рабята, ну я Вас умаляю... Ну Вы что, читать не умеете? Я же ясно написал, две переменные, одинаково объявленные и т.д. Вам, что, все это пустой звук или есть просто желание поговорить? Две переменные, объявленные одинаково уж точно не могут попасть одна во внутреннее ОЗУ, вторая во внешнее, что бы иметь разное время доступа. Ну кто этого не понимает? Все остальное и комментировать нет смысла. Вам уже aaarrr выше в этой теме написал - размещение переменных, в том числе акккуратность этого размещения- это задача программиста. И я в этом согласен. А вот аккуратностью размещения кода занимается компилятор, а затем оптимизатор. Об этом даже в Википедии почитать можно. Там нет ни слова об оптимизации данных. Судя по-всему, никто из написавших выше никогда не проверял, что же реально компилятор и оптимизатор творят с переменными, но, основываясь на каком то внутреннем понимании этого процесса пытается утверждать, что так оно и есть.

[ViKo]

занимается компилятор, а затем оптимизатор. Об этом даже в Википедии

Покажите, где написано (в Википедии, или еще где-то), что есть некий зверь, именуемый "оптимизатором", который занимается размещением то ли кода, то ли данных.

[jcxz]

Покажите, где написано (в Википедии, или еще где-то), что есть некий зверь, именуемый "оптимизатором", который занимается размещением то ли кода, то ли данных.

Википедия это конечно АВТОРИТЕТ! Любой TAutomatic знает