1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!ENTITY % version-entities SYSTEM "version.entities">
%version-entities;
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
]>
<refentry id="orc-tutorial" revision="29 may 2009">
<refmeta>
<refentrytitle>Orc Tutorial</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>Orc</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Orc Tutorial</refname>
<refpurpose>
Getting started writing Orc code.
</refpurpose>
</refnamediv>
<refsect1>
<title>Orc Tutorial</title>
<para>
This section walks you through several examples of increasing
complexity to get you started working with Orc. Each of these
examples are available in the Orc source code, in the examples
directory. The first three examples use static Orc code that
is in a source file, and is compiled into intermediate C code
by the orcc tool.
</para>
<para>
The first example demonstrates how to add two arrays of 16-bit
signed integers together. A possible use case for this is
combining two stereo audio streams together.
</para>
<para>
The second example builds from the first, replacing one of the
stereo input streams with a mono stream, converting it to stereo
in the process, and also adjusting the volume of the stream.
</para>
<para>
The third example shows how to convert a planar 4:2:0 video
image into a packed 4:4:4 video image with an alpha channel.
</para>
</refsect1>
<refsect1>
<title>Example 1</title>
<para>
This example demonstrates combining two stereo audio streams
by adding. Uncompressed audio streams (i.e., PCM format) can
be in a variety of formats, but one of the most common is
interleaved signed 16-bit integers, and we will choose that
for the purposes of this example. Extending to other formats
is left as an exercise for the reader. Interleaved means that
left and right channel samples are consecutive: in memory, the
data look like LRLRLR... The sampling rate is unimportant, as
long as both streams are the same.
</para>
<para>
One important feature/limitation of signed 16-bit audio samples
is that adding two together could cause an overflow. For example,
adding the value 25000 to 10000 gives 35000, but this overflows
16 bits, so a standard addition would instead give the value
-30536 (35000-65536). Overflows handled this way sound like
crackling or worse, so we would like a better solution. One
solution is to use saturating addition: in this case, the addition
of 25000 and 10000 would be limited by the upper end of signed
16-bit values to give 32767. Although this still causes
distortion in the output signal, it is much less audible and
annoying.
</para>
<para>
In normal C code, 16-bit saturating addition is difficult to express
without using 32-bit intermediates. In Orc, saturating addition
is a basic operation with opcodes for each size, both signed and
unsigned. In this case, we want "addssw", for "add signed saturated
word".
</para>
<para>
Also, we're going to make a one simplification: Adding two
interleaved stereo streams is the same as adding two mono streams
with twice as many samples. So we'll use 2*n_samples in the calling
code.
</para>
<para>
To the code:
<programlisting>
.function audio_add_s16
.dest 2 d1
.source 2 s1
.source 2 s2
addssw d1, s1, s2
</programlisting>
</para>
<para>
Line by line:
<programlisting>
.function audio_add_s16
</programlisting>
This starts a function. A function (represented internally by the
object OrcProgram) is equivalent to a C function. When you generate
C code from this Orc exmaple using the orcc tool, it generates a C
stub function called "audio_add_s16()", which at runtime will
generate an OrcProgram object corresponding to the above code,
compile it, and then run it.
<programlisting>
.dest 2 d1 short
</programlisting>
This specifies that you want a destination (output) array named "d1",
with the element size being 2. Orc does not differentiate between
signed and unsigned arrays (or even floating point), however, you
may optionally specify a type afterwards that will be used in any
autogenerated C code.
<programlisting>
.source 2 s1 short
.source 2 s2 short
</programlisting>
This specifies that you want two source (input) arrays, "s1" and "s2",
similar to the destination array.
<programlisting>
addssw d1, s1, s2
</programlisting>
This specifies the (only) opcode that we want for this program: signed
saturated addition of each member of the two source arrays, and store
the result in the destination array.
</para>
<para>
A few notes about the above program: The loop over the array members
is implied. Everything that Orc does is based on looping over each
array element and executing the opcodes in a program.
</para>
<para>
When you generate C code from the above Orc code using
'orcc --implementation example1.orc',
you get a bunch of boilerplate code, plus three C functions:
<programlisting>
/* audio_add_s16 */
#ifdef DISABLE_ORC
void
audio_add_s16 (int16 * d1, const int16 * s1, const int16 * s2, int n)
{
...
}
</programlisting>
This function is used if DISABLE_ORC is defined. As one might guess,
if you define DISABLE_ORC, no runtime Orc features are used, and all
calls to audio_add_s16() use this function. The interior of the function
is a for() loop that implements the Orc function. The generated code
may not necessarily be easy to read, but it is straightforward: all
the verbosity and use of unions is to avoid compiler warnings without
making the compiler too complex. But this is the place to go if you
are trying to understand what Orc is doing.
<programlisting>
#else
static void
_backup_audio_add_s16 (OrcExecutor * ORC_RESTRICT ex)
{
...
}
</programlisting>
This function is used when runtime Orc is enabled, but Orc was unable
to generate code for the function at runtime. There are various
reasons why that might happen -- unimplemented rules for a target, or
more temporary variables used than available registers.
<programlisting>
void
audio_add_s16 (short * d1, const short * s1, const short * s2, int n)
{
...
}
</programlisting>
The third generated function is the important part: It is used when
Orc is enabled at runtime, and creates the OrcProgram corresponding
to the function you defined. Then it compiles the function and
calls it.
</para>
<para>
After generating the C code, you should generate the header file,
using: 'orcc --header example1orc.orc -o example1orc.h'.
After similar boilerplate code, there is the expected declaration
of audio_add_s16():
<programlisting>
void audio_add_s16 (short * d1, const short * s1, const short * s2, int n);
</programlisting>
</para>
<para>
Some C code to generate sample data, call the generated code, and
print out the results:
<programlisting>
#include <stdio.h>
#include "example1orc.h"
#define N 10
short a[N];
short b[N];
short c[N];
int
main (int argc, char *argv[])
{
int i;
/* Create some data in the source arrays */
for(i=0;i < N;i++){
a[i] = 100*i;
b[i] = 32000;
}
/* Call a function that uses Orc */
audio_add_s16 (c, a, b, N);
/* Print the results */
for(i=0;i < N;i++){
printf("%d: %d %d -> %d\n", i, a[i], b[i], c[i]);
}
return 0;
}
</programlisting>
</para>
<para>
The output of the program:
<programlisting>
0: 0 32000 -> 32000
1: 100 32000 -> 32100
2: 200 32000 -> 32200
3: 300 32000 -> 32300
4: 400 32000 -> 32400
5: 500 32000 -> 32500
6: 600 32000 -> 32600
7: 700 32000 -> 32700
8: 800 32000 -> 32767
9: 900 32000 -> 32767
</programlisting>
</para>
<para>
</para>
</refsect1>
<refsect1>
<title>Example 2</title>
<para>
In this example, we will expand on the previous example by making
one of the input arrays a mono stream, and also scale the mono
input stream by a volume. Rather than iterating over each
signed 16-bit value, in this example we will iterate over samples,
meaning the member size for the stereo arrays is 4, since each
array member contains a left and right 16 bit value.
</para>
<para>
<programlisting>
.function audio_add_mono_to_stereo_scaled_s16
.dest 4 d1 short
.source 4 s1 short
.source 2 s2 short
.param 2 volume
.temp 4 s2_scaled
.temp 2 t
.temp 4 s2_stereo
mulswl s2_scaled, s2, volume
shrsl s2_scaled, s2_scaled, 12
convssslw t, s2_scaled
mergewl s2_stereo, t, t
x2 addssw d1, s1, s2_stereo
</programlisting>
Piece by piece:
<programlisting>
.function audio_add_mono_to_stereo_scaled_s16
.dest 4 d1 short
.source 4 s1 short
.source 2 s2 short
</programlisting>
This is the same as the previous example, except that the stereo
arrays are increased in size to 4. However, we'll use the short
type, since Orc does not care what type we use, and short is
the type of the array we want to use in the C code.
<programlisting>
.param 2 volume
</programlisting>
This specifies a parameter, which is an integer that is passed to
an Orc function. In the generated C code, parameters are always of
type int. There are also float parameters for the floating point
equivalent.
<programlisting>
.temp 4 s2_scaled
.temp 2 t
.temp 4 s2_stereo
</programlisting>
This specifies a few temporary variables that are used later in the
code. These definitions are similar to defining local variables in
C code. Note that the size is important: each opcode has
specific sizes for source and destination operands, and it is
important to match these correctly with temporary variables.
<programlisting>
mulswl s2_scaled, s2, volume
shrsl s2_scaled, s2_scaled, 12
</programlisting>
This scales the mono input: signed multiply of s2 and volume, giving
a 32-bit value, and then a signed right shift by 12. Since the
second operand of mulswl is 16-bit, only the lower 16 bits of
volume will be used in the multiply. The right shift is
effectively the same as dividing by 4096. Thus, a neutral scaling
that does not increase or decrease the mono input would correspond
to calling the function with a parameter value of 4096.
<programlisting>
convssslw t, s2_scaled
mergewl s2_stereo, t, t
</programlisting>
The first instruction is "convert saturated signed 32-bit to signed
16-bit", and the second merges the two values of (16 bit) t into the
high and low halves of s2_stereo. This duplicates the mono signal
into the right and left channels. It is important to use the
saturated conversion, since the effective scaling value may have
been greater than 1.0, thus the larger values may need to be clipped.
<programlisting>
x2 addssw d1, s1, s2_stereo
</programlisting>
The "x2" prefix indicates that we want the operation specified to be
done twice, first to the upper half of all operands, and again
separately to the lower half of all operands. Since addssw is
normally a 16-bit operation, the x2 prefix causes it to be a 32-bit
operation. And so, it adds the newly created right and left values
of the scaled mono signal into the s1 signal.
</para>
<para>
There are several variations of the above program that might be
more suitable for a particular application. This function only
handles a limited dynamic range of volume scaling factors, however,
by changing the shift constant, or turning the shift into a
parameter, the dynamic range can be increased significantly.
</para>
</refsect1>
<refsect1>
<title>Example 3</title>
<para>
The third example shows how to convert a planar 4:2:0 video
image into a packed 4:4:4 video image with an alpha channel. The
first format is often referred to as I420 and the second as AYUV.
</para>
<para>
For simplicity in the following discussion, we'll assume that the
image dimensions are 640x480. The 4:2:0 subsampling means the
input chroma planes are 320x240 (subsampled by 2 in each direction).
These need to be upsampled to 640x480, then repacked with the input
Y plane, with an added dummy alpha value. There are many ways to
perform upsampling; the simplest is to duplicate each value
horizontally and vertically. The result is low quality, but
adequate for demonstration purposes.
</para>
<para>
There are several choices for the Orc array size and dimensionality.
Iterating vertically can be done in the C code or in the Orc code. If
done in the Orc code, we would need to use an array size of 240 and
have two separate arrays for the even and odd Y rows. If done in the
C code, there is no such limitation. Horizontally, the story is
different: we can use the loadupsdb opcode to duplicate each byte in
the U and V arrays, so we can iterate over 640 array elements. It
is also possible to iterate over 320 elements and duplicate the U
and V elements using mergebw. There is a very slight speed
advantage to iterating vertically in Orc, and for demonstration
purposes, we will choose to use the loadupsdb opcode, thus we will
be iterating over 320x240 elements.
</para>
<para>
The code:
<programlisting>
.function convert_I420_AYUV
.flags 2d
.dest 4 d1
.dest 4 d2
.source 1 y1
.source 1 y2
.source 1 u
.source 1 v
.const 1 c255 255
.temp 2 uv
.temp 2 ay
.temp 1 tu
.temp 1 tv
loadupdb tu, u
loadupdb tv, v
mergebw uv, tu, tv
mergebw ay, c255, y1
mergewl d1, ay, uv
mergebw ay, c255, y2
mergewl d2, ay, uv
</programlisting>
A few things of note: The ".flags 2d" line is used to indicate that
Orc should iterate over two dimensions, and generate a prototype that
includes row strides for each array and a size parameter for the
second dimension.
</para>
<para>
Since we are working on two input Y lines and two output AYUV lines
at a time, we need two source and destination arrays corresponding
to the even and odd lines. The row strides for these are doubled
compared to the normal 2-D array.
</para>
<para>
The mergebw and mergewl opcodes join two 8-bit values into one 16-bit
value (or 16-bit values into a 32-bit value) by concatinating them
in memory order. Thus, to get AYUV in memory order, we merge AY and
UV, and to get UV, we merge U and V. Since we're duplicating each
U and V line, we use the same UV value for the even and odd output
lines.
</para>
<para>
The prototype that is generated is:
<programlisting>
void convert_I420_AYUV (orc_uint32 * d1, int d1_stride, orc_uint32 * d2,
int d2_stride, const orc_uint8 * s1, int s1_stride, const orc_uint8 * s2,
int s2_stride, const orc_uint8 * s3, int s3_stride, const orc_uint8 * s4,
int s4_stride, int n, int m);
</programlisting>
The orcc tool unhelpfully changed the names of the parameters,
however, the order is standard: first destinations, then sources, then
parameters, then array sizes. Think of it like memcpy() or memset().
</para>
<para>
Calling the function:
<programlisting>
convert_I420_AYUV (output, 1280*4, output + 640, 1280 * 4,
input_y, 1280, input_y + 640, 1280,
input_u, 320, input_v, 320,
320, 240);
</programlisting>
</para>
</refsect1>
</refentry>
|