Знатоки Keil подскажите !, Непонятно, но здорово... Опции

[okela]

На днях столкнулся с непоняткой при работе с uVision2.
Собрал проект, всё работает нормально. Исходник остался только последний.
Сравнивал бинарники двух последних версий , размер кода в которых был одинаков и увидел 3 десятка отличий. Стал разбираться и обнаружил смещение на 1 байт адресов глобальных переменных (причем не всех , а где-то начиная с середины ).
Т.е. была убрана одна переменная типа char. Дальнейшие разбирательства показали , что адреса при линковке назначаются переменным каким-то
непостижимым образом . Они не зависят от порядка объявления переменных ,
и даже не зависят от порядка появления в программе.
Но самое странное, что они зависят от.... имён переменных.

Это что глюки компилятора/линковщика или я чего-то недопонимаю ???

[bialix]

Дальнейшие разбирательства показали , что адреса при линковке назначаются переменным каким-то
непостижимым образом . Они не зависят от порядка объявления переменных ,
и даже не зависят от порядка появления в программе.
Но самое странное, что они зависят от.... имён переменных. 

Это что глюки компилятора/линковщика или я чего-то недопонимаю ???

Вы чего-то недопонимаете.

Никто не обещал, что переменные должны лежать в каком-то определенном порядке. Упорядоченно по алфавиту - это я еще могу как-то понять. Если очень хочется, то воспользуйтесь опцией компилятора Keep variables in order - описание эффекта этой опции есть в доке на компилер.

[Stas]

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

[okela]

Никто не обещал, что переменные должны лежать в каком-то определенном порядке. Упорядоченно по алфавиту - это я еще могу как-то понять. Если очень хочется, то воспользуйтесь опцией компилятора Keep variables in order - описание эффекта этой опции есть в доке на компилер.

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

[bialix]

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

Почему это должно так сильно волновать - вот в чем вопрос?

[bialix]

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

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

Если рассматривать эту "проблему" под таким углом зрения, то становится понятным почему в кейле введена опция "Keep variables in order": она включает генерацию дополнительной информации для линкера, по которой он может потом восстановить порядок следования данных в исходном коде.

[okela]

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

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

Если рассматривать эту "проблему" под таким углом зрения, то становится понятным почему в кейле введена опция "Keep variables in order": она включает генерацию дополнительной информации для линкера, по которой он может потом восстановить порядок следования данных в исходном коде.

Благодарю за обстоятельное разъяснение !
Похоже что так оно и происходит.. Было просто интересно разобраться.