yasep/docs/assembly.html version 2009-09-02 Back to the main page | version française : |
This page describes the YASEP's JavaScript assembler and the language conventions (syntax) used when writing software for the YASEP. For informations about specific instructions, see the opcode map and the Instruction Set Manual pages.
This page covers the following points :
The YASEP's assembler is split into two layers :
Or maybe the high-level assembly will simply be implemented as a side-function of listed.
The YASEP's instructions are very simple but they are not always practical, so some opcodes introduce a few modifications (see 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 assembly language's goal is to hide the architectural details from the mind of the software developper. He should keep in mind a few rules :
and that's all there is to say about the subject of "input syntax".
The numbers are accepted in 3 formats :
Numbers are mostly used in contexts where the number of significant bits is bounded to the size of the container (usually, the immediate fields). When more bits are input, the assembler keeps only the desired number of LSB, and discards the MSB. The following example shows how the number is truncated : db 1234h.
The ability to output arbitrary numbers is critical for many uses so the assembler has the following three pseudo-instructions :
An unbounded number of litteral numbers is accepted (since 2007-04-04 and the limit depends on the JavaScript engine, not on the assembler's design). The floating assembler's window 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).
Example : db 12h 34h 56h 78h 9Ah BCh DEFh
emit_bin()'s output :
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 a pointless instruction (probably invalid for the given 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 below).
The instruction-level assembler recognizes the following symbols, and rejects anything else :
There are 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 disassembly 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.
Despite the very simple instruction format, the assembly language instructions appear with several different forms. This is due usually to reasons like :
The various instructions forms are described in the instructions.html page.
The flags have their own page too.
Normally, all uninitialized data, fields or values are cleared (zero).
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 can be enhanced this way, too. The possible reduction is quite low, but maybe could reach 5% when fetching instructions from external SDRAM ? Gotta try with and without, and even when EMI/toggles are maximized, just for testing it.