Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

gcc - проблем с оптимизациите.
http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=8528
Страница 1 от 1

Автор:  Цецо [ Сря Фев 09, 2011 10:56 am ]
Заглавие:  gcc - проблем с оптимизациите.

Имам следния код:

Код:
/* LCD is connected to the FSMC_Bank1_NOR/SRAM1 and NE1 is used as ship select signal */

#define LCD_REG   *((u16*)0x60000000)
#define LCD_RAM *((u16*)(0x60000000 + 0x20000))   //A16 is activated by bit 17 because of 16 bit transfer.
...
...
...
//methods for LCD driving

#define WriteReg(REG, VALUE)            { LCD_REG = REG; LCD_RAM = VALUE; }
...
...
...
WriteReg(0xE5, 0x8000); /* Set the internal vcore voltage */
WriteReg(0x00, 0x0001); /* Start internal OSC. */
WriteReg(0x01, 0x0000); /* set SS and SM bit */
WriteReg(0x02, 0x0700);   /* set 1 line inversion */
WriteReg(0x03, 0x0030); /* set GRAM write direction and BGR=0. */
WriteReg(0x04, 0x0000); /* Resize register */
WriteReg(0x08, 0x0202); /* set the back porch and front porch */
WriteReg(0x09, 0x0000); /* set non-display area refresh cycle ISC[3:0] */
WriteReg(0x0A, 0x0000); /* FMARK function */
WriteReg(0x0C, 0x0000); /* RGB interface setting */
WriteReg(0x0D, 0x0000); /* Frame marker Position */
WriteReg(0x0F, 0x0000); /* RGB interface polarity */
...
...
...


Това е фрагмент от кода управляващ TFT-то, което е закачено на външната шина и се мапва на два адреса от паметта. Играта е просто писане и четене от тия два адреса.

Та докато съм с изключени оптимизации, нещата са ОК. Когато пусна оптимизациите (дори и първо ниво), компилатора съзира (съвсем правилно), че дращя последователно във едни и същи адреси и просто игнорира всичкия код след WriteReg макрос.

Установих че това се лекува като изключа опциите за "dead code elimination" (-fno-dce) и "dead store elimination" (-fno-dse).

1. Има ли по елегантно решение на проблема?

2. Някъде бях чел че не било добра идея да се пуска различна оптимизация на различни части от кода. Не съм и пробвал. Вярно ли е? Има ли начин да му кажа, че точно тая част от кода, неща да я бара, аз съм си я оптимизирал самичък :)

Въпросния код за ТФТ-то си е в отделен файл.

Автор:  miro_atc [ Сря Фев 09, 2011 11:07 am ]
Заглавие:  Re: gcc - проблем с оптимизациите.

Цецо написа:
1. Има ли по елегантно решение на проблема?



излагаш се....

Код:
#define LCD_REG  *((volatile u16*)0x60000000)
#define LCD_RAM  *((volatile u16*)(0x60000000 + 0x20000))   //A16 is activated by bit 17 because of 16 bit transfer.

Автор:  Цецо [ Сря Фев 09, 2011 11:16 am ]
Заглавие: 

Ми излагам се #-o Пробвах го вчера на уморена глава - и не стана. И понеже ми беше писнало, така и не се замислих що.

Днес стана :)

Предполагам, че от много проби съм овапцал и нещо друго. Най вероятно подредбата на "квалификаторите". :) Днес като поизчистих нещата и стана... логично. Интересен въпрос е и що въобще на входно изходен адрес съм пропуснал volatile.... Бързане, срокове, тъй ще е. :axe:

Както и да е въпроса си остава:

1. Има ли начин да се влияе на оптимизациите от препроцесора (прагма някаква си)?

2. Умно ли е да се компилрат части от кода с различни оптимизации (изключваме проблемите с дебъга) ?

Автор:  ДедоБоре [ Сря Фев 09, 2011 11:28 am ]
Заглавие: 

има прагма за оптимизация, разбира се
Код:
#pragma GCC optimize

но е за препоръчване да ползваш атрибутния механизъм на функциите
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

Автор:  miro_atc [ Сря Фев 09, 2011 11:31 am ]
Заглавие: 

Цецо написа:
1. Има ли начин да се влияе на оптимизациите от препроцесора (прагма някаква си)?


В последните версии добавиха прагма за оптимизация на ниво функцуя цък
но първо провери ти с коя версия си...
едит: Дедо ме е изпреварил ;-)

Цитат:
2. Умно ли е да се компилрат части от кода с различни оптимизации (изключваме проблемите с дебъга) ?


Не знам дали е умно, но се налага (като почне да не ти стига флаша примерно). Но аз го правя на ниво файлове, даже по-точно ниво библиотеки, щото съм си разцепил проекта на библиотечки. Така не се налага да прекомпилирам всичко постоянно, само нещата дето бъзикам. И тях обикновено си ги компилирам с дебъг а другото не.

Автор:  Цецо [ Сря Фев 09, 2011 11:40 am ]
Заглавие: 

Ясно. Моя компилатор не подържа тая прагма, но пък работи по бързо от новия, така че без нея:)

Атрибути на функции - ясно.

Компилация на различни парчета от кода с различни оптимизации - ами аз честно казано не виждам какъв точно е проблема (ама някъде го бях чел). Е сигурно може и да има проблем в някой частни случаи.

Библиотизирането на части от кода си е полезно занимание. Ама предвид хаоса в главата ми е трудно изпълнимо. Все се сещам да дооизкосурявам. :) Ама аз никога не съм претендирал да съм програмист по призвание :)

Автор:  miro_atc [ Сря Фев 09, 2011 12:14 pm ]
Заглавие: 

В библеотеченето няма нищо сложно. Библеотеката е просто няколко обектни файла слепени в един. Това не касае компилирането, щото компилатора пак си прави обектните файлове, не касае и линкването щото линкера пак си работи с обектни файлове.
Реално може да направиш същото нещо и без библиотеки, ако компилираш на част - веднъж една част от проекта, после друга и т.н. Дали ще групираш о-файлове в един а-файл няма никакво значение, това е просто за удобство.

Иначе има смисъл да "нацепиш" един проект на части само ако обичаш да "доизкусуряваш" в последствие. Особено ако някои части ползваш в повече от един проект. Така доизкусурявайки една част от един проект, доизкусуряваш и останалите проекти дето ползват тая част. Иначе ако примерно ползваш това LCD в няколко проекта и откриеш бъг, трябва да ходиш по всичките да го оправиш навсякъде.

Чисто технически цепенето става супер лесно. Особено ако ползваш моя стар мейкфайл, трябва само да го ъпдейтнеш, а и за библиотечките да укажеш кои хедъри да се експортират. Абе просто е. По-сложното е да измислиш на колко и какви части има смисъл да си цепиш проекта ;-)

Автор:  Цецо [ Сря Фев 09, 2011 2:06 pm ]
Заглавие: 

Е да де. Нали ти казвам, че в главата ми е малък хаос. Много рядко ми се случва да докарам код до ниво да го ползвам и другаде без промени. Непрекъснато нещо ровичкам. Вероятно защото не съм програмист по природа и подсъзнателно се мъча да напасна нещата до максимум към хардуера. Което в крайна сметка винаги води до непреносим код. Което не е за гордост.... ама който не му харесва да си наеме програмисти.

Та библиотеченето има смисъл при преносимост на кода. Иначе - все тая дали ще компилирам на части или на библиотеки.

Автор:  Реконструктор [ Чет Фев 10, 2011 10:51 pm ]
Заглавие: 

ДедоБоре написа:
има прагма за оптимизация, разбира се
Код:
#pragma GCC optimize

но е за препоръчване да ползваш атрибутния механизъм на функциите
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes


Точно и аз за прагмите си помислих, 100% има такава за контрол на оптимизиациите.

Автор:  ДедоБоре [ Пет Фев 11, 2011 1:16 pm ]
Заглавие: 

това може да ти е интересно
http://www.ethernut.de/en/documents/arm-inline-asm.html

Страница 1 от 1 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/