| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| ANSI C, гарантирано прочитане на адрес от паметта. http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=12689 |
Страница 1 от 1 |
| Автор: | Цецо [ Пет Фев 14, 2014 3:43 pm ] |
| Заглавие: | ANSI C, гарантирано прочитане на адрес от паметта. |
Въпроса е малко тривиален, ама какъв е гарантирания начин да накараш конпилатора да прочете даден адрес (да изчисти флаг в случая), без да прави нищо друго. .... (void)SPI->DR; .... ще работи ли при всички нива на оптимизации и при всички компилатори? Знам че най сигурно е int a; ... a = SPI->DR; ... Ама това ми се вижда малко глуповато. П.С въпросния регистър си е дефиниран като volatile предварително. |
|
| Автор: | miro_atc [ Пет Фев 14, 2014 4:07 pm ] | |||||||||
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. | |||||||||
значи щом е volatile всяко негово срещане в сорса генерира достъп (четене/писане според контекста (L-value/R-value) специално GCC ти го гарантира и може да го оптимизира само ако срещането е в коментари, или функция дето не се вика 
|
||||||||||
| Автор: | Реконструктор [ Пет Фев 14, 2014 4:16 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
най-сигурно си е asm{} 
|
|
| Автор: | Цецо [ Пет Фев 14, 2014 4:22 pm ] | ||||||||||||||||||
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. | ||||||||||||||||||
Да аз забелязах, че на GCC и SPI->DR; т.е. без (void) отпред също е достатъчно. Предполагам, че и за повечето ембедед компилатори ще е така. Ама се чудех по ANSI C имали нещо твърдо или е компилатор депендент една такава сентенция. Щото съм срещал всякакви творения из нета. |
|||||||||||||||||||
| Автор: | miro_atc [ Пет Фев 14, 2014 4:26 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
задължително махни (void)... това може да преебе volatile-a... |
|
| Автор: | Цецо [ Пет Фев 14, 2014 4:31 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
Абе, че не го преебава... не го преебава, поне на gcc 4.8 Но има идея в това което казваш. Явно няма рецепта. |
|
| Автор: | michev [ Пет Фев 14, 2014 5:00 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
И аз като Реконструктура установих че, няма нищо по - сигурно от това да си напишеш asm(...) и каквото ти трябва вътре, че инъче като мине оптимизатора и доста неща "изчезват" от генерирания код. |
|
| Автор: | Zdrav [ Пет Фев 14, 2014 6:14 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
И аз ползвам този начин: SPI->DR; При всички нива на оптимизации без проблем гарантирано за arm-none-eabi-gcc. |
|
| Автор: | loser [ Пет Фев 14, 2014 10:22 pm ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
SPI->DR; би трябвало да работи... току що си загубих половин час да ровя в последния стандарт http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, за да разбера какво би трябвало да е гарантирано в такъв случай, но то C-стандарта не е като едновремещните C стандарти (какви C стандарти имаше едно време...) - сега на човек му трябва юридическо образование, за да го разбере... абе добре е все още - само 700 страници са, от които реално под 200 са за самия език; за сравнение, това, което намерих за C++ - са около 1300 страници, което ме шокира - на мастит език като C++ би трябвало, си мисля, да му е поне 3000 страници стандарта... както е казал поетът - 'я, какъв голям мафиот, а с каква малка пишка' в случая насилствената смяна на типа с (void) просто няма смисъл - синтактично е правилна, но няма смисъл @Цецо SPI->DR; ще работи, със сигурност - майната му на стандарта, една много проста причина ще дам - виждал съм достатъчно комерсиален код, който ползва точно твоята конструкция, за точно твоята цел (в интерес на истината, почти всичко, което съм виждал, е било с '(void)' отпред, явно е някак си романтично така да се пише); ако производителите на компилатори променят това поведение - жална им майка... да речем, че който плаща - той поръчва музиката за протокола прилагам някои остроумни извадки от стандарта, докато се рових: ------------------------------------------------------------------ 5.1.2.3 Program execution 1 The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant. ... 2 Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, 12) which are changes in the state of the execution environment. Evaluation of an expression in general includes both value computations and initiation of side effects. Value computation for an lvalue expression includes determining the identity of the designated object. ... 6 The least requirements on a conforming implementation are: — Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine.... ... 3 An assignment operator stores a value in the object designated by the left operand. An assignment expression has the value of the left operand after the assignment, 111) but is not an lvalue. The type of an assignment expression is the type the left operand would have after lvalue conversion. The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands. The evaluations of the operands are unsequenced. ... 111) The implementation is permitted to read the object to determine the value but is not required to, even when the object has volatile-qualified type. ... 7 An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. 134) What constitutes an access to an object that has volatile-qualified type is implementation-defined. ... 134) A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be ‘‘optimized out’’ by an implementation or reordered except as permitted by the rules for evaluating expressions. ------------------------------------------------------------------ не ми стигнаха нервите, да търся какви са точно правилата за изчисление на изрази... |
|
| Автор: | woody [ Пет Фев 14, 2014 11:44 pm ] | |||||||||
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. | |||||||||
Ама и писанки. "void" в случая е само наследство да не дава warning, понеже следното са легални конструции:
Предупреждението е за израз без страничен ефект (когато няма volatile вътре). Някъде/някога беше решено че израз cast-нат до void не трябва да дава warning. В случая с volatile може и да се пропуска. |
||||||||||
| Автор: | miro_atc [ Съб Фев 15, 2014 1:17 am ] | |||||||||
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. | |||||||||
Няма защото "->" има приоритет пред тайпкаста, т.е. имаш volatile указател, от който се извлича някаква стойност от тип int, който ти кастваш до void. И вълкът сит и агнето цяло По-горе колегата е цитирал стандарта, последната точка пише черно на бяло, че действията с volatile типове не могат нито да се спестяват, нито да им се променя последователността. В случай че последователността не е ясна GCC те предупреждава А с кастванията пак ти казвам, не ги прави ако не си сигурен че трябва Действително се слага каст до войд, за да няма предупреждения за излишен израз, обаче ако ти даде това предупреждение значи си забравил volatile-a...
|
||||||||||
| Автор: | Цецо [ Съб Фев 15, 2014 9:51 am ] |
| Заглавие: | Re: ANSI C, гарантирано прочитане на адрес от паметта. |
Мерси. Спах спокойно
|
|
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|
