Raw data section

data(...) stores immutable bytes at the start of the compiled virtual data space:

raw-data-section.gpc

data(20, 42, 35, 255, 1, 100, 0, 86);

int signed_value;
int unsigned_value;

main {
    signed_value = dint8(3);    // -1 from byte 0xFF
    unsigned_value = duint8(3); // 255
}

data(...) also accepts values wider than one byte. The compiler splits a wider value into multiple bytes and warns because every later byte offset moves:

Source value range	Storage on the current Zen target	Warning
-128..255	1 byte	None for width
-32768..65535 outside the one-byte range	2 bytes	Later indexes shift by 1
Values outside the two-byte range	4 bytes	Later indexes shift by 3

raw-data-widths.gpc

data(0x12, 0x1234, 0x12345678);

int byte_value;
int word_value;
int dword_value;

main {
    byte_value = duint8(0);
    word_value = duint16(1);
    dword_value = dint32(3);
}

If exact packed bytes matter, spelling out each byte is easier to audit and avoids accidental offset changes.

Live readers:

Reader	Bytes	Interpretation
dint8(index)	1	signed 8-bit
duint8(index)	1	unsigned 8-bit
dint16(index)	2	signed 16-bit
duint16(index)	2	unsigned 16-bit
dint32(index)	4	signed 32-bit

Indexes are byte offsets. A wider entry shifts every following offset. Prefer compiler-managed const arrays for ordinary tables; use raw data when exact packed layout is the point.