The assembly language of the YASEP

Introduction

This page describes the YASEP's JavaScript assembler (the code that translates the textual instructions into binary code) and the language conventions (syntax) used when writing software for the YASEP. For informations about specific instructions, see the opcode map.

This page covers the following points :

• The Instruction-Level Assembler
• How to write numbers
• The pseudo-instructions (like DB, DW or YASEP)
• The reserved keywords
• The instruction aliases
• The flags
• The default values

Architecture

The YASEP's assembler is split into two layers :

• The line-by-line, or instruction-level assembler is a stateless routine that assembles one instruction at a time. Its interface can be accessed through the corresponding menu or when you click on instructions that look like this: add d2, r3. It is not very sophisticated but very useful in countless places.
   
  
• The high-level assembler takes a whole file, plits it into single lines then feeds them to the above routine. It doesn't deal with the instructions directly but assembles the results, manages the symbol tables, evaluates/computes values, create the binaries, handles preprocessing...

An instruction is the basic unit of software, like an atom.
* For the YASEP, it is a 16-bit or 32-bit word that contains several fields that describe what to do with what.
* For the assembler, an instruction is a line containing all these informations in readable, symbolic form.

An instruction typically contains

• An opcode (short of operation code) that describes what operation to perform (add, substract, copy...),
• One or two register operand(s), these are data already stored inside the processor,
• One immediate value, a number in 4 or 16 bits included by the software,
• One destination register, that tells where to write the result of the current instruction,
• One eventual condition code that describes under which condition to abort de instruction.

The binary structure of the instruction is explained there.

The YASEP's instructions are quite simple but they are not always practical, so some opcodes introduce a few modifications, as indicated by opcode flags (internal properties of the opcodes, listed here). They are usually harmless and don't impact the architecture, but they make the instructions more handy, thus helping writing/reading programs easily.

The assembler uses these flags when transforming the source text into binary codes. They keep the source code readable and coherent, independently from any hardware tricks, exceptions or processor versions.

• Rule 0 : The opcode comes first.
• Rule 1 : The destination register comes after all the source operands (usually, at the end of the instruction).
• Rule 2 : Generally, the immediate value comes just after the opcode, before the other operands (except the few cases that must obey rule#1, like FORM_Ri and FORM_RI).
• Rule 3 : The conditional codes come at the end of the instruction, after the destination register.

Input processing

• The assembly routine takes a single line (a character string with no "end of line" like '\n', '\r'...)
• The line may end with a comment, started with ';'. Starting from this delimiter, all the followin characters are flushed.
• The leading and trailing spaces are removed, the comas and tabs are replaced by spaces, and duplicated spaces are merged. You are free to write add 234h d2 r3, add 234h d2, r3 or   add 234h,   d2,   r3
• The whole line is converted to upper case. So it does not matter if you write adD 234h D2 r3 or ADd 234h d2 R3 because it will become ADD 234H D2 R3 internally.
• The first word must be the opcode (rule #0). Its properties (flags and forms) are looked up in the internal JavaScript tables.
• Depending on the instruction, register names, keywords and/or constant numbers follow. The order and function of these parameters are defined by the "form".

and that's all there is to say about the subject of "input syntax".

• Hexadecimal ([0-9A-F]* with a trailing 'h'), for example dw 1234h (the 0x prefix or the $ prefix is never used)
• Decimal ([0-9]* without prefix or suffix) : dw 1234.
  This is the only format that accepts a leading minus sign : dw -1234
• Binary ([01]* with a trailing 'b') : dw 01101101b

Numbers are mostly used in contexts where the number of significant bits is bounded to the size of the container (usually, the immediate fields of instructions). When too many digits are given, the assembler keeps only the desired number of LSB, and discards the MSB. The following example shows how the number is truncated : db 1234h.

Note : the disassembler always uses hexadecimal as output format.

• DB : "Data Byte"
      outputs 8 bits : db 12h
• DH : "Data Half-word"
      outputs 16 bits : dh 1234h
• DW : "Data Word"
      output 32 bits : dw 12345678h

An unbounded number of litteral numbers is accepted, the limit depends on the JavaScript engine, not on the assembler's design. The interactive assembler will not display all the digits when more than 32 bits are given but they are available through software, by defining the emit_bin() function.

results: 

(error messages)

The ability to include ASCII strings is still missing at this time of writing.

Since 2008-08, the YASEP exists in 16-bit and 32-bit variants. The opcodes don't change but a few of them are pointless in 16-bit mode or 32-bit mode. The source code can specify that a certain width is used so a warning is issued when an invalid instruction (depending on the CPU) is assembled.

YASEP16 specifies that the targetted CPU has a 16-bit datapath. All 32-bit only instructions generate a warning.

YASEP32 specifies that the targetted CPU has a 32-bit datapath. All 16-bit only instructions generate a warning.

YASEP resets the target CPU to generic/undefined.

These pseudo-instructions don't generate any code and can be used in any order, as they simply control an internal flag. This flag is compared with each instruction's flag (see YASEP32_ONLY and YASEP16_ONLY).

• Register names (PC R1 R2 R3 R4 R5 A1 D1 A2 D2 A3 D3 A4 D4 A5 D5)
• Pseudo-instructions (DB DH DW YASEP16 YASEP32 YASEP)
• The condition codes (LSB0 LSB1 MSB0 MSB1 ZERO NZ)
• The instruction opcodes and the opcode aliases (NOP...)

The assembler eases instruction coding (letting the programer think about what to do, while caring about how to do it) with two types of aliases : form aliases (see ALIAS_RR) and instruction aliases (they are listed under the opcode map). This section is about instruction aliases.

Internally, they can be used like normal instructions, but they provide different forms and/or different semantics. However, they use real opcodes of other instructions.

The substitution is handled at the assembly level and the disassembler probably won't infer the originally assembled alias. So don't be surprised if instructions like NOT or NEG assemble correctly, but the disassembly returns a different opcode.

The various instructions forms are described in the forms page.

The flags are listed in their own page too.

However, when certain instruction fields are not used (by FORM_ALONE or FORM_R...), these fields could be set to values chosen by the assembler, for the purpose of power reduction.

Toggle minimization and toggle spacing could help reduce the power consumption and EMI emissions. The YASEP's assembler will be able to compute proper values rather easily. Padding Imm16s and NOPs could be enhanced this way, too. The possible reduction is quite low, but maybe could reach a few percents when fetching instructions from external SDRAM ? An equivalent gain can come from efficient instruction coding/packing and compiler/algorithm smartness.