Stimmt, ich unterschätze das Parsen des Interpreters, Compiler versauen einen in der Beziehung
Hab' mal beides auf Variablen umgestellt - a%(i)=i% und pokea,i. Dann ist Array max. 25% schneller. Spannend ist der Unterschied bei den verschiedenen i% Werten.
Bei i% scheint es umso länger zu daueren, je mehr bits gesetzt sind und umso höherwertiger sie sind. -1 dauert am längsten (klar alle Bits gesetzt). Bei den einzelnen Bits: 16384 am Kürzesten. 8192 dauert einen kleinen Hauch länger... usw usf. bis 1 (bei meinem Programm sind es jeweils 5 TI-Einheiten). Nur -32768 schlägt aus der Reihe, das braucht ungefähr solange wie 2048. Och nöööö... wenn ich einem INTEGER-Array eine Fließkommazahl zuweise ist er in der Regel schneller als bei einer INTEGER-Zahl. Das hat dann aber nichts mehr mit Interpreter vs. Compiler zu tun, sondern dass Basic V2 schräg ist.
Aber der Vorteil schrumpft deutlich und wenn die Auslese und Oder-Verknüpfungen bei Ganzzahlen ähnlich schleichen wie der zum setzen wundert mich gar nix mehr.
Das Integer immer mit Floats gerechnet werden hat ja Mike schon ausführlich erklärt. Vielleicht ergänzend zu oben: Die Variation in der Zeit bei unterschiedlichen Werten kommt wohl von der Konvertierung Integer-Float. Eigentlich eine relativ einfache Operation, aber da die Float im "normalisierten" Format sind, fallen dann bei der Mantissennormalisierung, d.h. die gesamte Mantisse (4 Bytes) muss iterativ mit Schiebeoperationen so oft verschoben werden, bis das höchstwertige Bit quasi ganz "links" ist. D.h. z.B. -1 (bei Float ist das Vorzeichen extra) ergäbe das dann 1, also %0000 0000 0000 0001 und dieses eine Bit muss dann ganz nach links wandern. Die Trivialoptimierung, Nullbytes der Mantisse (rechts davon) nicht mitzuverschieben, verringert den Aufwand nur marginal. Das also bei Integer zu Float. Ähnliches Spielchen dann in die andere Richtung. ![]()
Das ist aber keine Besonderheit von BASIC V2, das wäre bei allen Interpretern so, die die Zahlen so darstellen, wenn man mal davon absieht, dass V2 hier generell nur mit Float rechnet (das war aber wirklich dem Platzmangel im ROM geschuldet - beim BASIC 3.5 oder 7.0 hat man sich dann auch nicht mehr getraut Bewährtes gravierend umzuschreiben und wohl eher auf neue Kommandos Wert gelegt).