Столкнулся с проблемой. Сразу отмечу, что понимаю её корни и вижу несколько способов решения, но мне непонятно почему компилятор так поступает. Кто объяснит.

Смысл следующий. Я размещаю несколько массивов типа


и так далее ...
Потом объявляю массив ...


Поскольку массивы идут попорядку, то я ожидал, что компилятор их и разместит попорядку во флэши. Причём в результирующем HEXе для AVR так и происходит. А для ARM7 компилятор разбрасывает массивы как хочет.

Почему это происходит?

Я бы хотел, чтобы они шли подряд. Как вариант вижу объединить их в структуру. Но непонятен мотив компилятора. Он что так место пытается экономить? Типа дырки забивает - так вроде не видно...

Кто подскажет?

PS: Проблема несколько сложнее чем показалось с первого взгляда. Размеры массивов разные и объединить их в структуру не очень удобно. Придётся явно объявлять их длину. А мне это делать очень неудобно. Они будут меняться от реализации к реализации. Высчитывать - нет желания. Хотелось бы простое и крассивое решение. Как компилятор заставить распологать массивы по порядку?

Есть предположение, что виноваты оптимально размещенные stubs

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

Потому что стандарт С не обязывает компилятор к размещению переменных в порядке их объявления.




Помочь может, но это будет частный случай. В общем случае гарантии нет.

Это понятно - претензий нет. А зачем он это делает? Дырки оптимизирует, которые при выравнивании остаются?
Может тогда достаточно сделать выравнивание на границу байта в начале массивов и вернуть к исходному в конце?

Ладно. Зайдём с другого конца. Может кто-нибудь предложит решение красивое.
Задача такова.
Имеется несколько массивов. Они находятся во флэш, но в то же время я их меняю иногда. Не хотелось бы чтобы изменение массивов в тексте программы требовало вмешательство ещё куда-нибудь. Массивы разной длины. В программе мне надо знать начало этого массива и его конец. Я брал указатель на начало массива 1, а в качестве конца использовал указатель на начало массива 2. Дырка, заполненная 0 или ff, к примеру, меня не беспокоит.

Как красиво и правильно это реализовать? Так чтобы я поменял, к примеру, массив в готовой проге, и она осталась полностью работоспособной.

Например, так (С++):

При этом CAN_J1939_TAG_COUNT - это константа во flash.
Если она нужна только в этой единице компиляции, то можно сделать static, и она будет прямо подставлена. Или используйте extern из других файлов.

по моему структура самое правильное решение тут

Глянул - массивы ведь не выровненные на 32 бита. А дырки какого размера?

Почему бы просто дополнительно не хранить длину массива? Жалко 2 байта во флеш?
Ну можно поизвращаться:

Вы же все равно прогу перекомпилируете?
Тогда почему нельзя использовать sizeof?

Наверное так и сделаю. Прогу придётся править.


Любопытно. Так вроде как дважды память будет выделена. Или static не даст? В смысле, если эти массивы не будут в данном файле использованы?

В общем случае это от компилятора зависит. Iar это оптимизирует, большинство других современных тоже скорее всего.
Возникает только warning , который можно в принципе прибить через #pragma
Но, имхо это извращения какие-то.
Я бы создал структуру, состоящую из указатетеля на массив и длины.
А потом бы создал и проинициализировал массив таких структур. Ну или просто, как рекомендовали выше, sizeof() для определения длины.

Мне кажется, проблема надумана.
Желание не указывать длину массива и при этом сохранить работоспособность программы при смене массива как-то не вяжется.
Объявить длины массивов, уложить в структуру. Массив указателей тогда не нужен.