EmBitz "Optimize even more (for speed)" !

[ferdem]

EmBitz 1.11 ve STM32F103C8 li mini kit[Çin] ile alıştırmalara başladım. İlginç bir durumla karşılaştım:

  while(1){

GPIOC->BSRR = (1<<13);
for (i = 0; i <= 1000000; i=i+1){
 k=k+1;
}

GPIOC->BRR = (1<<13);
for (i = 0; i <= 1000000; i=i+1){
 k=k+1;
}
}

Bu kodun çalışmasıyla çıkışta yaklaşık eşit sürelerde lojik1 ve lojik 0 olmasını bekliyordum ancak anlamadığım bir şekilde çıkış %99.9 lojik1 de kalıyordu. Debug yaptığımda değişkenlerde "optimize out"  benzeri ibareler görünce compiler ın optimizasyonuna bağladım. "Build options" "optimization" kısmında (default)işaretli olan birkaç tikten "Optimize even more (for speed)" seçeneğini kaldırınca düzeldi.
"Default" olarak bu seviyede optimizasyon bana ilginç geldi, not olarak düşeyim dedim. Bilmiyorum, normal mi sizce?

[Elektroemre]

Kullanılmayan değişken ve döngüleri derleyicilerin optimize etmesi normal hocam. Eğer yaptığınız işlerin bu optimizasyonlardan etkilenmediğinden emin olmak isterseniz değişkeni "volatile" tanımlayın. Optimizasyonlar açıkkende normal çalışması lazım.

[Zoroaster]

While komutu pini 1-0 yapan satırlardan sadece birisine ek gecikme getiriyor.

Süreleri Eşitlemek için araya (LOG) laf olsun gecikmesi ekle.

[MrDarK]

While komutu pini 1-0 yapan satırlardan sadece birisine ek gecikme getiriyor.

Süreleri Eşitlemek için araya (LOG) laf olsun gecikmesi ekle.

Laf olsun gecikmelerindeki favorim; Bu sayede optimizasyon yaptığında bile bu komutu işlemek zorunda kalıyor.

asm("nop");

[muhittin_kaplan]

debug yaparken neden optimizasyona ihtiyacınız oluyor ?

[MrDarK]

debug yaparken neden optimizasyona ihtiyacınız oluyor ?

Arkadaş default olarak bu ayarda gelmiş diye açıklama yapmıştı hocam.

Lakin dediğiniz senaryo ile ben karşılaşıyorum. MCU'nun hafızası 128K, kendi uygulamamın debug'lu hali 160K'lara gittiği için optimizasyon uygulayıp debug yapmak zorunda kaldığım oluyor.
Zor oluyor ama oluyor

[ferdem]

Zoroaster dediğinizi anlıyorum ama ben farklı bir durumdan bahsetmiştim. Verdiğim kodda for döngüleri güme gidiyor, hiç işletilmiyor. k değişkenini dışarda bir yerde kullansaydım veya Emre hocanın söylediği gibi volatile tanımlasaydım durum farklı olabilirdi.

Muhittin hocam kodu karta yükleyip(default ayarlarla optimize edilmiş kodu) denemiştim problem görünce "release" modda "break point" koyarak gözledim bu durumu. Eğer debug modda çalıştırsaydım optimize olmayan kod mu koşturulurdu? Eğer öyleyse o da ayrı problem bak şimdi...

Cevaplar için teşekkür ediyorum.

[Zoroaster]

Değişkenleri volatile tanımlamak lazım.

[muhittin_kaplan]

Hocam bununla alakali bir kural varmidir bilmiyorum. Ama ben nezaman optimizasyon yapilan bir kodu debug etsem ve adim adim calistirsam, anlamsiz (aslinda olusturulan koda gore sirali) satirlara atliyor. Bu yuzden uzun zamandir kod release olmadan optimizasyon yapmiyorum.

[Elektroemre]

Örneğin arm mimarisinde şartlı komut işleme var.  (muhtelemen pipeline dağılmasın diye böyle bir güzellik yapmışlar)

if(a == b)
{
  c = d;
}

gibi bir kod yazınca, bu "c = d" kısmına break point koyunca şenlik başlıyor.

Kod sürekli buradaki break pointe düşüyor (şart gerçekleşsede gerçekleşmesede). Şart gerçeleşmeyince atama işlemini yapılmasada arka planda derleyici bu satır için şartlı işleme asm komutu kullandığı için her seferinde cpu buradan geçiyor.