Bug del compilatore VC++2003 su const volatile

Raffaele Rialdi — Tue, 26 Jul 2005 15:31:00 GMT

... bug che non è presente in VC++2005.

Il linguaggio C++ mette a disposizione molte keyword che non sono indispensabili ma che rendono il sorgente più leggibile e rendono possibile un controllo più ferreo da parte del compilatore.

Per esempio const serve per rendere read-only una variabile. Il compilatore permette quinidi la sua inizializzazione ma ci restituisce un errore di compilazione qualora provassimo ad assegnare il suo valore successivamente.

Questo è un grosso benefit del compilatore perchè gli errori del compilatore sono nostri amici. Tutto ciò che ci viene rilevato in compilazione, ci evita grossi problemi successivamente ed è questo il motivo per cui keyword come const andrebbero sempre usate per rendere più rigoroso il sorgente.

L'uso di const per esempio fornisce un'immediato guadagno in performance perché il compilatore metterà direttamente il valore della costante nel nostro sorgente invece di eseguire l'accesso in memoria alla variabile, risparmiando così un'istruzione.

Può capitare però di avere un dispositivo hardware, un driver, una zona in shared memory che modifica il valore della variabile dichiarata const, anche se dal nostro sorgente non la modificheremo mai. A questo scopo esiste la keyword volatile. In pratica avvisa il compilatore di non eseguire alcuna ottimizzazione perchè il valore di quella variabile può cambiare al di là di quello che può fare il listato.

Il seguente sorgente, una semplice console Win32 riproduce il bug del compilatore VC++2003.

#include "stdafx.h"
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
   const volatile int iTest = 1;
   _asm
   {
      push 5
      pop iTest
   }

   if(argc == iTest)
      std::cout << "equals!";
   return 0;
}

Compilato con VC++ 2003 il risultato è questo (per maggiore chiarezza pubblico con il sorgente misto C++ e compilato x86):

const volatile int iTest = 1;
00415D2E C7 45 F8 01 00 00 00 mov dword ptr [iTest],1

_asm
{
  push 5
00415D35 6A 05            push        5
  pop iTest
00415D37 8F 45 F8         pop         dword ptr [iTest]
}

if(argc == iTest)
00415D3A 83 7D 08 01      cmp         dword ptr [argc],1 // BUG! Ha sostituito iTest con 1 anche se è volatile
00415D3E 75 12            jne         main+42h (415D52h)
  std::cout << "equals!";
00415D40 68 C8 00 44 00   push        offset string "equals!" (4400C8h)
00415D45 68 D8 92 44 00   push        offset std::cout (4492D8h)
00415D4A E8 DA EB FF FF   call        std::operator<<<std::char_traits<char> > (414929h)
00415D4F 83 C4 08         add         esp,8

return 0;
00415D52 33 C0 xor eax,eax

Compilato con VC++ 2005 il risultato è questo:

const volatile int iTest = 1;
0041140E C7 45 F8 01 00 00 00 mov dword ptr [iTest],1

_asm
{
  push 5
00411415 6A 05            push        5
  pop iTest
00411417 8F 45 F8         pop         dword ptr [iTest]
}

if(argc == iTest)
0041141A 8B 45 F8         mov         eax,dword ptr [iTest]
0041141D 39 45 08         cmp         dword ptr [argc],eax
00411420 75 13            jne         wmain+45h (411435h)
  std::cout << "equals!";
00411422 68 FC 66 41 00   push        offset string "equals!" (4166FCh)
00411427 A1 A8 92 41 00   mov         eax,dword ptr [__imp_std::cout (4192A8h)]
0041142C 50               push        eax
0041142D E8 FF FC FF FF   call        std::operator<<<std::char_traits<char> > (411131h)
00411432 83 C4 08         add         esp,8

return 0;
00411435 33 C0 xor eax,eax

In sostanza VC++ 2003 ignora la keyword volatile e di conseguenza non è usabile più allo scopo.

L'uso dell'inline assembler simula la presenza di un “qualcosa“ di esterno che modifichi la variabile. Al posto del blocco _asm ci sarebbe potuta essere una shared memory o qualsiasi altra cosa.

Per dovere di cronaca va detto che questa ottimizzazione viene fatta sia in modalità release che in debug (cioè con le ottimizzazioni 'spente'). Ci sono però tante ottimizzazioni più spinte che vegnono effettuate solo in modalità release e per questo è sempre indispensabile fare i test anche sulla versione release.

Visual C++ in primo piano con VS2005

Raffaele Rialdi — Thu, 12 May 2005 20:04:00 GMT

Con molto affanno torno sul VC++ Day ... le due giornate passate con April, Ronald e Nikola sono state entusiasmanti.

Non ho memoria di un evento su VC++ e se c'erano voci che il C++ stesse per andare in cantina, all'evento sono state smentite con i fatti. Circa 140 persone, 55 tester e 16 PM si occupano di questo gioiello che serve a sviluppare il 95% del codice prodotto da Microsoft.

Riassumere tutto sarebbe veramente lunghissimo e quindi mi terrò argomenti per futuri blog, dopo aver approfondito i singoli punti, però alcune cose mi fa piacere ricordarle:

Adeguamento allo standard ISO. Questo è un punto importante perchè permette di mettere al sicuro il nostro codice sorgente. Spesso i sorgenti VC++ sono algoritmi privi di interfaccia grafica che possono veramente sopravvivere a lungo, a priori del sistema operativo o delle tecnologie che li circondano. Usare un compilatore standard significa che con le future versioni non ci saranno sorprese nel compilare il nostro codice.
Spesso questo punto mette in crisi chi migra da VC++ 6.0 che non era affatto aderente allo standard, ma tra le altre cose si guadagna la possibilità di usare librerie note come Boost e Loki.
Ottimizzazioni. Solo ricompilando il codice con le nuove ottimizzazioni si guadagna in performance fino al 30% rispetto a VC++ 6.0 e cifre simili anche da VC++ 2003 ... per una ricompilata non è male :-)
Le ottimizzazioni ora tengono conto dell'intero codice e non sono più applicate solo sui singoli file obj.
Supporto del compilatore per la compilazione parallela su più CPU o su più Core in una singola CPU
Supporto del compilatore alle specifiche OpenMP di cui avevo visto una demo della Intel allo scorso TechEd. In pratica con la direttiva:
#pragma omp parallel for
for(int i=0; i<=n; ++i) {a[i] = b[i] + c[i] }
si ottimizza l'esecuzione del loop su più thread contemporaneamente.
Profilazione statica del codice. Questa analisi permette di ottimizzare il codice sulla base di un run di prova. Si lancia l'applicazione in una modalità particolare usando le sole funzionalità critiche, quelle per cui vogliamo il massimo della performance. I dati collezionati da questa modalità vengono poi usati dal compilatore per ottimizzare la compilazione vera e propria.
Sempre una profilazione statica del codice permette l'individuazione di potenziali problemi, vulnerabilità, etc. suggerendo se possibile la fix da adottare.
Supporto del compilatore managed e unmanaged per la compilazione a 64bit
Side-by-side libraries del CRT (e non solo) per evitare il più che noto DLL Hell
Supporto all'attach del debugger a più processi oltre che a più thread come già fattibile in VS.NET 2003
Unico ambiente di sviluppo sia per la piattaforma Full che quella embedded
Secure version delle librerie CRT (tanto per intenderci quelle usate per la XP SP2 e Win2K3 SP1). Il codice va rivisto ma con queste librerie si evitano i buffer overrun e quindi ne vale la pena. In molti casi non è necessario modificare nulla grazie ad una speciale versione templated delle funzioni che permette di 'dedurre' la dimensione del buffer se questa viene allocata nello stack locale.
Nuova sintassi C++/CLI in fase di standardizzazione ECMA ed ISO. Il nuovo standard è molto più semplice da usare e permette di usare con semplicità le facilities di una piattaforma costruita sulla Common Language Infrastructure (standard ECMA). Grazie alla riga di comando /CLR si compila secondo la nuova sintassi.
Per chi ha usato le managed extensions, sarà disponibile un tool di conversione automatizzata che lo stesso Stan Lippman ci ha mostrato lo scorso Aprile a Redmond.
Linker di VC++ potrà costruire immagini miste (file come le dll) con codice managed (generato non solo da C++/CLI ma anche da C# o altri linguaggi) ed unmanaged. Questo può tornare utile a tutti coloro che volessero linkare in un unico assembly da VS.NET codice IL sviluppato in linguaggi diversi.
Deterministic Finalization. In pratica il distruttore delle classi C++ non è mappato come in C# sulla Finalize ma sulla Dispose. Questo consente l'implementazione automatica del pattern Dispose risparmiando non pochi grattacapi vista la complessità di quel pattern.
Possibilità di inserire le Winform (ed in futuro Avalon) in progetti MFC o WTL, grazie alla creazione di immagini miste managed/unmanaged. Per esempio MFC può usere le winform al posto di una classica CView senza perdere il routing dei messaggi, etc..
... sicuramente me ne sto dimenticando molte altre ...

Tutto questo per non parlare dell'IDE che fa veramente invidia anche a C#.... more to come ...

C++ [Italiano]

Bug del compilatore VC++2003 su const volatile

Visual C++ in primo piano con VS2005