Geliştirme ve hata ayıklama aşamalarında gerçekten iyi bir devre dışı bırakma optimizasyonu mu?

C'de 16-Bit PIC Mikrodenetleyicileri Programlama'yı okudum ve kitapta bu onaylama var:

Bununla birlikte, bir projenin geliştirme ve hata ayıklama aşamalarında, analiz edilen kodun yapısını değiştirebilecekleri ve tek adım ve kesme noktası yerleşimini sorunlu hale getirebilecekleri için tüm optimizasyonları devre dışı bırakmak her zaman iyi bir uygulamadır.

İtiraf ediyorum biraz kafam karıştı. Yazarın C30 değerlendirme dönemi nedeniyle mi yoksa gerçekten iyi bir uygulama olup olmadığını söylediğini anlamadım .

Bu uygulamayı gerçekten kullanıp kullanmadığınızı bilmek istiyorum, neden?

Bu, bir bütün olarak yazılım mühendisliğinde oldukça standarttır - kodu optimize ettiğinizde, derleyicinin, herhangi bir işlem farkını söyleyemediğiniz sürece, işleri istediği gibi yeniden düzenlemesine izin verilir. Bu nedenle, örneğin, bir döngünün her yinelemesinin içinde bir değişkeni başlatırsanız ve döngünün içindeki değişkeni asla değiştirmezseniz, optimize edicinin bu başlatmayı döngüden çıkarmasına izin verilir, böylece onunla zaman kaybetmezsiniz.

Ayrıca, üstüne yazmadan önce hiçbir şey yapmadığınız bir sayıyı hesapladığınızı fark edebilir. Bu durumda, işe yaramaz hesaplamayı ortadan kaldırabilir.

Optimizasyondaki sorun, optimize edicinin taşıdığı veya ortadan kaldırdığı bir kod parçasına bir kesme noktası koymak isteyeceğinizdir. Bu durumda, hata ayıklayıcı istediğinizi yapamaz (genellikle kesme noktasını yakın bir yere koyacaktır). Bu nedenle, oluşturulan kodu yazdıklarınıza daha yakından benzetmek için hata ayıklama sırasında optimizasyonları kapatırsınız - bu, kırmak istediğiniz kodun gerçekten orada olmasını sağlar.

Buna dikkat etmelisiniz, ancak kodunuza bağlı olarak optimizasyon işleri bozabilir! Genel olarak, doğru çalışan bir optimize edici tarafından kırılan kod gerçekten bir şeyle kaçan buggy kodudur, bu yüzden genellikle optimizatörün neden bozduğunu anlamak istersiniz.

Bu soruyu Jack Ganssle'a gönderdim ve bana bu cevap verdi:

Daniel,

Ben yayımlanan kodda olacak optimizasyonlar kullanarak hata ayıklamayı tercih. NASA "ne uçtuğunuzu test edin, ne test ettiğinizi uçurun" diyor. Başka bir deyişle, test yapmayın ve sonra kodu değiştirin!

Ancak, bazen hata ayıklayıcının çalışabilmesi için optimizasyonları kapatmak gerekir. Sadece üzerinde çalıştığım modüllerde onları kapatmaya çalışıyorum. Bu nedenle dosyaları küçük tutmaya inanıyorum, birkaç yüz kod satırı söyleyin.

En iyi dileklerimle, Jack

Bağlıdır ve bu sadece C30 için değil tüm aletler için geçerlidir.

Optimizasyonlar genellikle kodu çeşitli şekillerde kaldırır ve / veya yeniden yapılandırır. Anahtar ifadeniz bir if / else yapısıyla yeniden uygulanabilir veya bazı durumlarda hep birlikte kaldırılabilir. y = x * 16, bir dizi sol vardiya vb.Ile değiştirilebilir, ancak bu son optimizasyon türü genellikle hala aşılabilir, ancak çoğunlukla sizi alan kontrol ifadesinin yeniden yapılandırılmasıdır.

Bu, bir hata ayıklayıcıyı C kodunuzda atlamayı imkansız hale getirebilir, çünkü C'de tanımladığınız yapılar artık mevcut değildir, derleyici tarafından derleyicinin daha hızlı olacağına veya daha az yer kullanacağına inandığı bir şeyle değiştirilmiş veya yeniden sıralanmıştır. Ayrıca kesme noktalarının C listesinden ayarlanması imkansız olabilir, çünkü kırılma talimatınız artık mevcut olmayabilir. Örneğin, bir if ifadesinin içinde bir kesme noktası ayarlamayı deneyebilirsiniz, ancak derleyici if öğesini kaldırmış olabilir. Bir süre içinde veya döngü için bir kesme noktası ayarlamayı deneyebilirsiniz, ancak derleyici bu döngüyü artık var olmayacak şekilde açmaya karar verdi.

Bu nedenle optimizasyon kapalıyken hata ayıklayabilirsiniz, genellikle daha kolaydır. Optimizasyonları her zaman yeniden test etmelisiniz. Bu, önemli bir şeyi kaçırdığınızı volatileve bunun aralıklı arızalara (veya başka bir tuhaflığa) neden olduğunu öğrenmenin tek yolu ile ilgilidir .

Gömülü geliştirme durumunda, yine de optimizasyonlara dikkat etmelisiniz. Özellikle kodun zamanlama açısından kritik bölümlerinde, örneğin bazı kesmeler. Bu durumlarda, montajdaki kritik bitleri kodlamanız veya derleme direktiflerini kullanmanız gerekir; böylece bu bölümlerin optimize edilmediğinden emin olun, böylece sabit bir yürütme süresine veya sabit bir en kötü durum çalışma süresine sahip olduklarını bilirsiniz.

Diğer gotcha uC içine kod sığdırma olabilir, sadece kod çip içine sığdırmak için kod yoğunluk optimizasyonları gerekebilir. Bu, bir ailenin en büyük ROM kapasitesi uC ile başlamak ve kodunuz kilitlendikten sonra üretim için sadece daha küçük bir tane seçmek için genellikle iyi bir fikir olmasının bir nedenidir.

Genel olarak, bırakmayı planladığım ayarlarla hata ayıklayabilirim. Eğer optimize edilmiş kodu yayınlayacak olsaydım, optimize edilmiş kodla hata ayıklardım. Optimize edilmemiş kodu serbest bırakacak olsaydım, optimize edilmemiş kodla hata ayıklardım. Bunu iki nedenden dolayı yapıyorum. İlk olarak, optimize ediciler son ürünün optimize edilmemiş koddan farklı davranmasına neden olacak kadar önemli zamanlama farkları yapabilir. İkincisi, çoğu oldukça iyi olsa da, derleyici satıcıları hata yapar ve optimize edilmiş kod, optimize edilmemiş koddan farklı sonuçlar üretebilir. Sonuç olarak, bırakmayı düşündüğüm ayarlarla mümkün olduğunca fazla test süresi elde etmeyi seviyorum.

Bununla birlikte, optimize ediciler önceki yanıtlarda belirtildiği gibi hata ayıklamayı zorlaştırabilir. Hata ayıklamak zor olan kodun belirli bir bölümünü bulursam, optimize ediciyi geçici olarak kapatacağım, kodun çalışması için hata ayıklamayı yapacağım, ardından optimize ediciyi tekrar açıp bir kez daha test edeceğim.

Normal stratejim, son optimizasyonla (uygun şekilde boyut veya hız için maks.) Geliştirmektir, ancak bir şeyde hata ayıklamak gerekirse optimizasyonu geçici olarak kapatın. Bu, optimizasyon seviyelerinin değiştirilmesi sonucunda hataların ortaya çıkma riskini azaltır.

Tipik bir arıza modu, optimizasyonun artması, değişkenlerin gerektiğinde geçici olarak bildirilmemesi nedeniyle önceden görülmemiş hataların yüzeye çıkmasıdır - bu, derleyiciye hangi şeylerin 'optimize edilmemesi' gerektiğini söylemek için gereklidir.

Hangi formda yayınlayacağınızı kullanın, hata ayıklayıcılar ve hata ayıklama için derleme, sürüm için derleyene kadar görmediğiniz çok fazla hata (A LOT) gizleyin. O zamana kadar bu hataları bulmak çok daha zor, giderken hata ayıklama vs. 20 yıl sonra hiçbir zaman bir gdb veya başka bir hata ayıklayıcı için kullanmadım, değişkenleri veya tek adımı izlemeye gerek yok. Günde yüzlerce ila binlerce satır. Bu yüzden mümkündür, aksi düşünmeye yöneltmeyin.

Hata ayıklama için derleme, daha sonra serbest bırakma için derleme, çabanın iki katından iki katından fazla sürecektir. Bağlanırsanız ve hata ayıklayıcı gibi bir araç kullanmanız gerekiyorsa, hata ayıklayıcının belirli bir sorunu çözmesi için derleyin ve normal çalışmaya geri dönün.

Optimize edici, kodu daha hızlı hale getirdiğinden, özellikle derleyici seçenekleriyle zamanlama değişikliklerinize ve programınızın işlevselliğini etkileyebilecek şekilde diğer sorunlar da geçerlidir, burada yine tüm aşama boyunca teslim edilebilir derleme seçeneğini kullanın. Derleyiciler de programlardır ve hatalar ve optimize ediciler hata yapar ve bazıları buna inanmaz. Bu durumda, optimizasyon olmadan derlemede yanlış bir şey yoksa, sadece her zaman bu şekilde yapın. Tercih ettiğim yol optimizasyon için derlemektir, o zaman bir derleyici sorunundan şüphelenirsem, bu düzeltmelerde optimizasyonun devre dışı bırakılmasını genellikle tersine çevirip bazen montajcı çıktısını nedenini anlamak için inceleyelim.

Ben her zaman -O0 (optimizasyon kapatmak için gcc seçeneği) ile kod geliştirmek. Ben bir şey daha bir sürüm doğru daha fazla kafa izin izin başlamak istiyorum noktada olduğumu hissediyorum, ben genellikle önbellek tutmak daha iyi olacak daha fazla kod olarak -Os (boyut için optimize) ile başlayacağım süper duper optimize olmasa bile.

Gdb'nin -O0 kodu ile çok daha iyi çalıştığını ve derlemeye adım atmanız gerekiyorsa takip etmesi çok daha kolay olduğunu düşünüyorum. -O0 ve -Os arasında geçiş yapmak, derleyicinin kodunuza ne yaptığını da görmenizi sağlar. Zaman zaman oldukça ilginç bir eğitimdir ve derleyici hatalarını da ortaya çıkarabilir ... kodunuzdaki neyin yanlış olduğunu anlamaya çalışırken saçınızı çekmenizi sağlayan kötü şeyler!

Gerçekten ihtiyacım varsa, -gc-bölümleri ile -fdata-bölümleri ve -fcode-bölümleri eklemeye başlayacağım, bu da bağlayıcının aslında kullanılmayan tüm işlevleri ve veri bölümlerini kaldırmasına izin verir. İşleri daha da daraltmaya veya daha hızlı hale getirmeye çalışmak için uğraşabileceğiniz birçok küçük şey var, ancak bunlar genellikle kullandığım tek numara ve daha küçük veya daha hızlı olması gereken her şey -birleştirmek.

Evet, hata ayıklama sırasında optimizasyonları devre dışı bırakmak üç nedenden ötürü bir süredir en iyi uygulama olmuştur:

• (a) programı üst düzey bir hata ayıklayıcı ile tek adımda atacaksanız, biraz daha az kafa karıştırıcıdır.
• (a) (eski) Programda bir montaj dili hata ayıklayıcısıyla tek adımda hata ayıklama yapacaksanız, çok daha az kafa karıştırıcıdır. (Ama üst düzey bir hata ayıklayıcıyı kullanırken neden bununla uğraşasınız ki?)
• (b) (çok eski) muhtemelen bu belirli yürütülebilir dosyayı yalnızca bir kez çalıştıracaksınız, sonra biraz değişiklik yapacak ve yeniden derleyeceksiniz. Derleyici bu belirli yürütülebilir dosyayı "en iyi duruma getirirken" 10 dakikadan daha az çalışma süresi kazandıracak bir kişinin fazladan 10 dakika beklemesi zaman kaybıdır. (Bu, 2 saniyeden daha kısa sürede tam optimizasyonla tipik bir mikrodenetleyici yürütülebilir dosyasını derleyebilen modern PC'lerle artık ilgili değildir).

Birçok insan bu yönde daha da ileri gider ve iddialar açık olarak gönderilir .

Basit: optimizasyonlar zaman alıcıdır ve bu kod parçasını daha sonra geliştirme aşamasında değiştirmeniz gerektiğinde yararsız olabilir. Yani zaman ve para kaybı olabilir.
Ancak bitmiş modüller için kullanışlıdır; kodun artık büyük olasılıkla değişiklik gerektirmeyecek kısımları.

kesme noktalarında kesinlikle mantıklıdır ... çünkü derleyici aslında belleği etkilemeyen birçok ifadeyi kaldırabilir.

şöyle bir şey düşünün:

int i =0;

for (int j=0; j < 10; j++)
{
 i+=j;
}
return 0;

tamamen optimize edilebilir (çünkü ihiç okunmaz). temelde sadece orada değildi zaman, tüm bu kodu atladı kırılma bakış açısından bakacaktı .... Ben uyku tipi fonksiyonlarında sık sık gibi bir şey göreceksiniz:

for (int j=delay; j != 0; j--)
{
    asm( " nop " );
    asm( " nop " );
}
return 0;

Hata ayıklayıcı kullanıyorsanız, optimizasyonları devre dışı bırakır ve hata ayıklamayı etkinleştiririm.

Şahsen PIC hata ayıklayıcının düzeltmeme yardımcı olduğundan daha fazla soruna neden olduğunu görüyorum.
C18 ile yazılmış programlarımda hata ayıklamak için sadece USART'a printf () kullanıyorum.

Derlemenizde optimizasyonu etkinleştirmeye yönelik argümanların çoğu şöyledir:

1. hata ayıklama sorunu (JTAG bağlantısı, kesme noktaları vb.)
2. yanlış yazılım zamanlaması
3. sh * t düzgün çalışmıyor

İMHO ilk ikisi yasal, üçüncüsü ise pek değil. Bu genellikle kötü bir kodunuz olduğu veya dilin / uygulamanın güvenli olmayan şekilde kullanılmasına güvendiğiniz anlamına gelir veya belki de yazar sadece İyi Olmamış Amca Davranışının hayranıdır.

Academia'daki Gömülü blog'un tanımlanmamış davranış hakkında söylenecek bir iki şey var ve bu yazı derleyicilerin nasıl kullandığına dair: http://blog.regehr.org/archives/761