Размер 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

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