Skip to content
This repository
Browse code

Merge pull request #66 from mitchskiba/master

Migrated Changes To XML
  • Loading branch information...
commit 47c8bae36ab84bce4dae02f26519e915469ce400 2 parents b40bd92 + 6345a4e
Melissa authored May 01, 2012
292  ASM/Spec_0xSCA.txt
@@ -4,7 +4,7 @@
4 4
 RFC X____                                               J. Kuijpers, Ed.
5 5
                                                                   Jarvix
6 6
                                                         M. Beermann, Ed.
7  
-                                                          April 24, 2012
  7
+                                                              April 2012
8 8
 
9 9
 
10 10
                   0xSCA: Standards Committee Assembly
@@ -62,7 +62,7 @@ Table of Contents
62 62
    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
63 63
      1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
64 64
    2.  Document Markup  . . . . . . . . . . . . . . . . . . . . . . .  3
65  
-     2.1.  Indentation and whitepace  . . . . . . . . . . . . . . . .  3
  65
+     2.1.  Indentation and whitespace . . . . . . . . . . . . . . . .  3
66 66
    3.  Case sensitivity . . . . . . . . . . . . . . . . . . . . . . .  3
67 67
    4.  Preprocessor Markup  . . . . . . . . . . . . . . . . . . . . .  3
68 68
      4.1.  Comments . . . . . . . . . . . . . . . . . . . . . . . . .  3
@@ -73,26 +73,26 @@ Table of Contents
73 73
          4.3.1.2.  Binary . . . . . . . . . . . . . . . . . . . . . .  4
74 74
        4.3.2.  Definitions  . . . . . . . . . . . . . . . . . . . . .  5
75 75
        4.3.3.  Data insertion . . . . . . . . . . . . . . . . . . . .  5
76  
-       4.3.4.  Origin relocation  . . . . . . . . . . . . . . . . . .  5
77  
-       4.3.5.  Macros: macro block and macro insertion  . . . . . . .  6
78  
-       4.3.6.  Repeat block . . . . . . . . . . . . . . . . . . . . .  6
  76
+         4.3.3.1.  Ascii Literal Flags  . . . . . . . . . . . . . . .  6
  77
+       4.3.4.  Origin relocation  . . . . . . . . . . . . . . . . . .  6
  78
+       4.3.5.  Macros: macro block and macro insertion  . . . . . . .  7
  79
+       4.3.6.  Repeat block . . . . . . . . . . . . . . . . . . . . .  7
79 80
        4.3.7.  Conditionals . . . . . . . . . . . . . . . . . . . . .  7
80  
-       4.3.8.  Error reporting  . . . . . . . . . . . . . . . . . . .  7
81  
-       4.3.9.  Alignment  . . . . . . . . . . . . . . . . . . . . . .  7
  81
+       4.3.8.  Error reporting  . . . . . . . . . . . . . . . . . . .  8
  82
+       4.3.9.  Alignment  . . . . . . . . . . . . . . . . . . . . . .  8
82 83
        4.3.10. Echo general output  . . . . . . . . . . . . . . . . .  8
83  
-   5.  Tokenizer Markup . . . . . . . . . . . . . . . . . . . . . . .  8
84  
-     5.1.  Labels . . . . . . . . . . . . . . . . . . . . . . . . . .  8
85  
-     5.2.  Inline character literals  . . . . . . . . . . . . . . . .  8
86  
-   6.  Inline arithmetic  . . . . . . . . . . . . . . . . . . . . . .  8
  84
+   5.  Tokenizer Markup . . . . . . . . . . . . . . . . . . . . . . .  9
  85
+     5.1.  Labels . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  86
+     5.2.  Inline character literals  . . . . . . . . . . . . . . . .  9
  87
+   6.  Inline arithmetic  . . . . . . . . . . . . . . . . . . . . . .  9
87 88
    7.  Conformance  . . . . . . . . . . . . . . . . . . . . . . . . .  9
88  
-     7.1.  Recognition of conformance . . . . . . . . . . . . . . . .  9
89  
-   8.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . .  9
90  
-     8.1.  Labels . . . . . . . . . . . . . . . . . . . . . . . . . .  9
91  
-     8.2.  Preprocessor . . . . . . . . . . . . . . . . . . . . . . .  9
92  
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
93  
-   10. Normative References . . . . . . . . . . . . . . . . . . . . . 10
94  
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
95  
-
  89
+     7.1.  Recognition of conformance . . . . . . . . . . . . . . . . 10
  90
+   8.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 10
  91
+     8.1.  Labels . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  92
+     8.2.  Preprocessor . . . . . . . . . . . . . . . . . . . . . . . 10
  93
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  94
+   10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
  95
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
96 96
 
97 97
 
98 98
 
@@ -133,7 +133,7 @@ Kuijpers & Beermann                                             [Page 2]
133 133
 
134 134
 2.  Document Markup
135 135
 
136  
-2.1.  Indentation and whitepace
  136
+2.1.  Indentation and whitespace
137 137
 
138 138
    Whitespace MUST be allowed between all elements of a line, including
139 139
    but not limited to opcodes, values, syntactic characters and
@@ -224,6 +224,7 @@ Kuijpers & Beermann                                             [Page 4]
224 224
 
225 225
                            Assembly Syntactics                April 2012
226 226
 
  227
+
227 228
    The latter form of incbin MUST include the file from an
228 229
    implementation defined location.
229 230
 
@@ -241,7 +242,7 @@ Kuijpers & Beermann                                             [Page 4]
241 242
    symbol does not exist compilation SHOULD continue and a warning MAY
242 243
    be emitted.
243 244
 
244  
-   Any occurances of the definition during its existence, MUST be
  245
+   Any occurrences of the definition during its existence, MUST be
245 246
    replaced with the given value to the definition.
246 247
 
247 248
 4.3.3.  Data insertion
@@ -254,89 +255,73 @@ Kuijpers & Beermann                                             [Page 4]
254 255
    dw (data word) MUST store the values literally and unpacked at the
255 256
    location of the directive.
256 257
 
257  
-   dp (data pack) MUST pack pairs of values into a single word. The
  258
+   dp (data pack) MUST pack pairs of values into a single word.  The
258 259
    first value is placed into the high octet, and the second is placed
259  
-   into the low octet of the word. Should there be an odd number of
  260
+   into the low octet of the word.  Should there be an odd number of
260 261
    values after a dp declaration, the remaining octet MUST be filled
261 262
    with the value 0.
262 263
 
263 264
    fill (fill words) MUST insert a count of words, initialized to the
264 265
    specified value.  If the value is not provided, the assembler MUST
265  
-   assusme 0.
266  
-
267  
-   ascii (ascii string) MUST pack the ascii values of the string as 
268  
-   described below.
269  
-   
270  
-   String declarations MAY have a set of control flags sepecified before
271  
-   a string contained in double quotes, and a value as allowed by flags.
272  
-   
273  
-   This will insert the ASCII values for the characters in the string,
274  
-   in a maner controlled by the flags. The optional value parameter in 
275  
-   between less than (< U+003C) and greater than (> U+003E) will be
276  
-   bitwise ORed with each character in the string.  The upper octet for
277  
-   unpacked strings will default to all 0's before the bitwise OR.
278  
-  
  266
+   assume 0.
  267
+
  268
+   ascii (ascii string) MUST pack the ascii values of the string as
  269
+   described by the flags that precede it.  An explanation of the flags
  270
+   is provided in the section on ascii flags.Section 4.3.3.1
  271
+
  272
+   The optional value parameter in between less than (< U+003C) and
  273
+   greater than (> U+003E) will be bitwise ORed with each character in
  274
+   the string.  The upper octet for unpacked strings will default to all
  275
+   0's before the bitwise OR.
  276
+
  277
+
  278
+
279 279
 Kuijpers & Beermann                                             [Page 5]
280 280
 
281 281
                            Assembly Syntactics                April 2012
282  
-   
283  
-   
284  
-   The control flags are:
285  
-
286  
-    k: The ascii values are "packed." Each character is mapped to an
287  
-	   octet of data. These are written in order. Certain other flags
288  
-	   may place octets that precede the first character's octet.
289  
-
290  
-    s: The ascii values are "packed" and "swapped." Like k, each
291  
-	   character uses one octet, however the order of the octets is
292  
-	   reversed within each word. Flags k and s are incompatible with
293  
-	   eachother. Certain other flags may place octets before the first
294  
-	   character octet.
295  
-	   
296  
-	z: Zero terminate the string, inheriting character width. A null
297  
-	   character will be appended to the string. If the string is one of
298  
-	   the packed formats only one octet will be added, where unpacked
299  
-	   strings will have a full word of zero. For the purpose of
300  
-	   determining string length, this zero counts as one character.
301  
-	   
302  
-	x: Word Zero terminate the string. This will zero terminate the
303  
-	   string, forcing a zero word onto the end of the string. If the
304  
-	   string is packed and of an odd length, a zero octet will be 
305  
-	   placed at the end of the content, before the zero word. For the 
306  
-	   purpose of determining string length, this zero will add quantity
307  
-	   of zero octets added divided by the octet width of each character.
308  
-	   
309  
-	   For example, an unpacked string will always have 1 added to the
310  
-	   string length by the Z flag. A packed string of odd length will
311  
-	   have 3 added to the string length, where an even length packed
312  
-	   string will have 2 added to the length;
313  
-	   
314  
-	   Flags w and x are incompatible.
315  
-	   
316  
-	a: Octet Pascal Length. This will prepend the length of the string
317  
-	   as an octet to the string content. This is only compatible with 
318  
-	   a packed mode, either k or s. (For swapped mode, this will end
319  
-	   up being the lower (second) octet of the first word.)
320  
-	   
321  
-	p: Word Pascal Length. This will prepend the length of the string
322  
-	   as a full word to the string content. This is compatible with 
323  
-	   either packed or unpacked modes. Flags a and p are incompatible.
324  
-
325  
-	   
326  
-   Assemblers SHOULD warn the user when string literals excede the
327  
-   length expressable in the pascal length field if the flag is set.
328  
-
329  
-
330  
-
331  
-
332  
-
333  
-
334  
-
335  
-Kuijpers & Beermann                                             [Page 6]	   
336  
-
337  
-                           Assembly Syntactics                April 2012
338  
-	   
339  
-	   
  282
+
  283
+
  284
+4.3.3.1.  Ascii Literal Flags
  285
+
  286
+   k: The ascii values are "packed."  Each character is mapped to an
  287
+   octet of data.  These are written in order.  Certain other flags may
  288
+   place octets that precede the first character's octet.
  289
+
  290
+   s: The ascii values are "packed" and "swapped."  Like k, each
  291
+   character uses one octet, however the order of the octets is reversed
  292
+   within each word.  Flags k and s are incompatible with each other.
  293
+   Certain other flags may place octets before the first character
  294
+   octet.
  295
+
  296
+   z: Zero terminate the string, inheriting character width.  A null
  297
+   character will be appended to the string.  If the string is one of
  298
+   the packed formats only one octet will be added, where unpacked
  299
+   strings will have a full word of zero.  For the purpose of
  300
+   determining string length, this zero counts as one character.
  301
+
  302
+   x: Word Zero terminate the string.  This will zero terminate the
  303
+   string, forcing a zero word onto the end of the string.  If the
  304
+   string is packed and of an odd length, a zero octet will be placed at
  305
+   the end of the content, before the zero word.  For the purpose of
  306
+   determining string length, this zero will add quantity of zero octets
  307
+   added divided by the octet width of each character.
  308
+
  309
+   For example, an unpacked string will always have 1 added to the
  310
+   string length by the Z flag.  A packed string of odd length will have
  311
+   3 added to the string length, where an even length packed string will
  312
+   have 2 added to the length;
  313
+
  314
+   Flags w and x are incompatible.
  315
+
  316
+   a: Octet Pascal Length.  This will prepend the length of the string
  317
+   as an octet to the string content.  This is only compatible with a
  318
+   packed mode, either k or s.  (For swapped mode, this will end up
  319
+   being the lower (second) octet of the first word.)
  320
+
  321
+   p: Word Pascal Length.  This will prepend the length of the string as
  322
+   a full word to the string content.  This is compatible with either
  323
+   packed or unpacked modes.  Flags a and p are incompatible.
  324
+
340 325
 4.3.4.  Origin relocation
341 326
 
342 327
    .org address
@@ -344,6 +329,14 @@ Kuijpers & Beermann                                             [Page 6]
344 329
    The org preprocessor directive MUST take an address as the only
345 330
    argument.  Assemblers SHOULD verify the address is 16-bit sized.
346 331
    Assembler MUST add this address to the address of all labels,
  332
+
  333
+
  334
+
  335
+Kuijpers & Beermann                                             [Page 6]
  336
+
  337
+                           Assembly Syntactics                April 2012
  338
+
  339
+
347 340
    creating a relocation of the program.
348 341
 
349 342
 4.3.5.  Macros: macro block and macro insertion
@@ -353,12 +346,12 @@ Kuijpers & Beermann                                             [Page 6]
353 346
    .end
354 347
    name([param [,param...]])
355 348
 
356  
-   The macro directive defines a macro, a parametrized block of code
  349
+   The macro directive defines a macro, a parameterized block of code
357 350
    that can be inserted any time later.  Parameters, if any, are written
358  
-   in parentheses seperated by commas (,).
  351
+   in parentheses separated by commas (,).
359 352
 
360  
-   Using the name with parenthis MUST insert a formerly defined macro
361  
-   and expands the parameters of the macro with the comma-seperated
  353
+   Using the name with parentheses MUST insert a formerly defined macro
  354
+   and expands the parameters of the macro with the comma-separated
362 355
    parameters following the name of the macro to insert.
363 356
 
364 357
    Parameter substitutions can only be constant values and memory
@@ -376,23 +369,6 @@ Kuijpers & Beermann                                             [Page 6]
376 369
    directives inside the repeat-block MUST be handled when the
377 370
    repetition is complete, to make allow conditional repetitions.
378 371
 
379  
-
380  
-
381  
-
382  
-
383  
-
384  
-
385  
-
386  
-
387  
-
388  
-
389  
-
390  
-
391  
-Kuijpers & Beermann                                             [Page 7]
392  
-
393  
-                           Assembly Syntactics                April 2012
394  
-
395  
-
396 372
 4.3.7.  Conditionals
397 373
 
398 374
    .if expression
@@ -400,7 +376,7 @@ Kuijpers & Beermann                                             [Page 7]
400 376
    .elif expression
401 377
        codeElseTrue
402 378
    .elseif expression
403  
-           codeElseTrue
  379
+       codeElseTrue
404 380
    .else
405 381
        codeElse
406 382
    .end
@@ -410,6 +386,13 @@ Kuijpers & Beermann                                             [Page 7]
410 386
 
411 387
    For the definition of valid expressions, see Section 6.
412 388
 
  389
+
  390
+
  391
+Kuijpers & Beermann                                             [Page 7]
  392
+
  393
+                           Assembly Syntactics                April 2012
  394
+
  395
+
413 396
    The if clause is REQUIRED.  The else clause is OPTIONAL.  The elif/
414 397
    elseif clause is OPTIONAL and can occur multiple times.
415 398
 
@@ -441,14 +424,6 @@ Kuijpers & Beermann                                             [Page 7]
441 424
 
442 425
    Aligns code or data on doubleword or other boundary.
443 426
 
444  
-
445  
-
446  
-
447  
-Kuijpers & Beermann                                             [Page 8]
448  
-
449  
-                           Assembly Syntactics                April 2012
450  
-
451  
-
452 427
    The assembler MUST add zeroed words (0x0000) to the generated
453 428
    machinecode until the alignment is correct.  The number of words
454 429
    inserted can be calculated using the formula: 'boundary -
@@ -464,17 +439,27 @@ Kuijpers & Beermann                                             [Page 8]
464 439
    The assembler SHOULD report the message to the user.
465 440
 
466 441
 
  442
+
  443
+
  444
+
  445
+
  446
+
  447
+Kuijpers & Beermann                                             [Page 8]
  448
+
  449
+                           Assembly Syntactics                April 2012
  450
+
  451
+
467 452
 5.  Tokenizer Markup
468 453
 
469 454
 5.1.  Labels
470 455
 
471 456
    Labels MUST be single-worded identifiers containing only alphabetical
472 457
    characters (/[A-Za-z]/), numbers (/[0-9]/), underscores (_ U+005F),
473  
-   and periods (. U+002E).  The label MUST represent the address of 
474  
-   following instruction or data.  A label MUST NOT start with a number 
475  
-   or an underscore.  A label SHOULD end with a colon (: U+003A), but 
476  
-   starting with a colon MAY be supported. An assemblery MAY require
477  
-   labels to not end in a period.
  458
+   and periods(.  U+002E).  The label MUST represent the address of
  459
+   following instruction or data.  A label MUST NOT start with a number,
  460
+   an underscore or a period.  A label SHOULD end with a colon (:
  461
+   U+003A), but starting with a colon MAY be supported.  A label MUST
  462
+   NOT end with a period.
478 463
 
479 464
    Local labels MUST start with an underscore (_ U+002E) and end with a
480 465
    colon (: U+003A).  Local labels MUST be scoped between the
@@ -498,13 +483,6 @@ Kuijpers & Beermann                                             [Page 8]
498 483
    AND) ^ (bit-wise XOR), | (bit-wise OR), ~ (bit-wise NOT), << and >>
499 484
    (bit-wise shifts).
500 485
 
501  
-
502  
-
503  
-Kuijpers & Beermann                                             [Page 9]
504  
-
505  
-                           Assembly Syntactics                April 2012
506  
-
507  
-
508 486
    The following logical and bitwise operators MUST also be supported:
509 487
    == (equal), != (not equal, also <>), < (smaller than), > (greater
510 488
    than), <= (smaller or equal), >= (greater or equal), & (bit-wise AND)
@@ -517,6 +495,16 @@ Kuijpers & Beermann                                             [Page 9]
517 495
 
518 496
 7.  Conformance
519 497
 
  498
+
  499
+
  500
+
  501
+
  502
+
  503
+Kuijpers & Beermann                                             [Page 9]
  504
+
  505
+                           Assembly Syntactics                April 2012
  506
+
  507
+
520 508
 7.1.  Recognition of conformance
521 509
 
522 510
    An assembler, formatter and any other assembly related program that
@@ -553,14 +541,6 @@ Kuijpers & Beermann                                             [Page 9]
553 541
 
554 542
    Both kinds of file inclusion support two different forms, one
555 543
    including the file relative to the current file, and the other
556  
-
557  
-
558  
-
559  
-Kuijpers & Beermann                                            [Page 10]
560  
-
561  
-                           Assembly Syntactics                April 2012
562  
-
563  
-
564 544
    including it from an implementation defined location.  The former is
565 545
    ideal for splitting a program in multiple parts, while the latter is
566 546
    intended for implementation-provided resources such as source level
@@ -569,10 +549,18 @@ Kuijpers & Beermann                                            [Page 10]
569 549
    A preprocessor must accept every directive with a dot (.) or a number
570 550
    sign (#) prefix.  While Notch seems to prefer the latter, the former
571 551
    is much more common among todays assemblers.  Thus we decided to
572  
-   support both, especiall as the implementation-side overhead is very
  552
+   support both, especially as the implementation-side overhead is very
573 553
    low.
574 554
 
575 555
 
  556
+
  557
+
  558
+
  559
+Kuijpers & Beermann                                            [Page 10]
  560
+
  561
+                           Assembly Syntactics                April 2012
  562
+
  563
+
576 564
 9.  Security Considerations
577 565
 
578 566
    This memo has no applicable security considerations.
@@ -612,5 +600,17 @@ Authors' Addresses
612 600
 
613 601
 
614 602
 
  603
+
  604
+
  605
+
  606
+
  607
+
  608
+
  609
+
  610
+
  611
+
  612
+
  613
+
  614
+
615 615
 Kuijpers & Beermann                                            [Page 11]
616 616
 
255  ASM/Spec_0xSCA.xml
@@ -43,12 +43,12 @@
43 43
     <middle>
44 44
         <section title="Introduction">
45 45
           <t>This documents describes 0xSCA, Standards Committee Assembly. It
46  
-		  is a definition of a syntax to be used for writing assembly for the
47  
-		  DCPU-16 processor. Use of this syntax is voluntarily. With 0xSCA,
48  
-		  there is a defined syntax, and could decrease code incompatibility
49  
-		  among compilers.</t>
50  
-		  <t>Again, to be clear: 0xSCA is a syntax definition, not a standard.
51  
-		  0xSCA is to DCPU-16, what AT&amp;T or the NASM syntax is to IA-32.</t>
  46
+          is a definition of a syntax to be used for writing assembly for the
  47
+          DCPU-16 processor. Use of this syntax is voluntarily. With 0xSCA,
  48
+          there is a defined syntax, and could decrease code incompatibility
  49
+          among compilers.</t>
  50
+          <t>Again, to be clear: 0xSCA is a syntax definition, not a standard.
  51
+          0xSCA is to DCPU-16, what AT&amp;T or the NASM syntax is to IA-32.</t>
52 52
 
53 53
           <section title="Requirements Language">
54 54
             <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -59,7 +59,7 @@
59 59
         </section>
60 60
 
61 61
         <section title="Document Markup">
62  
-            <section title="Indentation and whitepace">
  62
+            <section title="Indentation and whitespace">
63 63
                 <t>Whitespace MUST be allowed between all
64 64
                 elements of a line, including but not limited to opcodes, values,
65 65
                 syntactic characters and preprocessor directives. Both a space
@@ -71,10 +71,10 @@
71 71
             </section>
72 72
         </section>
73 73
         
74  
-		<section title="Case sensitivity">
75  
-			<t>Assemblers MUST accept everything without regard to case EXCEPT
76  
-			string and character literals.</t>
77  
-		</section>
  74
+        <section title="Case sensitivity">
  75
+            <t>Assemblers MUST accept everything without regard to case EXCEPT
  76
+            string and character literals.</t>
  77
+        </section>
78 78
         
79 79
         <section title="Preprocessor Markup">
80 80
             <section title="Comments">
@@ -95,7 +95,7 @@
95 95
                 (. U+002E) or a number sign (# U+0023).</t>
96 96
                 <t>Preprocessor directives MUST start with a dot (. U+002E) or a 
97 97
                 number sign (# U+0023).</t>
98  
-				<t>Using a dot is RECOMMENDED to distinguish between C preprocessor
  98
+                <t>Using a dot is RECOMMENDED to distinguish between C preprocessor
99 99
                 syntax.</t>
100 100
             </section>
101 101
             <section title="Directives">
@@ -138,27 +138,66 @@
138 138
                     <t>undef MUST remove the given symbol from the namespace.
139 139
                     If the given symbol does not exist compilation SHOULD
140 140
                     continue and a warning MAY be emitted.</t>
141  
-					<t>Any occurances of the definition during its existence,
142  
-					MUST be replaced with the given value to the definition.</t>
  141
+                    <t>Any occurrences of the definition during its existence,
  142
+                    MUST be replaced with the given value to the definition.</t>
143 143
                 </section>
144 144
                 <section title="Data insertion">
145 145
                     <figure><artwork><![CDATA[
146 146
 .dw value [,value...]
147  
-.db value [,value...]
148  
-.ascii "string"]]></artwork></figure>
149  
-                    <t>dw (data word) MUST store the values literally and unpacked at
150  
-                    the location of the directive.</t>
151  
-                    <t>db (data byte) MUST pack (i.e. two bytes per word, first byte is LSB)
152  
-                    the values at the location of the directive. Words are filled with empty
153  
-                    bytes when the data does not evenly fit into 16-bit words.</t>
154  
-                    <t>ascii MUST store the string unpacked (i.e. character is LSB,
155  
-                    one word per character) at the location of the directive.</t>
156  
-                    <t>asciip (a pascal string) MUST store the string unpacked (i.e.
157  
-                    character is LSB, one word per character) at the location of the
158  
-                    directive, prepending the string with its length.</t>
159  
-                    <t>asciic (a C string) MUST store the string unpacked (i.e.
160  
-                    character is LSB, one word per character) at the location of the
161  
-                    directive, appending 0x0000 (\0).</t>
  147
+.dp value [,value...]
  148
+.fill count[,value]
  149
+.ascii [flags][<value>]"string"]]></artwork></figure>
  150
+                    <t>dw (data word) MUST store the values literally and unpacked at the
  151
+                    location of the directive.</t>
  152
+                    <t>dp (data pack) MUST pack pairs of values into a single word. The
  153
+                    first value is placed into the high octet, and the second is placed
  154
+                    into the low octet of the word. Should there be an odd number of
  155
+                    values after a dp declaration, the remaining octet MUST be filled
  156
+                    with the value 0.</t>
  157
+                    <t>fill (fill words) MUST insert a count of words, initialized to the
  158
+                    specified value.  If the value is not provided, the assembler MUST
  159
+                    assume 0.</t>
  160
+                    <t>ascii (ascii string) MUST pack the ascii values of the string as 
  161
+                    described by the flags that precede it. An explanation of the flags 
  162
+                    is provided in the section on ascii flags.<xref target="ascii_flags"/></t>
  163
+                    <t>The optional value parameter in between less than (&lt; U+003C) 
  164
+                    and greater than (&gt; U+003E) will be bitwise ORed with each character 
  165
+                    in the string.  The upper octet for unpacked strings will default to 
  166
+                    all 0's before the bitwise OR.</t>
  167
+                    <section title="Ascii Literal Flags" anchor="ascii_flags">
  168
+                        <t>k: The ascii values are "packed." Each character is mapped to an
  169
+                        octet of data. These are written in order. Certain other flags
  170
+                        may place octets that precede the first character's octet.</t>
  171
+                        <t>s: The ascii values are "packed" and "swapped." Like k, each
  172
+                        character uses one octet, however the order of the octets is
  173
+                        reversed within each word. Flags k and s are incompatible with
  174
+                        each other. Certain other flags may place octets before the first
  175
+                        character octet.</t>
  176
+                        <t>z: Zero terminate the string, inheriting character width. A null
  177
+                        character will be appended to the string. If the string is one of
  178
+                        the packed formats only one octet will be added, where unpacked
  179
+                        strings will have a full word of zero. For the purpose of
  180
+                        determining string length, this zero counts as one character.</t>
  181
+                        <t>x: Word Zero terminate the string. This will zero terminate the
  182
+                        string, forcing a zero word onto the end of the string. If the
  183
+                        string is packed and of an odd length, a zero octet will be 
  184
+                        placed at the end of the content, before the zero word. For the 
  185
+                        purpose of determining string length, this zero will add quantity
  186
+                        of zero octets added divided by the octet width of each character.</t>
  187
+                        <t>For example, an unpacked string will always have 1 added to the
  188
+                        string length by the Z flag. A packed string of odd length will
  189
+                        have 3 added to the string length, where an even length packed
  190
+                        string will have 2 added to the length;</t>
  191
+                        <t>Flags w and x are incompatible.</t>
  192
+                        <t>a: Octet Pascal Length. This will prepend the length of the string
  193
+                        as an octet to the string content. This is only compatible with 
  194
+                        a packed mode, either k or s. (For swapped mode, this will end
  195
+                        up being the lower (second) octet of the first word.)</t>
  196
+                        <t>p: Word Pascal Length. This will prepend the length of the string
  197
+                        as a full word to the string content. This is compatible with 
  198
+                        either packed or unpacked modes. Flags a and p are incompatible.</t>
  199
+                    </section>
  200
+                   
162 201
                 </section>
163 202
                 <section title="Origin relocation">
164 203
                     <figure><artwork><![CDATA[
@@ -175,12 +214,12 @@
175 214
     code
176 215
 .end
177 216
 name([param [,param...]])]]></artwork></figure>
178  
-                    <t>The macro directive defines a macro, a parametrized block
  217
+                    <t>The macro directive defines a macro, a parameterized block
179 218
                     of code that can be inserted any time later. Parameters,
180  
-                    if any, are written in parentheses seperated by commas (,).</t>
181  
-                    <t>Using the name with parenthis MUST insert a formerly defined
  219
+                    if any, are written in parentheses separated by commas (,).</t>
  220
+                    <t>Using the name with parentheses MUST insert a formerly defined
182 221
                     macro and expands the parameters of the macro with the
183  
-                    comma-seperated parameters following the name of the macro to
  222
+                    comma-separated parameters following the name of the macro to
184 223
                     insert.</t>
185 224
                     <t>Parameter substitutions can only be constant values and
186 225
                     memory references. Preprocessor directives inside the macro
@@ -204,7 +243,7 @@ name([param [,param...]])]]></artwork></figure>
204 243
 .elif expression
205 244
     codeElseTrue
206 245
 .elseif expression
207  
-	codeElseTrue
  246
+    codeElseTrue
208 247
 .else
209 248
     codeElse
210 249
 .end
@@ -214,17 +253,17 @@ isdef(definition)]]></artwork></figure>
214 253
                     <t>For the definition of valid expressions, see
215 254
                     <xref target="ia" />.</t>
216 255
                     <t>The if clause is REQUIRED. The else clause is OPTIONAL.
217  
-					The elif/elseif clause is OPTIONAL and can occur multiple times.</t>
  256
+                    The elif/elseif clause is OPTIONAL and can occur multiple times.</t>
218 257
                     <t>If expression consists of a single constant value,
219 258
                     then expression = 1 MUST be assumed. If expression evaluates
220  
-					to 1, the codeTrue-block MUST be assembled. When the
221  
-					evaluation fails, the next elif block must be evaluated. In
222  
-					any other case codeElse, if an else clause is specified,
223  
-					MUST be assembled.</t>
  259
+                    to 1, the codeTrue-block MUST be assembled. When the
  260
+                    evaluation fails, the next elif block must be evaluated. In
  261
+                    any other case codeElse, if an else clause is specified,
  262
+                    MUST be assembled.</t>
224 263
                     <t>isdef(symbol) can be used in place of expression.
225 264
                     isdef MUST evaluate to 1 if the given symbol is currently
226 265
                     defined, else it MUST evaluate to 0.</t>
227  
-					<t>ifdef is short for if isdef(). ifndef is short for if !isdef()</t>
  266
+                    <t>ifdef is short for if isdef(). ifndef is short for if !isdef()</t>
228 267
                     <t>Nesting of if directives MUST be supported.</t>
229 268
                 </section>
230 269
                 <section title="Error reporting">
@@ -246,9 +285,9 @@ isdef(definition)]]></artwork></figure>
246 285
                 <section title="Echo general output">
247 286
                     <figure><artwork><![CDATA[
248 287
 .echo message]]></artwork></figure>
249  
-					<t>The echo directive can be used to inform the user about
250  
-					(possible) issues, progress, etc.</t>
251  
-                	<t>The assembler SHOULD report the message to the user.</t>
  288
+                    <t>The echo directive can be used to inform the user about
  289
+                    (possible) issues, progress, etc.</t>
  290
+                    <t>The assembler SHOULD report the message to the user.</t>
252 291
                 </section>
253 292
             </section>
254 293
         </section>
@@ -256,11 +295,11 @@ isdef(definition)]]></artwork></figure>
256 295
         <section title="Tokenizer Markup">
257 296
             <section title="Labels">
258 297
                 <t>Labels MUST be single-worded identifiers containing only
259  
-                alphabetical characters (/[A-Za-z]/), numbers (/[0-9]/) and
260  
-                underscores (_ U+005F). The label MUST represent the address of
261  
-                following instruction or data. A label MUST NOT start with a
262  
-                number or an underscore. A label SHOULD end with a colon (: U+003A), but
263  
-                starting with a colon MAY be supported.</t>
  298
+                alphabetical characters (/[A-Za-z]/), numbers (/[0-9]/),
  299
+                underscores (_ U+005F), and periods(. U+002E). The label MUST represent
  300
+                the address of following instruction or data. A label MUST NOT start with a
  301
+                number, an underscore or a period. A label SHOULD end with a colon (: U+003A), but
  302
+                starting with a colon MAY be supported. A label MUST NOT end with a period.</t>
264 303
                 <t>Local labels MUST start with an underscore (_ U+002E) and end
265 304
                 with a colon (: U+003A). Local labels MUST be scoped between the
266 305
                 surrounding global labels. Local labels in different scopes
@@ -273,26 +312,26 @@ isdef(definition)]]></artwork></figure>
273 312
             </section>
274 313
         </section>
275 314
 
276  
-		<section title="Inline arithmetic" anchor="ia">
277  
-			<t>Source code can include inline arithmetics anywhere a
278  
-			constant value is permitted. Inline arithmetic may only
279  
-			consist of + (addition), - (subtraction), * (multiplication), /
280  
-			(integer division), % (modulus) and ! (negation), parentheses may be used
281  
-			to group expressions.</t>
282  
-			<t>The following bitwise operators MUST also be supported: &amp;
283  
-			(bit-wise AND) ^ (bit-wise XOR), | (bit-wise OR), ~ (bit-wise NOT), &lt;&lt;
284  
-			and &gt;&gt; (bit-wise shifts).
285  
-			</t>
286  
-			<t>The following logical and bitwise operators MUST also be
287  
-			supported: == (equal), != (not equal, also &lt;&gt;),
288  
-			&lt; (smaller than), &gt; (greater than), &lt;= (smaller or
289  
-			equal), &gt;= (greater or equal), &amp; (bit-wise AND) ^
290  
-			(bit-wise XOR), | (bit-wise OR), &amp;&amp; (logical AND), ||
291  
-			(logical OR), ^^ (logical XOR) which MUST be evaluated with
292  
-			respect to this order.</t>
293  
-			<t>Inline arithmetic MUST be evaluated as soon as possible, 
294  
-			the result MUST be used as a literal value in place of the expression.</t>
295  
-		</section>
  315
+        <section title="Inline arithmetic" anchor="ia">
  316
+            <t>Source code can include inline arithmetics anywhere a
  317
+            constant value is permitted. Inline arithmetic may only
  318
+            consist of + (addition), - (subtraction), * (multiplication), /
  319
+            (integer division), % (modulus) and ! (negation), parentheses may be used
  320
+            to group expressions.</t>
  321
+            <t>The following bitwise operators MUST also be supported: &amp;
  322
+            (bit-wise AND) ^ (bit-wise XOR), | (bit-wise OR), ~ (bit-wise NOT), &lt;&lt;
  323
+            and &gt;&gt; (bit-wise shifts).
  324
+            </t>
  325
+            <t>The following logical and bitwise operators MUST also be
  326
+            supported: == (equal), != (not equal, also &lt;&gt;),
  327
+            &lt; (smaller than), &gt; (greater than), &lt;= (smaller or
  328
+            equal), &gt;= (greater or equal), &amp; (bit-wise AND) ^
  329
+            (bit-wise XOR), | (bit-wise OR), &amp;&amp; (logical AND), ||
  330
+            (logical OR), ^^ (logical XOR) which MUST be evaluated with
  331
+            respect to this order.</t>
  332
+            <t>Inline arithmetic MUST be evaluated as soon as possible, 
  333
+            the result MUST be used as a literal value in place of the expression.</t>
  334
+        </section>
296 335
 
297 336
         <section title="Conformance">
298 337
             <section title="Recognition of conformance">
@@ -304,47 +343,47 @@ isdef(definition)]]></artwork></figure>
304 343
             </section>
305 344
         </section>
306 345
 
307  
-	<section title="Design Rationale">
308  
-		<section title="Labels">
309  
-			<t>Although Notch used the syntax :label in his first
310  
-			examples, it is not common in any popular assembler.
311  
-			Thus we decided for label: as the recommended form,
312  
-			still silently allowing the deprecated form.</t>
313  
-			<t>To simplify writing reusable code we also introduced
314  
-			local labels, which are only visible from within the
315  
-			global label they are defined within. Implementing this
316  
-			is easy to do and introduces little overhead, as nesting
317  
-			is neither specified nor recommended.</t>
318  
-		</section>
  346
+    <section title="Design Rationale">
  347
+        <section title="Labels">
  348
+            <t>Although Notch used the syntax :label in his first
  349
+            examples, it is not common in any popular assembler.
  350
+            Thus we decided for label: as the recommended form,
  351
+            still silently allowing the deprecated form.</t>
  352
+            <t>To simplify writing reusable code we also introduced
  353
+            local labels, which are only visible from within the
  354
+            global label they are defined within. Implementing this
  355
+            is easy to do and introduces little overhead, as nesting
  356
+            is neither specified nor recommended.</t>
  357
+        </section>
319 358
 
320  
-		<section title="Preprocessor">
321  
-			<t>0xSCA allows many operators and even parentheses in
322  
-			expressions for if-clauses, which complicates the
323  
-			implementation of these. We do recognize that, but
324  
-			the actual implementation difficulty is not too high,
325  
-			as there are many examples how to achieve this and
326  
-			we think that the additional power and reduced
327  
-			code complexity, resulting in better maintainable
328  
-			code, is worth the effort.</t>
329  
-			<t>The ability to define custom constants inline is
330  
-			easy to implement and yields more easily maintainable
331  
-			code, while introducing a minimum of additional syntax.</t>
332  
-			<t>Both kinds of file inclusion support two different
333  
-			forms, one including the file relative to the current file,
334  
-			and the other including it from an implementation defined
335  
-			location. The former is ideal for splitting a program
336  
-			in multiple parts, while the latter is intended for
337  
-			implementation-provided resources such as source level
338  
-			libraries.</t>
339  
-			<t>A preprocessor must accept every directive with
340  
-			a dot (.) or a number sign (#) prefix. While Notch seems
341  
-			to prefer the latter, the former is much more common
342  
-			among todays assemblers. Thus we decided to support
343  
-			both, especiall as the implementation-side overhead is
344  
-			very low.</t>
345  
-		</section>
346  
-	</section>
347  
-		
  359
+        <section title="Preprocessor">
  360
+            <t>0xSCA allows many operators and even parentheses in
  361
+            expressions for if-clauses, which complicates the
  362
+            implementation of these. We do recognize that, but
  363
+            the actual implementation difficulty is not too high,
  364
+            as there are many examples how to achieve this and
  365
+            we think that the additional power and reduced
  366
+            code complexity, resulting in better maintainable
  367
+            code, is worth the effort.</t>
  368
+            <t>The ability to define custom constants inline is
  369
+            easy to implement and yields more easily maintainable
  370
+            code, while introducing a minimum of additional syntax.</t>
  371
+            <t>Both kinds of file inclusion support two different
  372
+            forms, one including the file relative to the current file,
  373
+            and the other including it from an implementation defined
  374
+            location. The former is ideal for splitting a program
  375
+            in multiple parts, while the latter is intended for
  376
+            implementation-provided resources such as source level
  377
+            libraries.</t>
  378
+            <t>A preprocessor must accept every directive with
  379
+            a dot (.) or a number sign (#) prefix. While Notch seems
  380
+            to prefer the latter, the former is much more common
  381
+            among todays assemblers. Thus we decided to support
  382
+            both, especially as the implementation-side overhead is
  383
+            very low.</t>
  384
+        </section>
  385
+    </section>
  386
+        
348 387
         <section anchor="Security" title="Security Considerations">
349 388
             <t>This memo has no applicable security considerations.</t>
350 389
         </section>

0 notes on commit 47c8bae

Please sign in to comment.
Something went wrong with that request. Please try again.