[RISOLTO] dichiarare variabili al momento che servono oppure no

Silente: Poi mi spieghi perché dichiari alcune bool come =!HIGH (5 caratteri) e non come =LOW (3 caratteri)? Il risultato é lo stesso, ma il secondo é più chiaro.

Folcloristico come uso ma il numero di caratteri è ininfluente al fine dello spazio occupato nel compilato ;)

EDIT: Vorrei rivedere un cicinin questa mia affermazione:

maubarzi: Premetto che non sono per le ottimizzazioni estreme se non servono o se costano di più del passaggio a piattaforme più potenti.

Intendo su progetto one shot, se si tratta di un prodotto con un ciclo di vita non brevissimo invece sono abbastanza per l'ottimizzazione, magari non maniacale ma quasi ;)

Lo so. era solo per dire che ti piace pure scrivere di più

Però non negherai che è un modo carino di scrivere codice, per me è pure simpatico. Sembra quasi una firma stilistica ;)

a me personalmente non piace preferisco semmai scrivere 1 piuttosto che !LOW, che passa per una macro e una negazione per scrivere un uno, mi sembra una pippa inutile

Silente: incorpora fino alla morte le boolean in variabili di tipo byte (non so per che cosa le usi ma ne ho contate una quindicina soltanto tra le dichiarate globali)

Si potrebbero usare i bit di un singolo int per le 15 boolean che hai contato invece di 15 byte o addirittura di 15 int, non ricordo come erano dichiarate.

maubarzi: Si potrebbero usare i bit di un singolo int per le 15 boolean che hai contato invece di 15 byte o addirittura di 15 int, non ricordo come erano dichiarate.

no credo che ci guadagnamo molto, perchè poi diventa più complicata la gestione, considero l'attule compromesso "boolean grande uguale uguale a byte" un buon compromesso

si, forse hai ragione, probabile che sprechi di più a indicare di leggere il bit N con la bitRead che a dichiararlo e usarlo come byte

maubarzi: si, forse hai ragione, probabile che sprechi di più a indicare di leggere il bit N con la bitRead che a dichiararlo e usarlo come byte

No, anzi ... si risparmia tantissimo a raggruppare valori booleani in un singolo bit di un byte e poi fare il set, reset e test con gli operatori bitwise e magari, per brevità di scrittura, con l'ausilio della macro _BV() ...

set    : varByte |= _BV(numeroBit);
reset  : varByte &= ~(_BV(numeroBit));
test   : if (varByte & _BV(numeroBit)) ....

... tutte cose eseguite in uno paio di cicli macchina o poco più ... ;)

Guglielmo

P.S.: la macro _BV() è definita in come: #define _BV (bit) (1 << (bit))

Non si parlava di tempo di esecuzione ma di spazio utilizzato in memoria. se ad ogni test devi aggiungere un byte per indicare numeroBit già ti sei perso il vantaggio mi sa.

maubarzi:
se ad ogni test devi aggiungere un byte per indicare numeroBit già ti sei perso il vantaggio mi sa.

… mmm … non ne sono sicurissimo. Certo, occorrerebbe valutare quante variabli booleane ti servono, quali operazioni fai più spesso, ecc. ecc. e valutare caso per caso l’ottimizzazione migliore :slight_smile:

Guglielmo

gpb01: ... mmm ... non ne sono sicurissimo. Certo, occorrerebbe valutare quante variabli booleane ti servono, quali operazioni fai più spesso, ecc. ecc. e valutare caso per caso l'ottimizzazione migliore :)

Guglielmo

In effetti, stanotte, ragionando (leggi dormendo), è venuto il dubbio pure a me. Bisognerebbe vedere esattamente come viene scritto in assembly questo test, se riesce a mettere tutto negli stessi byte perchè di fatto non serve un intero byte per indicare numeroBit (ne potrebbero bastano 3 o 4 a seconda se si accede a 1 byte o 2) dipende dai bit che servono per l'indirizzamento della variabile da testare... Non è che dal cilindro tiri fuori un reference del linguaggio assembly? Sul datasheet dell'ATmega c'è solo la lista delle istruzioni con l'identificativo mnemonico, non con quella binaria, almeno se non ho visto male.

maubarzi: In effetti, stanotte, ragionando (leggi dormendo), è venuto il dubbio pure a me .....

... moltissimo conta come ottimizza il compilatore e quale livello di ottimizzazione si sceglie (cosa che non fa nessuno, ma esiste sia un apposito #pragma che un __attribute per cambiare le ottmizzazioni del codice tra le varie possibili).

Ripeto, per avere indicazioni reali, occorrerbbe mettersi a scivere aluni test, compilarli e guardare, con l'aiuto del .elf, l'assemblato generato per la varie righe scritte ;)

Guglielmo

Ho trovato un po' di doc e mi sa che alla fine il buon vecchio Guglielmo non aveva proprio tutti i torti. Le istruzioni sono a 16 bit per cui c'è tutto lo spazio per gestire il numeroBit nell'istruzione principale per cui non dovrebbe richiedere il byte in più che avevo ipotizzato.

L'unica pecca è che alla sua risposta mancava il solito doc di specifica cui ci ha sempre abituati... ;) ad abituare bene le persone ... :smiling_imp: poi queste non sono mai contente ... :P

Quindi mi sa che possiamo dire che anche accorpare i boolean come bit di byte ha il suo vantaggio.

maubarzi:
L’unica pecca è che alla sua risposta mancava il solito doc di specifica cui ci ha sempre abituati… :wink:

:smiley: :smiley: :smiley: … eccone uno (piuttosto vecchio) che magari ti sarà utile (se non lo hai già trovato) …

Guglielmo

AVR_INSTRUCTION-SET.pdf (1.22 MB)

Non mi dire che questa volta riesco io ad aggiornare la tua immensa libreria :wink:
Ne ho trovato uno del 2014.
Però il karma te lo metto lo stesso, anche se guadagnato in zona Cesarini :wink:

FIHE7GUI301K81S.pdf (1.41 MB)

maubarzi: Non mi dire che questa volta riesco io ad aggiornare la tua immensa libreria ;)

:D :D :D ... grazie, dato lo scarso uso che ne faccio, non mi ero preoccupato molto di cercare un aggiornamento ;)

Guglielmo

Silente: Qualche consiglio: incorpora fino alla morte le boolean in variabili di tipo byte (non so per che cosa le usi ma ne ho contate una quindicina soltanto tra le dichiarate globali) Contrario, solo in apparenza, a quanto dissi: sei certo che tutta quella pappardella di variabili globali ti siano utili? Quelle che ti servono solo per momenti rendile locali, che poi spariscono. Ho visto una cosa che non mi piace:un, ma forse sono di più, esemplare di String. Estinguili. Rendi #define TUTTE le variabili il cui valore NON debba cambiare nel programma. Altro che "const unsigned long", e pin di pulsanti manco dichiarati const. Sicuro che ti serva leggere lobstato di pulsanti e ricordarlo in variabile? Se tale variabile la usi una volta sola in lettura basta leggere lo stato del pulsante in quel punto. Poi mi spieghi perché dichiari alcune bool come =!HIGH (5 caratteri) e non come =LOW (3 caratteri)? Il risultato é lo stesso, ma il secondo é più chiaro.

Non ho ancora attaccato oa loop()

come scritto a molte delle cose che indichi ci avevo già pensato. Altre si potrebbero fare, ma quanto shrinko? 10-20-50 byte? ormai sono fuori di 600 byte.

"!HIGH" capisco la perplessità, ma cio' che sembra chiaro a te non lo per me. Uso "!HIGH" semplicemente perchè i relè si eccitato con stato LOW, e mi rimane piu intuitivo scrivere !HIGH per capire quando sto eccitando il relè."

I problemi non sono solo SW ma anche HW: questo progetto è stato inserito in una scatola elettrica di certe dimensioni, molto compatte... con Arduino Pro Micro è tutto compatto, se metto un mega2560 devo rifare tutto.

Eppoi considerazione conclusiva: è bello anche poter scrivere il codice con un minimo di libertà di scrittura, ottimizzando si, ma senza dover rinunciare al proprio "stile", e al modo in cui ciascuno è abituato a scriversi il codice e a leggerlo. Inoltre c'è da distinguere due tipi di sketcher: ci sono gli smanettoni, di solito piu esperti e molto bravi, ma spesso troppo intrippati con il coding (è bello concordo), e poco pratici, ma poi ci sono anche altri che per vari motivi non hanno tempo o voglia di dedicarsi troppo ai problemi SW e HW e preferiscono realizzare il progetto in modo piu agevole (quindi evitando di dedicarsi troppoai problemi di cavilli SW). Io appartengo alla seconda specie.

L'idea di passare a STM32 è dovuta 1) al costo 2) alle dimensioni fisiche (mi consente di utilizzare lo chassis già in suo) 3) la memoria, 64K è il doppio di quello che mi serve 4) non da ultimo il clock 72Mhz invece di 16.

Almeno per questo progetto, in altri casi rimango fedele ad ATMEL. :-)

Grazie cmq delle osservazioni di cui faccio sicuramente tesoro.

maubarzi: Resta però valida la mia premessa iniziale, se con pochi euro riesci a passare a qualcosa di più "potente" non vale la pena spendere ore in ottimizzazioni perchè costerebbero di più del cambio MCU.

Eh già. Anche perchè ahimè di tempo ne ho veramente poco. Tra figli moglie lavoro.. alla fine mi restano dei ritagli... perdere ore per comprimere di 100byte mi pare poco costruttivo nel mio caso almeno.

Grazie molto per le osservazioni.

dr_vagus: ... non da ultimo il clock 72Mhz invece di 16.

... questo dato, buttato così, non è molto signifcativo ... ho visto blasolante MCU viaggiare a quelle frequenze e svolgere i loro compiti più lentamente degli AVR a 16 MHz ... occorre esaminare molte cose, il solo clock non basta ;)

Guglielmo

dr_vagus: Eh già. Anche perchè ahimè di tempo ne ho veramente poco. Tra figli moglie lavoro.. alla fine mi restano dei ritagli... perdere ore per comprimere di 100byte mi pare poco costruttivo nel mio caso almeno.

Ma si, dai... siamo sempre in ambito hobbistico! Se lo si fa per lavoro sarebbe già diverso, altrimenti si rischia di fare come una nota azienda di software che con le sue pessimizzazioni riesce sempre a vanificare tutti i miglioramenti prestazionali dell'hardware ;)

gpb01: :D :D :D ... grazie, dato lo scarso uso che ne faccio, non mi ero preoccupato molto di cercare un aggiornamento ;)

Io però la metto lo stesso nel mio curriculum ;)