Я с ARM еще не работал, но у меня появились вопросы.
Если обьявить массив типа unsigned char в ОЗУ
сколько будет занимать один элемент в памяти?
Можно ли сделать так, чтобы он занимал 1 байт?
Если нет, то как легче всего это сделать программно.

все зависит от контроллера памяти и самой памяти где будет массив

Сообщение отредактировал SergeyDDD - Feb 8 2007, 11:24

Ну например для AT91SAM7S64, если разместить во внутреннем ОЗУ?

При компиляции программы можно указать ключи для выравнивания переменных на границу одного, двух или четырёх байт. Например, при использовании компилятора ICCV7 (Imagecraft) для процессоров ADuC702x и LPC21xx байтовые переменные занимают в памяти 1 байт.

Как правило внутреннее ОЗУ поддерживают операции с байтами
А вообще это справочная информация. См. документацию.

А еще проще сходу попробовать на железе

по-моему ерунду говорите. Массив всегда будет расположен ЛИНЕЙНО. Точка. И один char в массиве всегда занимает один байт
PS "по-моему" добавлено только для смягчения фразы, но никак не по причине наличия сомнений ;-)

Почему же ерунду? Проблема может возникнуть с железом, а не с компилятором.
Для примера возьмем EP7312:
ширина шины данных управляется линиями HALFWORD и WORD (думаю назначение понятно).
Для 32 разрядной шины используются линии адреса начиная с A2.
Так вот в такой конфигурации записать байт можно только по адресам 0, 4, 8, 12, 16...

А вот с SDRAM памятью и внутренней (в EP7312) такой проблемы нет.

Значит компилер будет считывать 32-битное значения и выдирать сам байиы, если я правильно Вас понял. Массив в любом случае по адресам будет лежать слитно, иначе вся арифметика указателей летит к чертовой матери вместе с Керниганом и этим.. как его.. Ритчи

Тут уж, наверно, не компилер, а сам процессор.

не важно кто, важно что для программисты массив линеен без разрывов, и заботиться не надо. Заботиться надо в union когда char или short в него входит и , одновременно, рассматривается как массиы. Тогда pragma pack(1) конечно

Сколько текста!
Сколько времени потрачено!
Неужто в облом написать пример в четыре строки, собрать и посмотреть листинг?

Вы оба неправы, господа. Этим занимается аппаратно контроллер памяти (неважно какой, SDRAM, SRAM, DDR) - все эти дела совершенно прозрачны для программиста и для процессора, исполняющего команды программиста.
Обратите внимание - несмотря на то, что разрядность шины данных процессора увеличивается (от 8 битных 8088, далее через 16 битные 8086/80286, через 32 битные 80386/Pentium-ы, а теперь есть и 64 битные ...) - ПО КАЖДОМУ АДРЕСУ ПАМЯТИ ЛЕЖИТ РОВНО ОДИН БАЙТ !!!
С точки зрения любого процессора (и программиста) физическая память является линейной структурой байтов, адрес каждого байта уникален и отличается от адреса предыдущего и последующего ровно на единицу.
32 разрядный процессор "хочет" загрузить себе в регистр один байт из адреса 0x123456FF, и его совершенно не волнует, каким образом внешняя память "исполнит его желание". Более того, проц не обязан "знать", что за память расположена по этому адресу. Дальнейшие действия целиком и полностью возложены на контроллер памяти, который всё это "знает". Если память 32 разрядная - будет выполнено ДВА цикла чтения - один по адресу 0x123456FC, другой по адресу 0x12345700, а оставшиеся два младших бита в исходном адресе будут определять, как расположить считанные 8 байт на 32 разрядной шине так, чтобы процесоор "почувствовал", будто он и вправду считал двойное слово с адреса 0x123456FF.
ДВА цикла чтения заменятся на ОДИН цикл в одном случае - если адрес кратен 4. Поэтому у программиста (который, в отличие от процессора, знает свою архитектуру аппаратной части) есть выбор - указать компилятору, как предпочтительнее располагать данные в памяти (align). Хочется сэкономить память - указывай align=1, но тогда при доступе к 3 элементам из 4 будешь "попадать" по времени на ДВА цикла чтения; если памяти море - указывай align=4 (вроде как это по умолчанию), тогда каждый объект массива char будет лежать "как король" в адресах, кратных 4, чтобы не тратить лишнее время на доступ к нему.
Если контроллер памяти очень "умный" - он может сильно ускорять процесс считывания, например, вести кэш, и недавно считанное значение не считывать заново, или при доступе по определённым адресам на чтение/запись генерировать исключения и т. п. Часть этих функций современные процессоры типа Pentium взяли себе на борт (кэш первого уровня, защита памяти и генерация исключений и т п), часть оставили снаружи (кэш второго уровня, разделение RAM/ROM).

ну я собсно и сказал - по барабану кто будет делать, главное что программисту пофик. Зачем забивать себе голову лишними знаниями?

А вот это кто сказал ?

Массив char в физической памяти будет лежать так, как на это указывает #pragma pack, то бишь выравнивание, если 4, то каждый элемент массива будет расположен с адреса, кратного 4, то есть занимать 4 байта.
И Керниган с Ритчи тут ни при чем. И арифметика указателей в порядке. Если Вы прибавите к указателю единицу, прибавка к адресу в машинном коде составит много больше - это зависит от размера элемента, на который указывает этот указатель и от выравнивания. Это уже работа компилятора.
А вот преобразование некратных адресов в адреса памяти (то, о чем я писал в пред. посте) - это работа контроллера памяти.
Это разные и совершенно не связанные вещи.

Ну я то под процессором имел ввиду сам мк, а не собсвенно алу, но за ликбез спасибо. ж)