Was ist Tachyon?

.:.:– TACHYON –:.:.

 

Hmm, hab ich doch in dem Beitrag zum Geschwindigkeitsvergleich glatt vergessen zu erwähnen was Tachyon überhaupt ist. Ok, das holen wir hier mal nach! Lassen wir einfach Peter Jakacki – dem Entwickler von Tachyon – zu Wort kommen: „TACHYON – A Fast and small Forth byte code VM„. Tachyon ist also wie m ein Forth-Derivat mit einigen wirklich interessanten Eigenschaften.  Das primäre Ziel ähnelt PropForth: Es soll ein interaktives Entwicklungswerkzeug sein, welches auf einem Propellerchip läuft und typisch über die serielle Schnittstelle und ein Terminalprogramm auf einem Hostcomputer bedient wird. Man kann es also nicht wirklich mit m und mental vergleichen, welches ja dem Hive mit seinen drei Propellerchips auf den Leib geschneidert ist. Im Gegensatz zu PropForth ist Tachyon sehr schnell und wahrscheinlich auch recht klein – genaue Zahlen zum Speicherverbrauch habe ich aber leider noch nicht. Da es aber ein klassisches Forthmodell ist, dürfte es auch mehr Speicher belegen als der m-Core, welcher ja viele Aufgaben nebenläufig auf die beiden Slaves verteilt.

Tachyon verwendet einen Bytecode (8 Bit) im Gegensatz zum Wortcode (16 Bit) von m. Ich habe es nicht genau untersucht, aber es ist durchaus möglich, dass auch der 16 Bit Wortcode von m letztlich kompakter als der Bytecode von Tachyon ist, da der Aufruf eines sekundären Wortes im hRAM letztlich im Bytecode aus drei Bytes besteht( Bytecode + 2 Byte Adresse), während m dafür konstant nur zwei Bytes benötigt – das spart Speicher und auch Ausführungsgeschwindigkeit.

Interessant auf den ersten Blick die drei Stacks für Daten, Return und Loop. Ob und welche Stacks im COG-RAM oder im Hub-RAM implementiert sind, kann ich auch noch nicht sehen. Wortheader werden platzsparend im EEPROM verwaltet.

Hier die Features im Überblick:

TACHYON

A very fast and very small Forth byte code interpreter for the Propeller chip.
2012 Peter Jakacki

Features:
– Low level words are written in PASM and accessed by the
Forth run-time interpreter as single byte codes.
Byte codes are read from hub RAM and executed in PASM
Byte codes $00..$BF are PASM primitives expaned to 9-bits to directly address COG code
Byte codes $C0..$FF are calls to kernel byte code defs via table in hub RAM

– Support for LMM operations
– Interpreted byte code definitions are referenced either as:
– 1 byte – codes $C0..$FF index their definitions via a table – used as part of compiled kernel
– 2 bytes – RCALL opcode + relative byte (always referenced backwards) (extra 4 bits in opcode = -4096 range)
There are 16 entires in the COG for the RCALL byte code + extra address bits
– 3 bytes – WCALL byte code + 16-bit relative address
– All literals and strings are byte aligned
– Fast I/O bit-bashing support
– Flexible SPI PASM code support words in kernel
Constuct fast serial drivers with minimal code

– Holds Forth headers in EEPROM or SD storage
Searches the dictionary using rapid index key searching by first character
No hub RAM is used by headers
Even 32K EEPROMs can be used if the area is in RAM is normally rewritten (i.e. video memory)
Option to hold additional information per defintion such as stack usage and description

– Kernel compiled in standard manner via Spin tools so other Spin objects can be combined

– Three stacks in COG RAM: Data, Return, and Loop
Access loop indices outside of definitions
Avoids manipulation and corruption of return stack
Static stack arrays for direct addressing of stack items
Intrinsically safe stack overflow and underflow

Some early unoptimized observations:
– Empty loops can execute in 500ns to 825ns (absolute worst case)
Two to one stack operations ( + * AND etc) inc opcode fetch take 900ns to 1.087us (absolute worse case)

Und letztlich noch die Links für weitere Recherchen:

Link: Tychyon-Tread im Parallax Forum
Link: Webseite zur Software mit Tutorial