Есть функция:
//====================================================
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.

Сообщение отредактировал alx2 - Jul 24 2009, 10:46

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

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." Понять это можно по-разному. Но если это понимать так, что у однобайтовых аргументов функции при входе в функцию обязательно надо отсекать лишние биты, то это приведёт к менее компактному и более медленному коду. Кому это надо? Тому разгильдяю, который не хочет инициализировать переменные? Я думаю, не следует идти у него на поводу.

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