MECCANICA e DINTORNI

Ni, il compilatore deve garantirti il risultato.. non l'ordine, esempio semplice. Compila con esegui un

cat testverifica.s

vedrai questo codice assembly Se lo ritraduci in c vedrai che Il compilatore ha deciso che
b=0;
dovesse avere precedenza rispetto a
a = b + 1;

nonostante noi gli avessimo detto di fare il contrario.!

Questo è un piccolissimo esempio di come il compilatore cambia l'esecuzione delle istruzioni di un codice..
Bada bene, io non stò dicendo che hai torto, sto semplicemente dicendo che nessuno ci dà la certezza di come il compilatore stà codificando il codice! !!

P.S Yrag scusa per L'OT

FraPaola tu stai compilando con gcc un eseguibile che gira sotto un sistema operativo.
Io sto compilando con ARM su un microcontrollore.... parliamo di due cose diverse. Sui microcontrollori i thread si possono gestire ma con altri sistemi e comunque sai sempre qual'è il codice da assegnare al thread e quello che deve essere eseguito con priorità. Oltre a ciò, anche per il codice in thread, NON viene assolutamente modificato MAI l'ordine di esecuzione.
Quando programmi un microcontrollore devi gestire periferiche a bassissimo livello (timing UART, I2C, PWM, ADC, DAC, DMA....); se il compilatore cambiasse l'ordine di esecuzione come dici tu tutta questa roba non funzionerebbe.

Per dirla tutta, il disassembly del codice che porti come esempio avviene perché oggi i compilatori sono più "smart" e quindi decidono che tu hai fatto un errore inizializzando la variabile "b" successivamente all'operazione e lo correggono.

Ai tempi in cui ho studiato io informatica questa roba non esisteva e, per come la vedo io, non dovrebbe esistere nemmeno adesso. Linguaggi come il visual basic, ad esempio, sono un insulto all'informatica.... la macchina deve fare ciò che dico io, non quello che dice lei. In questo modo possiamo imparare dai nostri errori che è l'unica cosa che (per ora) distingue le macchine dall'uomo.... in pratica, il tuo "ni", per una macchina, non dovrebbe esistere. 0 o 1, "si" o "no".

Ovviamente l'ultimo paragrafo è in onore dello zio....

Grazie !

Zio ormai sono partiti per la tangente, ignorali

Si, prendo le distanze, non vorrei che i mastuggiorgio, nella foga, impacchettassero anche me...

o magari, nella sfiga, impacchettano solo te

dalla documentazione ufficiale dell'stm32

The order of instructions in the program flow does not always guarantee the order of the
corresponding memory transactions. The reason for this is that:
• The processor can reorder some memory accesses to improve efficiency, providing this
does not affect the behavior of the instruction sequence.
• The processor has multiple bus interfaces.
• Memory or devices in the memory map have different wait states.
• Some memory accesses are buffered or speculative.

Cmq, parlando con alcuni colleghi di ST, mi hanno confermato che l'ipotesi di un riordine delle istruzioni così impattante anche se possibile è alquanto remota come ipotesi, quindi in linea teorica avrei ragione, ma in pratica hai ragione tu.. ottimo ho imparato qualcosa, faccio mea culpa:D

che vuol dire? che in pratica la macchina ha più buon senso di chi l'ha progettata? allora involontariamente subentrano le tre leggi della robotica?

sempre sia benedetto Isaac Asimov

FraPaola: "The order of instructions in the program flow does not always guarantee the order of the
corresponding memory transactions. The reason for this is that:"

Qui parla solo di come sono organizzate le istruzioni in memoria, non ha nulla a che vedere con l'instruction pointer, e infatti:
"The processor can reorder some memory accesses to improve efficiency, providing this
does not affect the behavior of the instruction sequence."

Il compilatore non c'entra nulla in questo caso; qui è ST che (giustamente) ti garantisce la giusta sequenza di esecuzione di un codice già caricato in flash. Il problema che hai posto tu compilando con gcc è a livello di compilatore, non di processore.

Più che ipotesi remota diciamo che dovrebbe essere impossibile.... anche perchè risulterebbe in un bug. Non che non ce ne siano, ben intesto, ma se andiamo a considerare i bug allora il discorso è differente.
Un riordino della sequenza di esecuzione da parte del compilatore atto ad ottimizzare il codice non ha senso, soprattutto in un'architettura come ARM.

PIGI aiuto!!!!

Ottimo, ho imparato qualcosa!

Lo dico ad Alan, sarà felice di saperlo...

Chi sarebbe Alan?