Einen MC wie die CC1 in Basic zu programmieren, ist nicht ganz blöd; vor allem, weils die die Alternative "Basic compilieren und dann als Maschinencode laufen lassen" in dieser Form bei der CC1 gar nicht gibt:

1. Die CC1 hat zwar "viel" ROM (so um die 6KB), aber da kann man ja nix reinladen. Drum ist da die CBASIC Runtime drin.
2. Die CC1 hat nur wenig EEPROM in der CPU (256 B); da kann man zwar bisschen was reinladen, aber kaum ein "sinnvolles" Programm. Drum werden da bei Bedarf nur Assembler Hilfsroutinen geladen.
3. An die CC1 kann man aber ganz leicht ein EEPROM anschliessen (über I2C bus), aber da kann man nur BIT-SERIELL zugreifen - na ja: die CC1 hat ja auch keinen "Adress-Bus" wie eine "richtige" CPU (ist halt ein MC, kein PC). In diesem EEPROM kann die CPU deshalb keine Programme ausführen. Drum werden da die CBASIC tokens reingeladen, und die CBASIC runtime, die im CPU ROM läuft, liest diese token dann bei Bedarf raus und führt sie aus.

Also: viel Alternativen gibts eh nicht, um ein Programm in Maschinencode direkt auf der CC1 auszuführen.

Und: Direkter Maschinencode im Gegensatz zu Interpreter für "tokens" (CBASIC) oder "PCODE" (Pascal) oder "virtuelle Op-Codes" (Java VM) ist sowieso mehr eine Philosophie-Frage als ein Performance-Problem: "gute" Interpreter sind ähnlich schnell wie Maschinencode, und "gute" runtime ist ähnlich kompakt wie Interpreter.
Aber Interpreter-Sprachen haben einige Vorteile "per Konstruktion": leichter zu lernen, schneller zu programmieren, wartungsfreundlicher, weniger fehleranfällig und liefern auf jeden Fall "mehr Leistung pro Op-Code".

Trotzdem ist CBASIC um Dimensionen (!) langsamer als Maschinencode. Aber das liegt vermutlich ganz stark daran, dass ja jedes Byte eines Tokens einzeln und bit-weise über den I2C - Bus aus dem EEPROM gelesen werden muss, bevor es verarbeitet werden kann. Und für jedes einzelne Byte werden dabei schon einige CPU-Zyklen verbraten...