Есть функция:
//====================================================
void LoadLastByte(Xuint8 Data)
{
Xuint32 d=0xFFFFFD00 + Data;
xil_printf("LoadLastByte - %x; Data - %x\r\n",d,Data);
GENERAL_SIMPLE_IO_32_mWriteSlaveReg3(XPAR_CTRLTEMAC_BASEADDR,0,d);
}
//====================================================

Есть вызов этой функции:
//====================================================
Xuint8 i;

LoadLastByte(i);
Переменная не инициализирована...
Результат следующий:

LoadLastByte - FFFF2444; Data - FFFF2744

Вопрос: Если переменная Xuint8 Data - один байт, то почеу значение - FFFF2744?
заранее спасибо.

Проинициализируйте и не занимайтесь буйней, простите за грубость, иначе Вас могут поджидать еще и не такие перлы. Если же Вас интересует точное поведение компилятора в этом случае, то курите асмовский листинг.

Сдаётся мне, надо написать
xil_printf("LoadLastByte - %x; Data - %x\r\n",d,(int)Data);

Это компилятор сам приведет. А вот что творится из-за отсутствия инициализации переменной - это никому не известно.

Для printf - нет. Ну и всяко в байт, пусть даже трижды неинициализированный, FFFF2744 не влезет

---
Поправка. Надо писать (Xuint32)Data. Потому что %x.

Во-первых, будет приведен к int'у. Курите передачу параметров в функции с (...) в параметрах.



Вы на тему посмотрели? Там тип проца указан. Регистры там 32хбитные. А вот в какой момент избавляться от мусора (т.е. вставлять расширение знака или просто and) - это уже компилятор сам решать должен. И в данном контексте смысла компилятору вставлять какое-либо приведение нету.

Вы хотите сказать, что при вызове LoadLastByte(Xuint8 Data) компилятор имеет право передавать в старших байтах аргумента всякий мусор?

Неа. Он передает там нолики (т.к. это unsigned). Но, т.к. переменная неинициализированна, то он имеет полное право забить болт на этот and. Например, считая, что в регистр уже загруженно правильное значение, не превышающее 256 (если бы перед этим была загрузка непосредственного значения или LBZ из озу).

Как определен тип Xuint32? Очень похоже на несоответствие типа, требуемого строкой формата, реальному типу переменной d.

При компиляции функции неизвестно, инициализированное будет передано значение или нет. Поэтому, по крайней мере при

Xuint32 d=0xFFFFFD00 + Data;

компилятор должен провести расширение Data до Xuint32. Я так думаю.

А то, что вы пишете, очень напоминает работу IAR с bool из вот этой ветки. За единственным исключением - там программист применил хитрый финт ушами, чтобы добиться подобного.

Поэтому я всё же версию с неправильной интерпретацией параметра printf. Ждём топикстартера

ЗЫ. И интересно на всякий случай посмотреть на объявление Xuint8. Вдруг это пресловутый uint_least8_t?

К сожалению, гнуся, да еще и под PPC под рукой нет. Могу показать, как компилит аналогичный код IAR под ARM.





Обратите внимание, несмотря на размер переменной 8 бит (char c), компилятор не собирается прочищать какие-либо битики. Просто так договоренно, что этим занимается вызывающая функция.

Правда вот получить из IAR'а такое-же поведения, как и ожидаемое мной у гнуся, не получается - тот хоть и матом орет на неинициализированную переменную, но ноликом ее прочищает. Правда, на малых уровнях оптимизации он этого не делает, но зато втыкает and с мусорным регистром.

В общем, тут все зависит от поведения компилятора при вызове функции с неинициализированным аргументом. Рубль за сто, что там гнусь с регистром, в котором происходит передача параметра, ничего не делает, что летит только мусор...

Более точно нам может ответить топикстартер, показав асмовский листинг своего творения.



Кстати, тоже вариант

У меня есть под арм (cortex-m3):



Гнусь таки чистит лишние битики.


Ну это тоже вариант. Компилятор гарантирует, что в переменной char старшие биты нулевые. Это уже чёткая аналогия с тем bool. Но чтобы и не гарантировал и не чистил - это как-то коряво, имхо.


Да, будем ждать

Познавательно. Но еще не факт, чего он там на PPC накомпилит. Походу идея с uint_least8_t/uint_fast8_t не лишена смысла. Топикстартер, ауууу!

А я думаю иначе :-) В стандарте написано: "If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate." Понять это можно по-разному. Но если это понимать так, что у однобайтовых аргументов функции при входе в функцию обязательно надо отсекать лишние биты, то это приведёт к менее компактному и более медленному коду. Кому это надо? Тому разгильдяю, который не хочет инициализировать переменные? Я думаю, не следует идти у него на поводу.

Я именно так и написал. Потом, правда, зачеркнул, решил, что сильно грубо

Понимать это надо так, как написано. Значение неопределено. Но в том же стандарте гарантируется, что значения переменной char находятся в диапазоне CHAR_MIN...CHAR_MAX. Если компилятор, вне зависимости от инициализированности переменной, этого не обеспечивает, это - кривой компилятор.
Как он это делает - это его личное дело. Но делать это он обязан.



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

При записи в ОЗУ отсечение происходит автоматически. Кстати, как и при чтении. При регистровых операциях оптимизатор точно выбросит лишние отсечения, которые "не пляшут рояли".



Очень гипотетическая ситуация, в связи с тем, что количество записей обычно меньше количества чтений.



Не надо уподобляться Дохтуру. Он тоже тут измышлял, в каких битах надежнее данные хранятся... Забанили нафиг

Лишь на тех архитектурах, где есть побайтовый доступ к ОЗУ, не правда ли?



Согласен, потому и написал "можно представить", а не "часто встречаются"




Ну, я надеюсь, что я немного более вменяем Я имею в виду, что отсечение при чтении защитит от ситуаций, когда хитрый программист записал что-то в переменную через указатель.
Что до меня лично, я бы не прочь иметь в ГЦЦ ключик, включающий такую оптимизацию

Дык и записал в положенный этой переменной младший байт

Дык! Но и в неположенные старшие мальца попало И если компилятор работает исходя из предположения, что там нули, то будет ой

ЗЫ. Я естественно имел в виду не запись через char*, а некий хак, как в теме про bool.

Вы много знаете архитектур с отсутствием такового?



Посмотрите, каким образом компилятор извлекает, скажем, байтовую переменную из ОЗУ в 32хбитных архитектурах. Например, для ARM он пользуется LDRB, что приводит к автоматическом маскированию старших бит. На PPC есть аналогичная команда LBZ.

Вот я уже правда не помню (давно не брал я в руки шашек), на большом индейце всех времен и народов (680x0) команда загрузки байта из ОЗУ в регистр типа move.b (Ax),Dy кажется не приводит к прочистке старших бит, посему там надо использовать ext.b Dy после загрузки.



Да откуда же возьмутся после загрузки с расширением (одной командой в ARM или PPC, или парой в 680x0) там не нули?