Newsgroup: it.comp.retrocomputing
Titolo: Ma i BASIC di una volta erano tutti così male ottimizzati?

So che una volta (prima che uscissero BASIC compilati) si diceva che i
BASIC sono lenti perch� sono interpretati, ma almeno in un caso
(sperimentato da me personalmente) la lentezza era dovuta solo a
mancanza di ottimizzazione, se non a un deliberato decremento delle
prestazioni.
Qualche tempo fa avevo notato che il programma TD_View di AMOS 3D non
funzionava con sistemi veloci perch� la routine di movimento
presuppone che il programma NON riesca a girare a full speed, allora
ho iniziato a riscriverla per poter muovere la telecamera coi tasti
WASD, allo stesso modo di un moderno FPS, controllando a ogni ciclo lo
scancode del tasto premuto e muovendo la telecamera di conseguenza. Il
primo tentativo l'ho fatto usando l'istruzione standard che AMOS
fornisce per lo scopo:
TASTO=Scancode
Questo tentativo � stato un disastro: il programma andava a scattoni
tremendi, come se il sistema fosse stato downcloccato a 1 MHz!
Allora ho fatto un altro tentativo, andando a leggere lo scancode
direttamente alla locazione di memoria in cui l'Amiga mappa la
tastiera. Cos�:
TASTO=Peek($BFEC01)
E stavolta il programma si � messo a girare a FULL SPEED!
A quel punto, per�, mi sono chiesto: dal momento che AMOS � scritto
per funzionare sugli Amiga classici, nei quali periferiche come
tastiera, mouse e joystick sono SEMPRE mappate sugli stessi indirizzi
di RAM... per quale accidenti di motivo, quando l'interprete si trova
davanti un richiamo alla funzione Scancode, non esegue semplicemente
uno spostamento del valore di scancode dalla locazione di memoria
adeguata alla variabile? Insomma, perch� non fa la STESSA cosa che fa
quando deve interpretare un Peek che legge quella locazione? Ma pi�
importante: quale perversione mentale pu� aver portato Francois Lionet
(l'autore di AMOS) a scegliere DELIBERATAMENTE di rallentare la
funzione Scancode in quel modo?
A questo punto mi aspetto che questo non sia l'unico caso, quindi:
qualcuno ha mai notato qualcosa del genere con un altro retro-BASIC?

 qualcuno ha mai notato qualcosa del genere con un altro retro-BASIC?
Considerando che magari deriva dallo stos basic sviluppato su atari st,
alcune versioni per amiga erano meno ottimizzate (ricordo che giravano
delle versioni di amos patchate) oppure semplicemente per mantenere un
layer basico di cross compatibilit� era un assunzione troppo forte
prevedere che certe routine fossero mappate ad un certo indirizzo di
memoria e quindi le funzioni facevano qualche controllo in pi�
Sono le uniche due cose che mi vengono in mente.

 ...
Credo che, in linea di massima, una "peek" su una locazione sia sempre e 
comunque piu' veloce di una qualsiasi funzione di "scansione" di una 
periferica.  Io la vedo cosi':
- "peek(x)" si traduce in una lettura su locazione, ed assegnazione del 
valore ad una variabile.  male andando, se la peek accetta indirizzi in 
decimale, questi dovranno essere convertiti in hex prima di avviare la 
lettura della locazione corrispondente.  ci vorranno... che so... 8-10 
operazioni ASM per fare tutto.
la peek e' dunque una operazione velocissima, probabilmente la piu' veloce 
(insieme alla poke) tra i vari comandi basic.
- "scancode()" esegue anch'essa la lettura su una certa locazione, ma magari 
saranno necessarie piu' operazioni perch� dovr� convertire il valore 
rilevato in una forma "leggibile" poi dall'interprete (butto a caso) ?
Posso citare ad esempio il comando "JOY" del Basic Creativision. 
Fondamentalmente racchiude in se tutta una serie di "peek" su 4 indirizzi 
separati (joy1, buttons 1 e 2, joy 2, buttons 3 e 4).  Tu passi solo il 
parametro "JOY(x)" con x tra 1 e 4, e lui ti restituisce il valore trovato.
Di fatto e' una funzione MOLTO lenta perche' intanto a seconda del valore 
che gli passi (1-4) lui deve andare a cercare la locazione richiesta tra le 
4 disponibili, dopodiche' esegue la peek.  Il risultato poi va a true/false 
o al valore trovato, e pertanto va "elaborato".
Questo diventa particolarmente pesante, specie quando in un ciclo devi 
verificare tutti i pulsanti ed i joystick a ripetizione.
La stessa cosa puoi ottenerla con delle "peek" dirette, che ti danno 
immediatamente il valore numerico trovato, e tu lavori direttamente su 
quello.
Comunque e' interessantissima l'osservazione di Giacomelli: probabilmente in 
quanto AMOS deriva da STOS, semplicemente si e' "wrappata" male la gestione 
degli indirizzi I/O.
MADrigal
-- 
---------------------------------------------------------------------
- Dr. Eng. Luca Antignano, Sassari, Italy
- freeware handheld simulators at          
www.madrigaldesign.it/sim/
- CreatiVision emulation central at 
www.madrigaldesign.it/creativemu/
- Game & Watch shrine at               
www.madrigaldesign.it/gwmania/
- Zzap!Raine web magazine  
http://rainemu.swishparty.co.uk/zzapraine/
---------------------------------------------------------------------
 

>> I have a family and a full time job, but still have a time to get
much hours of Amiga hacking a day  :-) <<< 

l'amiga.
La vedo piuttosto difficile mandare in guru una macchina con una
semplice lettura. E comunque ho provato col 3.1 e funziona comunque
benissimo.


Beh il principio per cui non si usa(va)no assunzioni dirette � quello 
detto prima, se la lettura della pressione del tasto rimane sempre quella 
con i vari O.S. buon per te hai trovato una buona ottimizzazione per 
quella funzione :-)



SCANCODE returns the internal scancode of a key which has previously
entered using the INKEY$ function. This allows you to check for keys
which do not produce a character from the keyboard, such as HELP or
TAB.
quindi...
inkey:
* fa una sistem call
* salva in un registro il valore letto
scancode
* converte il valore del registro nel codice corrispondente al tasto amiga
questo fa in modo che funzioni anche su altri modelli di amiga e di
sistema operativo.
comunque guarda sul sito del clickteam te lo trovi il codice sorgente di
amos....
*		= INKEY$
L_FInky		equ 	114
*
L114:	SyCall	Inkey
	tst.l	d1
	beq.s	L114a
	move.w	d1,d2
	swap	d1
	move.w	d1,SScan(a5)
	moveq	#2,d3
	RBsr	L_Demande
	move.w	#1,(a0)+
	move.b	d2,(a0)+
	addq.l	#1,a0
	move.l	a0,HiChaine(a5)
	move.l	a1,-(a3)
	rts
L114a	move.l	ChVide(a5),-(a3)
	rts
*******************************************************************
*		=SCANCODE
L_FScan		equ 	115
*
L115:	moveq	#0,d3
	move.b	SScan+1(a5),d3
	clr.b	SScan+1(a5)
	move.l	d3,-(a3)
	rts