The YASEP datapath sizes

The YASEP architecture defines one instruction set with two overlapping and similar subfamilies, or flavors, with a 16-bit or 32-bit wide datapath (YASEP16 and YASEP32 respectively). They share about 95% of the behaviour and we try to keep as much features in common as possible.

YASEP16 and YASEP32 refer only to the data word sizes, it is independent from the instruction sizes. The instruction encoding is not changed: both versions decode short, long and extended forms (16 AND 32 bits wide instructions). The 32-bits wide instructions are even designed to be easy to decode with a 16-bit memory bus (see the microYASEP architecture).

We'll mainly speak about the differences here.

The first obvious difference is the word size :

YASEP16 requires more instructions than YASEP32 to process 32-bit values, so it's adapted for classic microcontroller uses, for example, when data are mainly bytes or half-words.
YASEP32 is more fluent when fast datastreams must be processed (the datapaths are larger and the memory bandwidth is increased), it can handle some graphics or more sophisticated protocols (like TCP/IP).

The second obvious difference is the silicon footprint : YASEP16 uses roughly half the logic gates of YASEP32. If a compact CPU core is needed (for a small FPGA), YASEP16 will leave more room for peripheral circuits. And YASEP16 runs maybe 15% faster thanks to shorter logic critical datapaths and shorter wires (because of the smaller size).

A third difference deals with memory. The program memory footprint is not much affected because the instructions are the same. However the memory access is substantially different:

YASEP16 can only access 64K bytes, it is more adapted to short programs. An address extension mechanism (with a page table) can be used to extend the total addressable memory, and different threads can access different memory areas (as well as share some) but a pointer is still limited to 64K.
YASEP32 can access a theoretic 4GB area per thread and is more suitable for serious applications. It is not planned to support or implement as much yet because it goes outside of the "embedded" domain.

The fourth difference is in the instruction set. Some instructions that deal specifically with words or half-words make no sense with the YASEP16, which uses the half-word (16-bit) for everything. The following instructions are specific to the YASEP32 and may trap (or hang the core, or even do nothing) when executed with the YASEP16 :

(none)

And these instructions are YASEP16-only:

(none)

To help prevent coding mistakes, the YASEP32 and YASEP16 pseudo-instructions have been defined. They indicate to the assembler which YASEP "flavor" is targeted, so it can issue warnings when an assembled instruction is invalid for the selected core.

Compatibility

The similarity of the flavors makes it easy to create "dual-mode code", share code between projects, perform platform detection etc. as long as no assumption is made about data sizes and flavor-specific instructions are not used.

The other internal mechanisms are unchanged. For example, the Special Registers have the same addresses (in the lower 64K range), so code can be easily ported. The trap&interrupt mechanism (which is also accessed through the Special Registers) has the same structure too.

Detection

In the YASEP32, the sign condition is read at bit #31 of the registers, and bit #15 for the YASEP16. We can check the datapath width by writing on the bit #15 of a temporary register and check if the sign condition is affected. This is easily performed by using the IMM20 form of the MOV instruction :

 MOV 8000h R1  ; R1=8000h in YASEP16 or 00008000h in YASEP32
 ADD R2 R3 R4 MSB1 R1 ; Do something if YASEP16

This value can also be stored in a Special Register, along with other configuration informations.