Ottimizzazione Dei Programmi Basic

[MarC=ello]

 Ciao!

Oltre alle tecniche di compattazione che troverete nella Guida C64 (cospicuo aggiornamento previsto per la fine del mese...), esistono altri accorgimenti per rendere più veloci i programmi BASIC.

1. Utilizzare SEMPRE variabili, specialmente entro i cicli.
2. Evitare i calcoli se possibile.

Esempio:

10 FORT=0TO7999:POKE8192+T,0:NEXT

Questo brevissimo programma serve per azzerare il segmento di memoria da 8192 a 8192+7999 = 16191.

Osserviamo che entro il ciclo FOR c'è un calcolo che può essere evitato. Basta sostituire i valori iniziale e finale del contatore del ciclo FOR (T) come segue:

10 FORT=8192TO16191:POKET,0:NEXT

Infine, per occupare meno memoria e rendere più veloce il codice, utilizziamo delle variabili per rappresentare la locazione iniziale e la locazione finale:

10 A=8192:B=16191:FORT=ATOB:POKET,0:NEXT

Queste possono sembrare cose di poco conto ma in realtà, specialmente in programmi lunghi, si guadagna molto in termini di velocità.

Ciao a tutti!




 

[Alberto]

 Ciao Marcello

Quel che dici è vero,ma quando si intendono scrivere programmi in cui è importante la velocità di esecuzione  ( che debbano,ad esempio,richiedere la pulitura di un intero segmento di memoria.come sopra ),conviene spostare il proprio interesse verso il linguaggio macchina  

[MarC=ello]

 Ciao Alberto

Beh questo è fuori discussione...

Questi accorgimenti sono utili quando vuoi, per tua soddisfazione e/o divertimento, spingere il BASIC oltre i suoi limiti. Io ad esempio ho scritto un programma che realizza un semplice scrolling fluido in puro BASIC (Rob mi ha proposto di scrivere un articolo in merito a ciò... spero di trovarne il tempo un giorno).

A me è sempre piaciuto cercare di spingere il BASIC al massimo... semplicemente perché "it can be done"

Ciao!

[MarC=ello]

 Ti dirò poi che sono riuscito a creare effetti "raster" in BASIC... e anche un effetto 3D abbastanza carino... vorrei rilasciare un demo interamente in BASIC ma il problema è il tempo. Ad esempio ho finito solo stasera la seconda parte del vocabolario CBM BASIC a denti stretti... sono sempre molto indaffarato... Ora credo che la sezione dedicata alla Guida C64 sarà aggiornata fra pochi giorni.

Rinnovo i saluti!

[Roberto]

 L'ottimizzazione del linguaggio è fondamentale, quando si utilizza una macchina come il Commodore64, dove ogni byte è prezioso quanto un kilo di platino! E questo indipendentemente dal linguaggio utilizzato.
Questo è quello che ho imparato in base alle mie modeste esperienze in merito di programmazione e soprattutto grazie al mio diavolo custode: ian coog, che è stato per me un vero pozzo di consigli.
Per imparare ancora meglio altre tecniche di ottimizzazione, sarebbe utile analizzare alcuni programmi scritti in maniera non ottimizzata e cercare di capire come fare per ripulirli. Se magari qualcuno all'ascolto ha scritto o sta scrivendo qualche breve programma, potrebbe postarlo in questa sede, si potrebbe cercare di migliorarlo insieme. Sicuramente non si farà avanti nessuno... ma sicuramente potrebbe essere interessante.

[Alberto]

 

sarebbe utile analizzare alcuni programmi scritti in maniera non ottimizzata e cercare di capire come fare per ripulirli.

Il tutorial sui dischi contiene un paio di consistenti listati Basic non ottimizzati...
La stessa Guida del programmatore ne contiene parecchi...

Sicuramente non si farà avanti nessuno...

Perchè questo pessimismo? :mellow:
   

[Alberto]

 

Questi accorgimenti sono utili quando vuoi, per tua soddisfazione e/o divertimento, spingere il BASIC oltre i suoi limiti.

Certo,è una gran bella cosa

Io ad esempio ho scritto un programma che realizza un semplice scrolling fluido in puro BASIC

Perchè non lo pubblichi? :fagiano:

A me è sempre piaciuto cercare di spingere il BASIC al massimo... semplicemente perché "it can be done"

Ottima filosofia...
Ciao
Alberto  

[MarC=ello]

 Sì, penso che prima o poi lo pubblicherò...    

[MarC=ello]

 

La stessa Guida del programmatore ne contiene parecchi...

Sì, infatti. Questo perché è stata messa come prioritaria la chiarezza dei programmi. Un programma "compattato" è più difficilmente leggibile di uno non compattato. Inoltre, sui programmi non compattati si possono inserire agevolmente dei commenti (REM) esplicativi.

 

[iAN CooG]

 Questi cicli da basic ci impiegano sempre troppo.
Se proprio vogliamo andare veloci come razzi eccovi una routinetta:

Codice: [Seleziona]

;fill routine da Basic
;[iAN CooG/HokutoForce]
;uso: SYS820,8192,16384,0

*=$0334
    JSR $AEFD ; salta la virgola
    JSR $A96B ; leggi un intero in $14/$15
    lda $14
    ldx $15
    sta $fb   ; indirizzo di partenza
    stx $fc
    JSR $AEFD
    JSR $A96B
    lda $14    
    ldx $15
    sta $fd   ; indirizzo di fine
    stx $fe
    JSR $AEFD
    JSR $A96B
    lda $14   ; valore di riempimento
    ldy #$00
lp  sta ($fb),y
    ldx $fe
    cpx $fc
    bne inc1
    ldx $fb
    cpx $fd
    beq exit

inc1
    inc $fb
    bne lp
    inc $fc
    jmp lp
exit
    rts

e per implementarlo in un listato basic

Codice: [Seleziona]

10 forx=820to881:ready:pokex,y:next
15 sys820,8192,16191,0
20 end
90 data 032,253,174,032,107,169,165,020,166,021,133,251,134,252,032,253
91 data 174,032,107,169,165,020,166,021,133,253,134,254,032,253,174,032
92 data 107,169,165,020,160,000,145,251,166,254,228,252,208,006,166,251
93 data 228,253,240,009,230,251,208,238,230,252,076,090,003,096

anche se io sono per il link diretto delle routines senza usare READ/DATA che occupano tempo e *tanto* spazio inutilmente. Ma forse questo risultera' arabo per la maggior parte dei niubbi  :overkiller:  

[Alberto]

 

Questi cicli da basic ci impiegano sempre troppo.

Infatti,per quello ho detto che,in questi casi,conviene usare il linguaggio macchina...

anche se io sono per il link diretto delle routines senza usare READ/DATA che occupano tempo e *tanto* spazio inutilmente.

Vero,del resto i caricatori Basic sono utili specialmente per le routines lunghe,in cui è bene controllare l'esattezza dei codici macchina inseriti con l'introduzione di una somma di controllo

 

[iAN CooG]

Vero,del resto i caricatori Basic sono utili specialmente per le routines lunghe,in cui è bene controllare l'esattezza dei codici macchina inseriti con l'introduzione di una somma di controllo

Io direi proprio il contrario! :mellow:
Per una routinetta di 62 bytes come questa mi sta anche bene un caricatore in basic, per qualcosa di piu' lungo e' meglio scriverla direttamente in assembler, senza bisogno di checksum vari: e' meglio sapere cosa si sta scrivendo che immettere numeri a caso senza significato    

[MarC=ello]

 Io stavo parlando di ottimizzazione dei programmi BASIC, ed ho scelto un compito non adatto per il BASIC in modo da far vedere meglio i guadagni di tempo che si ottengono con l'ottimizzazione (considerando un lasso di tempo più lungo, i guadagni sono relativi ad una grande quantità e pertanto risultano più evidenti).

Nessuno, Alberto, sosteneva che bisogna usare il BASIC per azzerare un segmento di 8K. Il mio thread aveva come argomento L'OTTIMIZZAZIONE DEI PROGRAMMI BASIC, non l'azzeramento (o comunque il filling) di un segmento di memoria wink.gif

Bellissimo comunque il programma di Ian, che, previa sua autorizzazione, gradirei molto inserire nella Guida al futuro capitolo sull'interfacciamento fra BASIC e linguaggio macchina (spero che Ian sarà d'accordo; ovviamente ci saranno tutti i crediti del caso :-)).

In ogni caso, l'ottimizzazione dei programmi BASIC è importante. Infatti, guardate un po' la differenza fra il programma non ottimizzato e quello ottimizzato:

5 TI$="000000"
10 FORT=0TO7999:POKE8192+T,0:NEXT:PRINTTI$
15 A=8192:B=16191
20 TI$="000000":FORT=ATOB:POKET,0:NEXT:PRINTTI$

Digitando RUN (e, se siete su VICE, premendo ALT + W onde evitare di attendere una vita) si otterrà:
000111
000028

Questo significa che il programma non ottimizzato impiega 1 minuto e 28 secondi per svolgere l'azzeramento delle locazioni da 8192 a 16191; il programma ottimizzato impiega "solo" 28 secondi... a me non sembra una cosa da poco.

L'esempio del segmento di memoria non è certo dei più felici per il BASIC.
Consideriamo allora il seguente programma:

Programma LENTO:

100 REM FINTO RASTER
110 REM VERSIONE NON OTTIMIZZATA
240 PRINTCHR$(147);
250 FORT=1TO24:FORK=1TO40:PRINTCHR$(63+T);:NEXTK:NEXTT
260 FORT=12288TO12288+(8*24):POKET,0:NEXT
270 POKE 53272,(PEEK(53272)AND240)OR12
280 FORK=0TO192:POKE12288+K,255:NEXTK
290 FORK=192TO0STEP-1:POKE12288+K,0:NEXTK
300 GOTO280


Programma VELOCE (fa la stessa cosa del precedente, ma è ben più veloce):

100 REM FINTO RASTER
110 REM VERSIONE PARZIALMENE OTTIMIZZATA
240 PRINTCHR$(147);
250 FORT=1TO24:FORK=1TO40:PRINTCHR$(63+T);:NEXTK:NEXTT
260 FORT=12288TO12288+(8*24):POKET,0:NEXT
270 POKE 53272,(PEEK(53272)AND240)OR12
275 S=12288:F=12480
280 A=255:FORK=STOF:POKEK,A:NEXTK
290 A=0:FORK=FTOSSTEP-1:POKEK,A:NEXTK
300 GOTO280

Basta eseguire i due programmi, per rendersi conto che l'ottimizzazione può consentire il conseguimento di risultati stimolanti anche in BASIC (that's BASIC hacking, guys!!).

Ovviamente il programma può essere ottimizzato ancora... basta abbassare i numeri di linea, modificare la routine che effettua delle POKE direttamente sullo schermo con delle istruzioni PRINT, ecc... ecc... Non mi sono concentrato sulla velocità di visualizzazione dei caratteri sullo schermo, quanto alla "raster" routine vera e propria (ovviamente questo programma simula una routine raster, per questo il termine è fra virgolette - lo dico per chi non ha mai programmato il raster; per le vere routine raster è indispensabile il linguaggio macchina). I numeri di linea sono grandi perché ho preso il programma da un altro mio programma più grande (e non ho avuto voglia di cambiare i numeri di linea...).

(Se qualcuno non capisse qualcosa, chiedetemi pure :-)).

Comunque, buona Pasqua a tutti!

[MarC=ello]

 Quanto ai caricatori, sono in tutto e pertutto d'accordo con Ian.    

[MarC=ello]

 Ah, sensa offesa: per interrompere i programmi FINTO RASTER premere RUN/STOP e RESTORE.