Atypical Language Reference

Introduction

Atypical is an experimental assembly language for the PICmicro family of microcontrollers (14-bit core only: 16f84, 16f628, 16f877, etc). It uses a vaguely pseudo-C-like syntax instead of opcode mnemonics, so rather than writing, for example,

	MOVF a, 0
	ANDWF b, W
	XORLW 0xf0
	MOVWF c

you can write

	w = a
	w = w & b
	w ^= 0xf0
	c = w

or even

	w += a, & b, ^ 0xf0, => c

The most important thing to remember about Atypical is that it is an assembly language, not a high-level language. There is a one-to-one correspondence between Atypical statements and PICmicro instructions. For example, this Atypical assignment,

	w = 42

	movlw 42

	PORTA = 42

	movlw 42
	movwf PORTA

	w = 42, => PORTA

Familiarity with the PICmicro instruction set is a requirement for using Atypical.

Atypical is case-sensitive. Whitespace between symbols is generally unimportant, but line-breaks are significant. Comments start with // and continue to the end of the line.

    w=  PORTA  ;call     Process	// weird spacing doesn't matter.
  call   process // Process and process are different subroutines.

Instruction set in Atypical notation

The following tables list the PIC instructions and their Atypical equivalents. In the tables, k refers to a constant expression, f refers to a variable, and b is a bit number (a constant expression in the range 0 to 7 inclusive).

The columns labeled Focus and Implicit form contain information needed when comma-splicing multiple instructions on one line.

Literal and control instructions

	w -= 1

	addlw 255

Byte-oriented instructions

Bit-oriented instructions

Combining instructions

	w = var1	// focus is w
	w += 3		// focus is w
	w = w & 0x0f	// focus is w

	w = var1, + 3, & 0x0f

Note that instructions after the comma are written in implicit form, as listed in the instruction set tables.

	w = var1	// focus is w
	w = w & 0x0f	// focus is w
	PORTA |= w	// focus is PORTA

	w = var1
	w = w & 0x0f
	w |=> PORTA   // same as previous code, but now the focus is w

	w = var1, & 0x0f, |=> PORTA

	--var1		// focus is var1
	com var1	// focus is var1
	clr var1	// focus is var1

	--var1, com, clr // the preceding instructions comma-spliced

	PORTA<0> = 1	// focus is PORTA
	PORTA<7> = 0	// focus is PORTA

	PORTA<0> = 1, <7> = 0 // comma-spliced equivalent

	nop; nop; nop;

	w = var1, com; call DoSomething; w &= 0x7f, => var2

Variables

	varorg 0x20
	byte x          // x is file register 0x20
	byte a, b, c	// a is 0x21, b 0x22, c 0x23

	varorg 0x20
	byte PORTA  : 0x05  // PORTA is file register 0x05
	byte PORTB  : 0x06  // guess what
	byte x              // x is 0x20

	varorg 0x20
	byte a[3]  // a[0] is 0x20, a[1] is 0x21, a[2] is 0x22
	byte b     // b is 0x23

	w = INDF   // movf 0, w

	w = @fsr   // movf 0, w

The @ is supposed to be reminiscent of C's * dereferencing operator, and thus is supposed to indicate indirection through the FSR file register. @ can only be followed by "fsr" (case-insensitive).

Note: Forward references to variables and constants are not allowed.

Constants

	w = 15     // decimal
	w = 0x0f   // hex
	w = 0b1111 // binary
	w = 'A'    // ASCII

	const max_len = 100

	const recsize = 3, numrecs = 10
	const buffsize = 1 + (recsize * numrecs)

	w = w + recsize		// plain constant doesn't need parentheses
	w = w + (recsize * 2)	// constant expression needs parentheses

	varorg 0x20
	byte a
	w = (#a), => fsr	// put address of a into FSR (note parentheses around constant expression)
	w = a, => fsr		// put contents of a into FSR

Control flow

Labels

A label can be the target of a goto or call instruction. A label may be placed on any line that isn't a pseudo-op. The label can start in any column but it must be the first non-blank sequence on the line (in other words, any instructions on that line must come after the label).

infinite_loop:		// here's a label (infinite_loop)
	call do_something
	goto infinite_loop

    do_something: w = PORTA	// another label (do_something)
	// etc etc

Local labels are labels that begin with the . (dot) character. Local labels need be unique only within their scope; local labels may be redefined in other scopes. A non-local (global) label starts a new scope. Within its scope, a local label can be referred to as itself; outside its scope, a local label can be referred to by prepending the global label to the local label.

Blah:	goto Foo.0	// forward reference to local label in Foo

Foo:			// global label Foo starts new scope
	...
.0:	...		// local label (Foo.0)
	goto .0

Bar:	...		// start new scope (Bar)
.0:	...		// this .0 doesn't conflict with previous one
	goto .0
.zzz:	...		// local labels can be alphanumeric

Variables and constants may also be local to a scope. Note that global variables and constants do not start new scopes.

Foo:	byte .i		// local variable Foo.i
	byte Total	// global variable doesn't start new scope
	const .max=10	// local variable Foo.max
	byte .0		// ERROR: only local labels may be numeric

Basic control flow

The basic Atypical notation for the conditional instructions is of this general form:

	if condition then skip

However, the basic form is rarely used; far more common is the one-liner if, in which the condition is negated and the instruction that would have followed the if is instead incorporated into the same line. For example,

	if STATUS then skip
	goto nonzero

	if !STATUS then goto nonzero  // exactly the same machine code as above

	if STATUS==0 then goto nonzero

	if !STATUS then ++Count

Structured control flow

if condition then
    ...
endif

	btfsc/btfss/decfsz/incfsz (condition)
	goto  .endif_label
	...
.endif_label:

if condition then
    ...
else
    ...
endif

	btfsc/btfss/decfsz/incfsz (condition)
	goto  .else_label
	...
	goto  .endif_label
.else_label:
	...
.endif_label:

if condition1 then
    ...
elseif condition2 then
    ...
// there can be multiple elseif clauses
else
    ...
endif

	btfsc/btfss/decfsz/incfsz (condition1)
	goto  .elseif_label
	...
	goto  .endif_label
.elseif_label:
	btfsc/btfss/decfsz/incfsz (condition2)
	goto  .else_label
	...
	goto  .endif_label
.else_label:
	...
.endif_label:

// infinite loop
do
    ...
loop

.do_label:
	...
	goto do_label

// loop (test at top)
while condition do
    ...
loop

	goto .test
.do_label:
	...
.test:	btfsc/btfss/decfsz/incfsz (!condition)
	goto .do_label

// loop (test at bottom)
do
    ...
loop while condition

.do_label:
	...
.test:	btfsc/btfss/decfsz/incfsz (!condition)
	goto .do_label

You can also use break to exit a loop, and continue to jump directly to the next iteration of a loop.

Control-flow structures can, of course, be nested.

Atypical does not perform any optimizations; the various program-flow constructs always generate the code described above.

Note that, because decfsz and incfsz do not have "skip on non-zero" counterparts, you must choose your conditions carefully when decrementing or incrementing. Some constructs require that you test for equality to 0; others for inequality.

Jump tables and lookup tables

	goto  { .0, .1, ErrorHandler }
	// equivalent to goto .0; goto.1; goto ErrorHandler

	retlw { 10, 0xff, 'y' }
	// equivalent to retlw 10; retlw 0xff; retlw 'y'

	retlw { "Hello, world!", CR, LF, 0 }

.table:	retlw { "0123456789abcdef" }
	assert ($-1>>8) == (#.table>>8)

Pseudo-ops

	assert ($-1>>8) == (#.table2>>8)

	byte TRISA  : 0x85 // TRISA is in bank 1
	...
	STATUS = 1    // ready to access bank 1
	bank 1		   // let Atypical assembler know
			   // (otherwise we'll get a warning)
	TRISA = 0

	byte a, TRISA:0x85, buff[10]

	config _WDT_OFF & _INTRC_OSC_CLKOUT

	const height=50, width=20

	include "p16f877.aty"

	org 0x0100

	varorg 0x20