|
@@ -0,0 +1,346 @@
|
|
1
|
+ Nils Dagsson Moskopp // erlehmann
|
|
2
|
+ http://dieweltistgarnichtso.net
|
|
3
|
+ December 2011
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+ The application/x-glitch Media Type for the glitch file format
|
|
7
|
+
|
|
8
|
+Status of This Memo
|
|
9
|
+
|
|
10
|
+ This memo provides information for the Internet community. It does
|
|
11
|
+ not specify an Internet standard of any kind. This memo is licensed
|
|
12
|
+ under the Creative Commons Share-Alike license, either Version 3, or,
|
|
13
|
+ at your option, any later version.
|
|
14
|
+
|
|
15
|
+Abstract
|
|
16
|
+
|
|
17
|
+ The glitch file format is a lightweight, text-based, language-
|
|
18
|
+ independent program interchange format. It is used to specify
|
|
19
|
+ programs to be executed on a stack machine that generates a
|
|
20
|
+ bitstream.
|
|
21
|
+
|
|
22
|
+ Outputs of such programs are commonly interpreted as audio waveforms.
|
|
23
|
+ Doing this, many programs have been found to produce interesting
|
|
24
|
+ musical results, referred to as “bytebeat” [BYTEBEAT].
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+1. Introduction
|
|
28
|
+
|
|
29
|
+ The glitch file format is a text format for the serialization of
|
|
30
|
+ programs generating bitstreams. It is derived from the implementation
|
|
31
|
+ of the iOS application Glitch Machine [GLITCHMACHINE].
|
|
32
|
+
|
|
33
|
+ Programs noted in the glitch file format (glitches) contain
|
|
34
|
+ instructions for a stack machine and integer constants. Its design
|
|
35
|
+ goals were for it to be minimal, portable and textual.
|
|
36
|
+
|
|
37
|
+ The glitch file format was intended to be usable in microblogging
|
|
38
|
+ applications. Those commonly limit textual messages to 140 characters
|
|
39
|
+ to force messages to be terse and discourage intelligent discourse
|
|
40
|
+ [HTML].
|
|
41
|
+
|
|
42
|
+1.1. Conventions Used in This Document
|
|
43
|
+
|
|
44
|
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
45
|
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
46
|
+ document are to be interpreted as described in [RFC2119].
|
|
47
|
+
|
|
48
|
+ The grammatical rules in this document are to be interpreted as
|
|
49
|
+ described in [RFC4234].
|
|
50
|
+
|
|
51
|
+2. Glitch File Format Grammar
|
|
52
|
+
|
|
53
|
+ A glitch consists of sequences of characters. In general, a glitch is
|
|
54
|
+ written as follows:
|
|
55
|
+
|
|
56
|
+ <title>!<instructions>
|
|
57
|
+
|
|
58
|
+ Title names consist of a sequence of zero or more characters, with
|
|
59
|
+ an upper limit of 16 characters. The lower case letters "a"--"z",
|
|
60
|
+ digits and the character underscore ("_") are allowed.
|
|
61
|
+
|
|
62
|
+ Instructions consist of one or more lines, with an upper limit of 16
|
|
63
|
+ lines.
|
|
64
|
+
|
|
65
|
+ Lines start with an exclamation mark followed by a sequence of one or
|
|
66
|
+ more token, with an upper limit of 16 tokens.
|
|
67
|
+
|
|
68
|
+ A tokens can be an opcode, a number or a period (".").
|
|
69
|
+
|
|
70
|
+ Opcodes tokens consist of single characters. The upper case letters
|
|
71
|
+ "G"--"Z" and the lower case letters "a"--"z" are allowed.
|
|
72
|
+
|
|
73
|
+ Numbers tokens consist of one to eight characters. The upper case
|
|
74
|
+ letters "A"--"F" and the numbers "0"--"9" are allowed.
|
|
75
|
+
|
|
76
|
+ Periods tokens are used as spacers whenever two numbers would
|
|
77
|
+ otherwise be directly adjacent.
|
|
78
|
+
|
|
79
|
+2.1 ABNF for the Glitch File Format
|
|
80
|
+
|
|
81
|
+ alphalower = %x61-7A
|
|
82
|
+ underscore = %x5F
|
|
83
|
+ title = 0*16(alphalower / digit / underscore)
|
|
84
|
+
|
|
85
|
+ opcode = %x47-5A / %x61-7A
|
|
86
|
+ number = 1*8hexdig
|
|
87
|
+ period = %x2E
|
|
88
|
+ token = opcode / number / period
|
|
89
|
+
|
|
90
|
+ newline = %0x21
|
|
91
|
+ line = newline 1*16token
|
|
92
|
+
|
|
93
|
+ instructions = 1*16line
|
|
94
|
+ glitch = title instructions [%x0A]
|
|
95
|
+
|
|
96
|
+
|
|
97
|
+2.2. Advice for Implementors
|
|
98
|
+
|
|
99
|
+ For interoperability with implementations using fixed-width glyphs,
|
|
100
|
+ programs SHOULD NOT produce glitches with lines of more than 16
|
|
101
|
+ characters.
|
|
102
|
+
|
|
103
|
+ Programs interpreting glitches SHOULD output a warning when
|
|
104
|
+ encountering any title or line exceeding 16 characters. For
|
|
105
|
+ robustness, programs SHOULD try to interpret such input, by
|
|
106
|
+ truncating the title to 16 characters and splitting lines.
|
|
107
|
+
|
|
108
|
+ If a program automatically truncates or splits lines, it SHOULD
|
|
109
|
+ output a warning and SHOULD NOT let users save the changed content
|
|
110
|
+ without further user intervention.
|
|
111
|
+
|
|
112
|
+ Programs interpreting glitches MUST output a warning when
|
|
113
|
+ encountering a sequence of more than eight characters from the set of
|
|
114
|
+ the upper case letters "A"--"F" and the numbers "0"--"9" and SHOULD
|
|
115
|
+ stop interpretation.
|
|
116
|
+
|
|
117
|
+ Programs interpreting glitches MUST output a warning when
|
|
118
|
+ encountering any character other than "A"--"Z", "a"--"z", "0"--"9",
|
|
119
|
+ "_", ".", "!" or a single new line (LF) at the end of input and
|
|
120
|
+ SHOULD stop interpretation.
|
|
121
|
+
|
|
122
|
+ Warnings MUST NOT be output to the standard output.
|
|
123
|
+
|
|
124
|
+3. Glitch Stack Machine
|
|
125
|
+
|
|
126
|
+3.1. Stack Machine
|
|
127
|
+
|
|
128
|
+ Interpreting programs written in the glitch file format is done using
|
|
129
|
+ a virtual stack machine. The stack is a ring buffer with 256 cells
|
|
130
|
+ that can hold an unsigned 32-bit integer and are initialized to hold
|
|
131
|
+ a value of zero (0). In this context, setting a cell to a value means
|
|
132
|
+ setting it to that value truncated to the last 32bits.
|
|
133
|
+
|
|
134
|
+ A top-of-stack pointer (TOSP), holding an unsigned 8-bit integer,
|
|
135
|
+ points to the current cell. Pushing a value to the stack means adding
|
|
136
|
+ one (1) to the TOSP, then setting the current cell to that value.
|
|
137
|
+ Popping from the stack means getting the current value, then subtracting
|
|
138
|
+ one (1) from the TOSP.
|
|
139
|
+
|
|
140
|
+ The stack machine has a global register referred to as “t”.
|
|
141
|
+
|
|
142
|
+ […]
|
|
143
|
+
|
|
144
|
+3.2. Tokenizer
|
|
145
|
+
|
|
146
|
+ […]
|
|
147
|
+
|
|
148
|
+3.3. Opcodes
|
|
149
|
+
|
|
150
|
+ The following table details opcode names and their shorthands. For
|
|
151
|
+ brevity, abbreviations are used for the top-of-stack pointer (TOSP),
|
|
152
|
+ cell values (using stack indices within brackets “[” and “]”) and
|
|
153
|
+ values retrieved or computed in previous numbered steps (V1, V2 …).
|
|
154
|
+
|
|
155
|
+ Shorthand Name Description
|
|
156
|
+
|
|
157
|
+ a T 1. Push the value of t to the stack.
|
|
158
|
+
|
|
159
|
+ b PUT 1. Get [TOSP].
|
|
160
|
+ 2. Compute V1 modulo 256.
|
|
161
|
+ 3. Compute V2 plus 1.
|
|
162
|
+ 4. Get [TOSP + 1]
|
|
163
|
+ 5. Set [TOSP - V3] to V4.
|
|
164
|
+ 6. Pop the stack.
|
|
165
|
+
|
|
166
|
+ c DROP 1. Pop from the stack.
|
|
167
|
+
|
|
168
|
+ d MUL 1. Pop from the stack.
|
|
169
|
+ 2. Pop from the stack.
|
|
170
|
+ 3. Multiply V2 and V1.
|
|
171
|
+ 4. Push V3 to the stack.
|
|
172
|
+
|
|
173
|
+ e DIV 1. Pop from the stack.
|
|
174
|
+ 2. Pop from the stack.
|
|
175
|
+ 3. Divide V2 by V1, in case of a division by
|
|
176
|
+ zero yielding zero.
|
|
177
|
+ 4. Push V3 to the stack.
|
|
178
|
+
|
|
179
|
+ f ADD 1. Pop from the stack.
|
|
180
|
+ 2. Pop from the stack.
|
|
181
|
+ 3. Add V2 and V1.
|
|
182
|
+ 4. Push V3 to the stack.
|
|
183
|
+
|
|
184
|
+ g SUB 1. Pop from the stack.
|
|
185
|
+ 2. Pop from the stack.
|
|
186
|
+ 3. From V2, subtract V1.
|
|
187
|
+ 4. Push V3 to the stack.
|
|
188
|
+
|
|
189
|
+ h MOD 1. Pop from the stack.
|
|
190
|
+ 2. Pop from the stack.
|
|
191
|
+ 3. Compute V2 modulo V1, in case of a
|
|
192
|
+ division by zero yielding zero.
|
|
193
|
+ 4. Push V3 to the stack.
|
|
194
|
+
|
|
195
|
+ j LSHIFT 1. Pop from the stack.
|
|
196
|
+ 2. Pop from the stack.
|
|
197
|
+ 3. Compute V2 bit-shifted to the left by V1,
|
|
198
|
+ shifting in zeros, in case of an overflow
|
|
199
|
+ yielding zero.
|
|
200
|
+ 4. Push V3 to the stack.
|
|
201
|
+
|
|
202
|
+ k RSHIFT 1. Pop from the stack.
|
|
203
|
+ 2. Pop from the stack.
|
|
204
|
+ 3. Compute V2 bit-shifted to the right by V1,
|
|
205
|
+ shifting in zeros, in case of an overflow
|
|
206
|
+ yielding zero.
|
|
207
|
+ 4. Push V3 to the stack.
|
|
208
|
+
|
|
209
|
+ l AND 1. Pop from the stack.
|
|
210
|
+ 2. Pop from the stack.
|
|
211
|
+ 3. Compute a bitwise AND of V2 and V1.
|
|
212
|
+ 4. Push V3 to the stack.
|
|
213
|
+
|
|
214
|
+ m OR 1. Pop from the stack.
|
|
215
|
+ 2. Pop from the stack.
|
|
216
|
+ 3. Compute a bitwise OR of V2 and V1.
|
|
217
|
+ 4. Push V3 to the stack.
|
|
218
|
+
|
|
219
|
+ n XOR 1. Pop from the stack.
|
|
220
|
+ 2. Pop from the stack.
|
|
221
|
+ 3. Compute a bitwise XOR of V2 and V1.
|
|
222
|
+ 4. Push V3 to the stack.
|
|
223
|
+
|
|
224
|
+ o NOT 1. Pop from the stack.
|
|
225
|
+ 2. Compute the bitwise NOT of V1.
|
|
226
|
+ 3. Push V2 to the stack.
|
|
227
|
+
|
|
228
|
+ p DUP 1. Pop from the stack.
|
|
229
|
+ 2. Push V1 to the stack.
|
|
230
|
+ 3. Push V1 to the stack.
|
|
231
|
+
|
|
232
|
+ q PICK 1. Get [TOSP].
|
|
233
|
+ 2. Compute V1 plus 1.
|
|
234
|
+ 3. Compute V2 modulo 256.
|
|
235
|
+ 4. Get [TOSP - V3].
|
|
236
|
+ 5. Pop the stack.
|
|
237
|
+ 6. Push V4 to the stack.
|
|
238
|
+
|
|
239
|
+ r SWAP 1. Pop from the stack.
|
|
240
|
+ 2. Pop from the stack.
|
|
241
|
+ 3. Push V1 to the stack.
|
|
242
|
+ 4. Push V2 to the stack.
|
|
243
|
+
|
|
244
|
+ s LT 1. Pop from the stack.
|
|
245
|
+ 2. Pop from the stack.
|
|
246
|
+ 3. If V2 is smaller than V1, push 0xFFFFFFFF
|
|
247
|
+ to the stack.
|
|
248
|
+ 4. If V2 is greater than V1, push 0x00000000
|
|
249
|
+ to the stack.
|
|
250
|
+
|
|
251
|
+ t GT 1. Pop from the stack.
|
|
252
|
+ 2. Pop from the stack.
|
|
253
|
+ 3. If V2 is greater than V1, push 0xFFFFFFFF
|
|
254
|
+ to the stack.
|
|
255
|
+ 4. If V2 is smaller than V1, push 0x00000000
|
|
256
|
+ to the stack.
|
|
257
|
+
|
|
258
|
+ u EQ 1. Pop from the stack.
|
|
259
|
+ 2. Pop from the stack.
|
|
260
|
+ 3. If V2 and V1 are equal, push 0xFFFFFFFF to
|
|
261
|
+ the stack.
|
|
262
|
+ 4. If V2 and V1 are not equal, push
|
|
263
|
+ 0x00000000 to the stack.
|
|
264
|
+
|
|
265
|
+ Not listed lower case and upper case letters are reserved and MUST
|
|
266
|
+ NOT be used for opcodes. Additional opcodes can be added to the
|
|
267
|
+ specification as soon as two independent implementations with equal
|
|
268
|
+ output exist and at least one other implementator pledges to also
|
|
269
|
+ implement the specified behaviour.
|
|
270
|
+
|
|
271
|
+ Programs interpreting glitches MAY optimize opcode behaviour, if the
|
|
272
|
+ output does not change.
|
|
273
|
+
|
|
274
|
+3.4. Execution and Output
|
|
275
|
+
|
|
276
|
+ Programs interpreting glitches SHOULD execute all contained opcodes
|
|
277
|
+ 8000 times per second. Programs MUST preserve the contents of the
|
|
278
|
+ stack between successive interpretations of the same glitch.
|
|
279
|
+
|
|
280
|
+ After each time a glitch is executed, a program MUST add one to the
|
|
281
|
+ value of t. The last 8 bits of the value on the top of the stack
|
|
282
|
+ at this time are then taken as a sample. Samples SHOULD be written to
|
|
283
|
+ standard output, sound devices or files.
|
|
284
|
+
|
|
285
|
+ Sample output MAY happen immediately or be buffered. If buffering is
|
|
286
|
+ used, programs that output samples on standard output SHOULD buffer
|
|
287
|
+ at most 256 samples at a time. The resulting output frequency of
|
|
288
|
+ 31.25hz is adequate for visualisations.
|
|
289
|
+
|
|
290
|
+4. IANA Considerations
|
|
291
|
+
|
|
292
|
+ The MIME media type for the glitch file format is
|
|
293
|
+ application/x-glitch.
|
|
294
|
+
|
|
295
|
+ Type name: application
|
|
296
|
+
|
|
297
|
+ Subtype name: x-glitch
|
|
298
|
+
|
|
299
|
+ Required parameters: n/a
|
|
300
|
+
|
|
301
|
+ Optional parameters: n/a
|
|
302
|
+
|
|
303
|
+ Encoding considerations:
|
|
304
|
+
|
|
305
|
+ A glitch MUST be represented using ASCII.
|
|
306
|
+
|
|
307
|
+
|
|
308
|
+5. Security Considerations
|
|
309
|
+
|
|
310
|
+ The glitch file format does not in itself pose a security threat. Due
|
|
311
|
+ to lack of branching and looping instructions a conforming
|
|
312
|
+ implementation can not enter an infinite loop.
|
|
313
|
+
|
|
314
|
+ Implementors SHOULD ensure their implementations handle variable
|
|
315
|
+ overflows and underflows securely. Users SHOULD take note that there
|
|
316
|
+ is no general guarantee that an implementation contains no security
|
|
317
|
+ holes.
|
|
318
|
+
|
|
319
|
+6. Applications that use this media type
|
|
320
|
+
|
|
321
|
+ The glitch file format has been used in libglitch [LIBGLITCH].
|
|
322
|
+
|
|
323
|
+
|
|
324
|
+7. References
|
|
325
|
+
|
|
326
|
+7.1. Normative References
|
|
327
|
+
|
|
328
|
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
329
|
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
330
|
+
|
|
331
|
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|
332
|
+ Specifications: ABNF", RFC 4234, October 2005.
|
|
333
|
+
|
|
334
|
+7.2. Informative References
|
|
335
|
+
|
|
336
|
+ [BYTEBEAT] <http://canonical.org/~kragen/bytebeat/>
|
|
337
|
+
|
|
338
|
+ [GLITCHMACHINE]
|
|
339
|
+ <http://madgarden.net/apps/glitch-machine/>
|
|
340
|
+
|
|
341
|
+ [HTML]
|
|
342
|
+ <http://www.whatwg.org/specs/web-apps/current-work/
|
|
343
|
+ multipage/common-input-element-attributes.html
|
|
344
|
+ #attr-input-maxlength>
|
|
345
|
+
|
|
346
|
+ [LIBGLITCH] <https://github.com/erlehmann/libglitch>
|