COB / BOS — Bytecode di scripting delle unità

Ogni unità di Total Annihilation esegue uno script che anima i suoi pezzi (piece), emette i lampi delle armi, riproduce effetti sonori e risponde agli eventi di gioco. Il linguaggio sorgente è BOS ("Basic Object Script"); il bytecode compilato che il motore esegue davvero è COB ("Cobble", il gioco di parole di Cavedog per "compiled BOS"). Un file per unità, chiamato come l'ObjectName dell'unità nel suo FBI.

# Decompile a unit's bytecode back to readable BOS
kbot cob decompile scripts/ARMCOM.cob

# Disassemble to opcode-level assembly with control-flow arrows
kbot cob disassemble scripts/ARMCOM.cob -a

# Lint a whole directory for common script issues
kbot cob lint scripts/ -q

# Round-trip the entire scripts/ tree to verify byte-perfect compile
kbot cob roundtrip scripts/

import "github.com/coreprime/kbot-io/formats/scripting"

cob, _ := scripting.LoadFromFile("scripts/ARMCOM.cob")
fmt.Printf("%d scripts, %d pieces\n", cob.NumScripts, cob.NumPieces)
for i, name := range cob.ScriptNames {
    fmt.Printf("  [%d] %s\n", i, name)
}

Due linguaggi, un solo formato di file#

Il motore vede soltanto il COB. Il BOS è una comodità per gli autori umani: quando "modifichi lo script di un'unità" in realtà modifichi il sorgente BOS, lo ricompili in COB e distribuisci il COB nel .ufo aggiuntivo dell'unità.

Un esempio minimo:

// armcom.bos — fragment from the Arm Commander
piece base, pelvis, lthigh, lleg;

#define SIG_WALK 2

Create() {
    hide pelvis;
    set-signal-mask SIG_WALK;
}

Walk() {
    set-signal-mask SIG_WALK;
    while (1) {
        turn lthigh to x-axis  [-25] speed [50];
        turn lleg   to x-axis  [50]  speed [100];
        wait-for-turn lthigh around x-axis;
        sleep 100;
    }
}

kbot cob compile traduce tutto questo in un blob binario. kbot cob disassemble -a mostra il flusso di opcode affiancato da frecce del flusso di controllo; kbot cob decompile fa l'operazione inversa e recupera un BOS che quasi sempre supera il round-trip identico byte per byte (kbot cob roundtrip lo verifica sull'intero catalogo del gioco).

Un sorgente viene compilato come script di TA (COB versione 4), a meno che non inizi con .version 6. Il compilatore rifiuta ciò che TA 3.1c eseguirebbe in modo errato invece di scrivere un segnaposto: i costrutti di TA: Kingdoms (play-sound, Mission-Command, __tak_math_*, .sound_name) e % sono errori in uno script di TA (TA non ha un'istruzione di modulo, e 0x10037000, la parola in cui veniva tradotto %, è il suo XOR bit a bit), così come gli identificatori sconosciuti e le funzioni che richiedono più dei 32 slot di stack del gioco. Ciò che compila comunque ma merita un'occhiata (una funzione definita due volte: ogni chiamata si lega alla prima definizione, come fa la ricerca per nome del gioco) viene stampato come avviso, insieme a ogni segnalazione delle regole di lint di compatibilità con TA; --strict fa fallire il comando in presenza di avvisi. kbot cob assemble applica gli stessi controlli ai listati scritti a mano.

Struttura su disco del COB#

typedef struct {                          // 44-byte header (11 × uint32)
    uint32 VersionSignature;              // 4 for TA, 6 for TA: Kingdoms
    uint32 NumScripts;                    // Number of functions (Create, Killed, …)
    uint32 NumPieces;                     // Number of named pieces
    uint32 LengthOfScripts;               // Total code size, in DWORDs
    uint32 NumberOfStaticVars;            // Static-variable count
    uint32 UKZero;                        // Always 0 in retail bytecode; purpose unknown
    uint32 OffsetToScriptCodeIndexArray;  // → uint32 × NumScripts: code-index per script
    uint32 OffsetToScriptNameOffsetArray; // → uint32 × NumScripts: absolute offsets into string pool
    uint32 OffsetToPieceNameOffsetArray;  // → uint32 × NumPieces: absolute offsets into string pool
    uint32 OffsetToScriptCode;            // → packed uint32 opcode stream
    uint32 OffsetToNameArray;             // Byte just past the piece-name offset array (= sound-name offset table start for TAK v6, or string-pool start for TA v4)
} COBHeader;

Seguono poi, in questa disposizione:

┌─ Script code ─────────────────────────────┐  uint32 opcodes/operands, packed
├─ Script code-index table ─────────────────┤  uint32[NumScripts] — *not* byte offsets
├─ Script name offset table ────────────────┤  uint32[NumScripts]
├─ Piece name offset table ─────────────────┤  uint32[NumPieces]
└─ String pool ─────────────────────────────┘  NUL-terminated names, in order

Risolvere uno script#

La tabella degli indici del codice contiene offset in parole uint32, non offset in byte. Per trovare il bytecode dello script numero i:

uint32 first_instr_word = ScriptCodeIndexArray[i];
uint32 byte_offset      = OffsetToScriptCode + first_instr_word * 4;

Lo script finisce dove comincia il successivo (oppure all'inizio della tabella degli indici, per l'ultimo script).

Il flusso di opcode#

COB è una macchina virtuale basata su stack. La maggior parte degli opcode estrae gli argomenti da uno stack di dati proprio di ciascuno script, fa il suo lavoro e vi inserisce un risultato. Alcuni opcode hanno operandi inline (destinazioni dei salti, numeri di pezzo).

Ogni opcode è un uint32 con questa struttura:

       MSB                          LSB
  ┌─────────┬─────────┬─────────┬─────────┐
  │   0x10  │ family  │ op      │ flags   │
  └─────────┴─────────┴─────────┴─────────┘

Il byte alto è sempre 0x10; famiglia, operazione e flag variano da opcode a opcode. Il gioco non confronta l'intera parola: smista in base a word & 0x100FF000, quindi i bit fuori da quella maschera vengono ignorati e 0x10064001 viene eseguito come JUMP (il disassemblatore di kbot scrive una parola del genere come JUMP@0x10064001, così si riassembla identica). PUSH (0x10021000) e POP (0x10023000) leggono poi la loro sorgente o destinazione dai tre bit bassi. Il catalogo è scripting/opcodes.go di kbot-io; scripting.Opcodes() elenca ogni istruzione con i suoi operandi inline e il suo effetto sullo stack.

Famiglie di opcode#

Un campionario piccolo ma rappresentativo:

0x10021001 PUSH_CONST     <value>      ( -- v )
0x10021002 PUSH_LOCAL     <var#>       ( -- v )
0x10023002 POP_LOCAL      <var#>       ( v -- )
0x10033000 MUL                         ( a b -- a*b )
0x10051000 LESS_THAN                   ( a b -- a<b )
0x10066000 JUMP_IF_FALSE <byteOffset>  ( v -- )    pops; falls through if v != 0
0x10064000 JUMP          <byteOffset>  ( -- )
0x10065000 RETURN                      ( v -- )    pops the return value
0x10001000 MOVE          <piece> <axis> ( speed distance -- )
0x10003000 SPIN          <piece> <axis> ( speed -- )
0x1000F000 EMIT_SFX      <piece>       ( flags -- )
0x10068000 SET_SIGNAL_MASK              ( mask -- )

Modello di concorrenza#

Un'unità può avere molti script in esecuzione contemporaneamente: Walk, Aim, SmokeUnit, MoveWatcher, ecc. Sono schedulati in modo cooperativo:

• sleep <ticks> cede il controllo per N tick (1/30 s ciascuno).
• wait-for-turn <piece> around <axis> cede il controllo finché quel pezzo non completa l'animazione turn in corso. Lo stesso vale per wait-for-move.
• signal <n> termina ogni script per cui signal_mask & n != 0.
• set-signal-mask <n> dichiara a quali segnali è interessato lo script corrente.

La maschera dei segnali (signal mask) è il modo in cui gli script realizzano la prelazione (preemption): MoveWatcher imposta la maschera SIG_MOVE e sorveglia la velocità; quando l'unità smette di muoversi invia SIG_MOVE, terminando in modo pulito le animazioni di camminata prima di avviare la posa di riposo.

Come si svolge davvero la prelazione#

Uno schema comune: MoveUnit avvia uno script di animazione Walk; quando il movimento si ferma, il motore invia SIG_MOVE per fare pulizia prima che parta Idle. La sequenza:

   Engine                 MoveUnit script        Walk script        Idle script
     │                          │                     │                  │
     │  unit ordered to move    │                     │                  │
     ├─ start-script MoveUnit──▶│                     │                  │
     │                          ├─ set-signal-mask    │                  │
     │                          │   SIG_MOVE          │                  │
     │                          ├─ start-script Walk─▶│                  │
     │                          │                     ├─ set-signal-mask │
     │                          │                     │   SIG_MOVE       │
     │                          │                     │ (loops:          │
     │                          │                     │   turn pieces,   │
     │                          │                     │   sleep, repeat) │
     │                          │                     │                  │
     │  movement completes      │                     │                  │
     ├─ engine sets velocity=0  │                     │                  │
     │                          ├─ signal SIG_MOVE ──┐│                  │
     │                          │                    ││                  │
     │   ◀─── KILLED ──────────────────────────────  ◀┤                  │
     │   ◀─── KILLED ──────────┤                     │                  │
     │                                                                   │
     ├─ start-script Idle ─────────────────────────────────────────────▶│
     │                                                                   │ (loops)

Tre cose da notare:

1. Entrambi gli script che impostano SIG_MOVE vengono terminati quando il segnale scatta, compreso MoveUnit stesso (non importa: il suo lavoro è finito).
2. Lo script che invia il segnale (MoveUnit) sopravvive abbastanza a lungo da inviare il segnale prima di essere terminato; il runtime controlla le maschere dopo che l'opcode signal ha restituito il controllo.
3. Idle non imposta SIG_MOVE, quindi il successivo signal SIG_MOVE non lo tocca.

Esempio svolto — cortruck.cob (Core Construction Truck)#

kbot cob decompile scripts/cortruck.cob:

piece base;

SmokeUnit() {
    var local_0, local_1, local_2;

    while (get BUILD_PERCENT_LEFT) { sleep 400; }

    while (1) {
        local_0 = get HEALTH;
        if (local_0 < 66) {
            local_2 = (256 | 2);
            if (rand(1, 66) < local_0) { local_2 = (256 | 1); }
            emit-sfx local_2 from base;
        }
        local_1 = (local_0 * 50);
        if (local_1 < 200) { local_1 = 200; }
        sleep local_1;
    }
    return 0;
}

Create() { return 0; }

Killed() {
    var severity;
    if (severity <= 25) { explode base type (32 | 256); return 0; }
    if (severity <= 50) { explode base type (32 | 256); return 0; }
    if (severity <= 99) { explode base type (32 | 256); return 0; }
    explode base type (32 | 256);
}

Il disassemblato corrispondente (kbot cob disassemble -a -s SmokeUnit) mostra il flusso di opcode effettivo, con le frecce di JUMP_IF_FALSE/JUMP che attraversano i corpi dei while/if: utile quando l'output del decompilatore è ambiguo.

Linting#

kbot cob lint (e la scheda Lint dell'esploratore di asset) esegue l'insieme di regole predefinito di kbot-io: regole di stile ricavate da bug reali negli script di Cavedog stessi e da patch di mod inviate dalla comunità, due controlli a livello di file e, per ogni COB che non dichiara la versione 6, le regole di compatibilità con TA 3.1c. Il catalogo delle regole di stile:

Le regole di compatibilità con TA segnalano ciò su cui TA 3.1c va in errore o che esegue in modo diverso. Sono errori, compaiono nell'output SARIF di --ci come le altre e saltano i file di TA: Kingdoms (versione 6):

Le descrizioni complete delle regole sono nel README di kbot. Il decompilatore conserva di proposito la numerazione originale di variabili e pezzi, così un ciclo decompilazione→lint→correzione→compilazione mette in evidenza le mod che hanno bisogno di manutenzione.

Insidie#

• Tutti gli offset nell'intestazione del COB sono offset assoluti nel file, ma le voci di ScriptCodeIndexArray sono offset in parole all'interno della sezione del codice. È facile confonderli.
• I numeri di pezzo negli opcode sono indici nella tabella dei nomi dei pezzi, non stringhe. Il COB contiene i nomi in un pool di stringhe; il runtime usa gli indici per velocità.
• Gli opcode get UNIT_VALUE differiscono in modo sottile tra TA e TA: Kingdoms. TA: Kingdoms ha aggiunto ID di valore per la rigenerazione della magia, i punti comando, ecc.; la tabella dei valori di TA è più compatta. Il decompilatore di kbot attualmente etichetta l'insieme di TA; i numeri di porta di TAK ≥ 21 vengono emessi come letterali numerici (che superano comunque il round-trip attraverso l'assemblatore). Vedi TA: Kingdoms — differenze di COB v6 per tutte le differenze.
• Le variabili sono di due tipi: local_N (slot di stack locale alla funzione) e global_N (statica per unità che persiste tra le chiamate). Il decompilatore emette local_N / global_N per impostazione predefinita; rinominale nel sorgente per renderlo più leggibile.
• Lo strumento Scriptor di Cavedog a volte rende inline CURRENT_SPEED come letterale 29, rompendo gli script in stile MoveWatcher dopo un round-trip. Il decompilatore di kbot ripristina il nome simbolico; se devi per forza passare da Scriptor, usa le parentesi: (get CURRENT_SPEED) > 5.

Dimensioni tipiche#

TA: Kingdoms — differenze di COB v6#

Struttura del file v6#

┌─ 44-byte v4 header ──────────────────────────────────┐
│ VersionSignature == 6, NumScripts, NumPieces, …      │
├─ Sub-header (8 bytes, TAK-only) ─────────────────────┤  (soundNameOffsetTableStart, soundNameCount)
├─ Script code (uint32 opcode stream) ─────────────────┤  same encoding as v4
├─ ScriptCodeIndexArray (uint32 × NumScripts) ─────────┤  unchanged
├─ ScriptNameOffsetArray (uint32 × NumScripts) ────────┤  unchanged
├─ PieceNameOffsetArray (uint32 × NumPieces) ──────────┤  unchanged
├─ SoundNameOffsetArray (uint32 × Count) ──────────────┤  TAK-only — count from sub-header[1]
└─ String pool ────────────────────────────────────────┘  script names → piece names → sound names (in that order)

La sotto-intestazione di 8 byte si trova tra OffsetToNameArray (fine dell'intestazione canonica di 11 DWORD, al byte 44) e l'inizio della sezione del codice (OffsetToScriptCode, di solito 0x34 = 52). Contiene due uint32 little-endian:

Ogni voce della tabella degli offset dei nomi dei suoni è l'offset assoluto nel file di una stringa terminata da NUL nel pool di stringhe: cose come "SetMission o 1, s", "create ARASWORD", "ARROW10". Il bytecode le richiama per indice (non per offset) tramite l'opcode MISSION_COMMAND (vedi l'Appendice C). La tabella si chiama array dei nomi dei suoni perché il compilatore canonico Scriptor vi registra le stringhe tramite l'azione ADDSOUND; il contenuto effettivo, però, sono stringhe di comando del motore e non nomi di file audio.

La rappresentazione di kbot#

scripting.COB conserva i nomi dei suoni come campo strutturato []string, senza preservare byte opachi. Tutto il resto (i valori della sotto-intestazione, la tabella degli offset, gli offset di ogni stringa nel pool) viene ricostruito da questo elenco in scrittura:

type COB struct {
    // …canonical TA fields…
    SoundNames []string // TAK-only; nil for v4
}

Per i file v4 la slice è sempre nil, e sia la sotto-intestazione sia la tabella degli offset dei nomi dei suoni vengono omesse dall'output.

Il disassemblatore e il decompilatore emettono ogni stringa come direttiva .sound_name, così sopravvivono a un round-trip attraverso .coba e .bos:

.version 6
.statics 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"
.script Start
…

Nuovi opcode#

I file .cob di TAK usano istruzioni per cui TA 3.1c non ha un gestore (PLAY_SOUND, MISSION_COMMAND e gli operatori TAK_MATH_*), più DONT_SHADOW, che TA esegue come no-op. La loro semantica esatta lato gioco non è documentata, ma la loro struttura binaria (dimensione + numero di parametri inline) è nota da ogni .cob originale di TAK, e questo basta perché il round-trip disassemblaggio→assemblaggio recuperi i byte originali alla lettera. Vedi l'Appendice C per il riferimento completo.

Stato del round-trip#

Sintassi BOS per le estensioni di TAK#

Il decompilatore emette queste pseudo-chiamate perché i COB di TAK superino il round-trip attraverso il BOS. Il compilatore accetta la stessa sintassi, ma solo dopo .version 6 (eccetto dont-shadow: TA lo esegue come no-op). dont-shadow e Mission-Command usano le parole chiave canoniche di TAK di Scriptor; gli opcode matematici non hanno un nome documentato in Scriptor (li etichetta ?? e ????), quindi kbot mantiene i segnaposto __tak_math_*:

// Statement-level (emitted on their own line):
dont-shadow(<piece>);                                  // DONT_SHADOW — disables shadow casting for one piece
Mission-Command("sound name", arg1, arg2, …);          // MISSION_COMMAND — engine call (statement form drops the return value)
return_val = Mission-Command("sound name", args…);     // assignment form keeps the pushed result

// Expression-level (binary operators: two values popped, one pushed):
local_x = __tak_math_09(a, b);   // TAK_MATH_09
local_x = __tak_math_0a(a, b);   // TAK_MATH_0A
local_x = __tak_math_0b(a, b);   // TAK_MATH_0B

Il primo argomento di Mission-Command è il nome del suono come stringa tra virgolette: il compilatore lo cerca nella tabella dei nomi dei suoni (quindi la direttiva .sound_name corrispondente deve comparire prima nel file). Gli argomenti rimanenti vengono inseriti nello stack e il motore li consuma.

Due direttive in cima al file portano il resto dei metadati v6:

.version 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"

.version viene sempre emessa (così i file v4 di TA superano il round-trip identici attraverso la stessa pipeline). Ogni .sound_name è una voce della tabella dei nomi dei suoni del COB; lo scrittore ricostruisce la sotto-intestazione di 8 byte e la tabella degli offset dei nomi dei suoni a partire da len(SoundNames) e dall'ordine in cui compaiono le voci.

L'epilogo STACK_ALLOC ; RETURN di TAK, che ogni return; senza valore emette in v6, è gestito dal compilatore: return; diventa STACK_ALLOC ; RETURN quando c'è .version 6, mentre return <expr>; diventa <expr> ; RETURN senza prefisso (come fa il compilatore di Cavedog).

Riproducilo sulla tua installazione:

kbot ctx use kingdoms  # or wherever you registered TAK
kbot cob roundtrip

Simboli delle porte oltre la porta 20#

Gli script di TA: Kingdoms usano le porte di get_unit_value fino alla 46 (CURRENT_SPEED, VETERAN_LEVEL, campi della riserva di magia, ecc.). Il decompilatore di kbot attualmente etichetta in modo simbolico solo le porte 1–20 (vedi l'Appendice B); le porte di TAK ≥ 21 vengono emesse come letterali numerici. Il bytecode le memorizza comunque come interi, quindi i round-trip non ne risentono: ne soffre solo la leggibilità del BOS. L'aggiunta dei nomi delle porte di TAK è seguita a parte.

Appendice A — Riferimento completo degli opcode#

Ogni istruzione eseguita da TA o da TA: Kingdoms. Fa fede formats/scripting/opcodes.go di kbot-io. La notazione dello stack usa lo stile Forth ( before -- after ). La colonna Inline indica quante parole uint32 seguono la parola dell'opcode stesso (consumate durante la decodifica, non dallo stack).

Animazione — manipolazione dei pezzi (0x100x)#

Operazioni di attesa (0x101x)#

Manipolazione dello stack (0x102x)#

Aritmetica (0x103x)#

TA non ha un'istruzione di modulo: % è un errore di compilazione in uno script di TA. Da 0x10039000 a 0x1003B000 ci sono gli operatori TAK_MATH_* di TA: Kingdoms (Appendice C); TA va in errore su di essi.

Interrogazioni al motore (0x104x)#

Vedi l'Appendice B per il catalogo delle porte.

Confronti e operazioni logiche (0x105x)#

Flusso di controllo e concorrenza (0x106x)#

L'offset di JUMP / JUMP_IF_FALSE è un offset in byte relativo a OffsetToScriptCode, non all'istruzione corrente.

Effetti (0x107x)#

Operazioni di impostazione (0x108x)#

Codifica degli opcode#

Ogni parola di opcode è 0x10CCSSFF, dove:

• CC = il byte di categoria (animazione, matematica, flusso di controllo, …).
• SS = il nibble del sotto-comando, nel nibble alto del secondo byte dall'alto.
• FF = il byte dei flag.

Il gioco smista in base a word & 0x100FF000 e ignora gli altri bit, quindi una parola come 0x10064001 viene eseguita come JUMP; il disassemblatore la scrive JUMP@0x10064001 e l'assemblatore la rilegge nella stessa parola. PUSH e POP leggono la loro sorgente o destinazione dai tre bit bassi: PUSH accetta 1 (costante), 2 (locale) e 4 (statica), POP accetta 2 e 4, e qualsiasi altro valore manda in errore lo script.

Le parole che nessun gioco esegue vengono rese dal disassemblatore come UNKNOWN_0x10xxxxxx (e segnalate da ta-unknown-opcode); se ne trovi una in un file reale, apri una issue allegando il COB di esempio.

Appendice B — Tabella delle porte di get_unit_value#

Le 20 porte che il decompilatore di kbot attualmente etichetta in modo simbolico. Il vero TA ne ha ~80; TA: Kingdoms ne aggiunge altre ~15 per le grandezze legate alla magia. Oggi tutto ciò che supera la porta 20 viene reso come letterale numerico nell'output del decompilatore.

Le porte più alte includono CURRENT_SPEED (29, notoriamente reso inline come letterale dallo Scriptor di Cavedog; vedi Insidie più sopra), MAX_ID, UNIT_TEAM, UNIT_BUILD_PERCENT, BUILDER, UNIT_ALLIED e molte altre. L'elenco completo si trova nella documentazione interna di Cavedog; il wiki della comunità sui forum di TAUniverse ha il catalogo pubblico più completo.

TA: Kingdoms estende l'intervallo delle porte. Le porte esclusive di TAK che kbot riconosce (il decompilatore rende il nome simbolico; il compilatore lo accetta in ingresso) sono prese dalla tabella [UNITVLAUES] di Scriptor:

Appendice C — Opcode di TA: Kingdoms#

Codifica (riepilogo)#

Ogni parola di opcode COB è 0x10CCSSFF, dove CC è la categoria e SS il sotto-comando: questi opcode di TAK occupano semplicemente slot CC:SS prima inutilizzati all'interno delle categorie esistenti, invece di introdurre un nuovo byte di categoria. DONT_SHADOW sta nella categoria dell'animazione accanto a DONT_CACHE/DONT_SHADE, e MISSION_COMMAND nella categoria degli effetti accanto a EXPLODE e PLAY_SOUND.

kbot ctx use tak-30bb-flat
kbot cob disassemble scripts/araat.cob -a | grep -E 'DONT_SHADOW|MISSION|TAK_MATH|PLAY_SOUND'

Esempi reali nel catalogo di riferimento#

Unità reali che spingono il formato ai suoi estremi: aprile per vedere la complessità effettiva degli script, invece degli esempi costruiti nel testo:

• CORKROG — Krogoth (Core) — uno dei COB più grandi del gioco (~25 KB, più di 30 script, animazioni complesse con molti pezzi).
• ARMCOM — Arm Commander — unità "ricca" rappresentativa: cicli di camminata/mira/riposo/costruzione, più armi, gestione del D-gun.
• CORTRUCK — Construction Truck — COB quasi minimo, usato come esempio guidato in questa pagina (3 script: SmokeUnit, Create, Killed).
• ARMSAM — Samson — buon esempio di unità con torretta (rotazione di turret1 per mirare, animazione di rinculo, sincronizzazione con wait-for-turn).

Decompila qualsiasi di questi in locale con kbot cob decompile scripts/<name>.cob, una volta impostato un contesto kbot.

Vedi anche#

• 3DO — i nomi dei pezzi a cui fanno riferimento gli script COB stanno nel .3do dell'unità.
• FBI — il file dei metadati dell'unità. Lì ObjectName lega il COB a un 3DO; Sounds definisce il banco audio che lo script può riprodurre.
• La tabella delle regole di cob lint della CLI di kbot.
• Glossario — pezzo (piece), asse (axis), maschera dei segnali (signal mask), tick.