ETSI GS ECI 001-4 V1.1.1 (2017-07)

Embedded Common Interface (ECI) for exchangeable CA/DRM solutions; Part 4: The Virtual Machine

DGS/ECI-001-4

General Information

• Status: Published
• Publication Date: 26-Jul-2017
• Technical Committee: ECI - Embedded Common Interface for exchangeable CA/DRM solutions
• Current Stage: 12 - Completion
• Due Date: 09-Aug-2017
• Completion Date: 27-Jul-2017

Standards Content (Sample)

GROUP SPECIFICATION
Embedded Common Interface (ECI)
for exchangeable CA/DRM solutions;
Part 4: The Virtual Machine
Disclaimer
The present document has been produced and approved by the Embedded Common Interface (ECI) for exchangeable CA/DRM
solutions ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS ECI 001-4 V1.1.1 (2017-07)

Reference
DGS/ECI-001-4
Keywords
CA, DRM, VM
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GS ECI 001-4 V1.1.1 (2017-07)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
Introduction . 8
1 Scope . 9
2 References . 9
2.1 Normative references . 9
2.2 Informative references . 9
3 Definitions and abbreviations . 10
3.1 Definitions . 10
3.2 Abbreviations . 10
4 Conceptual principles . 11
4.1 The Virtual Machine as a CPU . 11
4.2 Characteristics of the Virtual Machine . 11
4.3 Isolation of individual ECI Clients . 11
4.4 Specifying the Virtual Machine . 11
4.5 ECI Client loader . 12
5 The Virtual Machine . 12
5.1 Execution environment . 12
5.2 Virtual Machine Architecture . 13
5.2.1 CPU architecture . 13
5.2.2 Registers . 14
5.2.3 Data space . 15
5.2.4 Code space . 15
5.2.5 Stack . 16
5.2.6 Endianness . 16
5.2.7 Exceptions. 16
5.2.8 Calling convention . 16
5.3 Virtual Machine instruction set . 16
5.3.1 Notation . 16
5.3.2 Arithmetic Instructions . 17
5.3.2.1 Register operands . 17
5.3.2.2 Register, immediate. 17
5.3.3 Short Forms . 18
5.3.4 Control Flow . 18
5.3.4.1 Common rules . 18
5.3.4.2 Unconditional Branches and Function Calls . 19
5.3.4.3 Conditional Branches . 19
5.3.4.4 Conditional Branches Based on Memory Comparisons with Constant . 19
5.3.4.5 Far Conditional Branches . 19
5.3.5 Load and Store instructions . 19
5.3.5.1 Register + offset . 19
5.3.5.2 Register + short offset . 20
5.3.5.3 Register Indexed . 20
5.3.5.4 Absolute indexed . 20
5.3.5.5 Dedicated Stack Access . 20
5.3.5.6 Memory Transfer . 20
5.3.6 Complex Instructions . 20
5.3.7 Miscellaneous . 21
5.3.7.1 System Calls . 21
5.3.7.2 Pseudo Instructions . 21
6 Interface between the ECI Client and the ECI Host . 21
ETSI
4 ETSI GS ECI 001-4 V1.1.1 (2017-07)
6.1 General principles. 21
6.2 Error value . 22
6.3 SYS_EXIT . 22
6.4 SYS_PUTMSG . 23
6.5 SYS_GETMSG . 23
6.6 SYS_HEAPSIZE . 23
6.7 SYS_STACKSIZE . 24
6.8 SYS_SYNCCALL. 24
6.9 SYS_CLIB . 24
7 bytecode lifecycle . 25
7.1 Introduction . 25
7.2 Loading a new ECI Client into the VM . 25
7.3 Initialization of the VM . 25
7.4 The Central Run Loop . 25
Annex A (normative): VM System resources . 27
Annex B (normative): Op codes for the VM . 28
Annex C (normative): Standard C library routines . 32
C.1 Introduction . 32
C.2 memmove . 32
C.3 strcpy . 32
C.4 strncpy . 33
C.5 strcat . 33
C.6 strncat . 33
C.7 memcmp . 33
C.8 strcmp . 33
C.9 strncmp . 34
C.10 memchr . 34
C.11 strchr . 34
C.12 strcspn. 34
C.13 strpbrk. 35
C.14 strrchr . 35
C.15 strspn . 35
C.16 strstr . 35
C.17 memset . 35
Annex D (normative): ECI Client File Format . 36
Annex E (informative): Authors & contributors . 37
Annex F (informative): Change History . 38
History . 39

ETSI
5 ETSI GS ECI 001-4 V1.1.1 (2017-07)
List of Figures
Figure 1: VM Host environment .12
Figure 2: Virtual processor architecture .13
Figure 3: Register file architecture .14
Figure 4: VM data memory layout .15

ETSI
6 ETSI GS ECI 001-4 V1.1.1 (2017-07)
List of Tables
Table 1: Error values .22
Table 2: SYS_EXIT reason values .22
Table D.1: ECI-compliant e_ident settings .36
Table D.2: ECI-compliant settings for ELF header members .36

ETSI
7 ETSI GS ECI 001-4 V1.1.1 (2017-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Embedded Common
Interface (ECI) for exchangeable CA/DRM solutions.
The present document is part 4 of a multi-part deliverable covering the Virtual Machine for the Embedded Common
Interface for exchangeable CA/DRM solutions specification, as identified below:
Part 1: "Architecture, Definitions and Overview";
Part 2: "Use cases and requirements";
Part 3: "CA/DRM Container, Loader, Interfaces, Revocation";
Part 4: "The Virtual Machine";
Part 5: "The Advanced Security System";
Part 6: "Trust Environment".
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
8 ETSI GS ECI 001-4 V1.1.1 (2017-07)
Introduction
The present document describes the concept of a Virtual Machine that executes in a Sandbox and offers a range of
instructions and System Call functions. The VM is designed to work in a variety of environments. It interoperates with
other applications that exist on the same machine using well-defined interfaces and provides a combination of support
for its own instruction set and a modular mechanism for the execution of elements written in the native code of the ECI
Host CPU and interacting with the hardware and other elements of the ECI Host environment. This provides the VM
with the means to execute readily renewable code that can provide a wide range of potential secure applications,
including the implementation of CA/DRM clients.

ETSI
9 ETSI GS ECI 001-4 V1.1.1 (2017-07)
1 Scope
The present document specifies a Virtual Machine which is intended for inclusion in the implementation of digital
television receivers and Set Top Boxes, and which is able to provide a secured environment for executing Conditional
Access kernel or Digital Rights Management client applications. The intention is to provide a uniform execution
environment in which such clients can operate in the knowledge that minimum ECI Host performance requirements are
met, that a standard API is provided to be used for retrieval of essential security data from content (i.e. encapsulated
with content) or via external networks (e.g. the Internet) and where resources can be accessed from the ECI Host
environment in a standardized way.
The presence and use of the VM allows to exchange CA/DRM clients at will and to support multiple simultaneous
instances of such clients in ECI Hosts so that users and operators are not tied in to a particular content protection
provider and that they can use security solutions of different types to suit differing content types. For Content
Protection system providers, it ensures the availability of a known execution platform that does not require specific
integration with any and every vendor of ECI Host devices.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS ECI 001-3: "Embedded Common Interface (ECI) for exchangeable CA/DRM solutions;
Part 3: CA/DRM Container, Loader, Interfaces, Revocation".
[2] "Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification, version 1.2",
TIS Committee, 1995.
NOTE: Available at https://refspecs.linuxfoundation.org/elf/elf.pdf.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ISO/IEC 9899: "Information technology -- Programming Languages -- C", ISO/IEC JTC1/SC22
WG14.
[i.2] ETSI GR ECI 004: "Embedded Common Interface (ECI) for exchangeable CA/DRM solutions;
Guidelines for the implementation of ECI".
ETSI
10 ETSI GS ECI 001-4 V1.1.1 (2017-07)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
bytecode: code of ECI Client (typically comprising a Conditional Access kernel or Digital Rights Management client)
that is executed by the VM
content protection system: system that uses cryptographic techniques to manage access to digital content
NOTE: Typically, a content protection system is either a conditional access system or a digital rights
management system.
Customer Premises Equipment (CPE): customer device that provides ECI specified decryption and encryption
functions
ECI (Embedded CI): architecture and the system specified in the ETSI ISG "Embedded CI", which allows the
development and implementation of software-based swappable ECI Clients in customer premises equipment (CPE)
and thus provides interoperability of CPE devices with respect to ECI
ECI Client (Embedded CI Client): implementation of a CA/DRM client which is compliant with the ECI
specifications
ECI Host: hardware and software system of a CPE, which covers ECI related functionalities and has interfaces to an
ECI Client
ecosystem: content and system environment in which the Virtual Machine described in the present document exists
NOTE: It takes into account the wider perspective of content preparation, delivery, authorization, etc. and is not
limited to a specific device or implementation.
interface specification: wrapper document that describes the extension, restrictions or any other modifications to the
present document that are required to meet the specific needs of a wider ecosystem in which the VM is required to
operate
native code: programmatic code written in the native executable instruction set of the ECI Host processor
sandbox: application execution environment limiting application access to only those resources defined by the sandbox
API
VM Instance: instantiation of VM established by an ECI Host that appears to an ECI Client as an execution
environment to run in
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
CA Conditional Access
CI Common Interface
CP Content Protection
CPU Central Processing Unit
DRM Digital Rights Management
ELF Executable and Linkable Format
EPG Electronic Programme Guide
ID Identification/Identity/Identifier
OS Operating System
PC Program Counter
POSIX Portable Operating System Interface
RISC Reduced Instruction Set Computer
VM Virtual Machine
ETSI
11 ETSI GS ECI 001-4 V1.1.1 (2017-07)
4 Conceptual principles
4.1 The Virtual Machine as a CPU
In essence, the Virtual Machine (VM) comprises a virtual CPU with its own code and data memory and a set of system
interfaces that provide access to hardware features of the ECI Host machine. The emulated CPU executes code in the
manner of a virtual 32-bit CPU, and the code it executes is called bytecode in the present document. Since the VM is a
simulation of a general purpose RISC processor it is able to execute a variety of applications.
4.2 Characteristics of the Virtual Machine
The VM shall provide a single-process, single-threaded environment.
The interface to the ECI Host hardware and other functions is provided in the form of a standard library of calls,
termed SYSCALLs. The SYSCALL instruction is one of the customized instructions of the VM and it is generally
executed after preparing the parameters required by the library routine (i.e. passed in "registers" of the VM).
All interaction between the ECI Client and the ECI Host is achieved through this operation. No interrupt architecture
is defined and, once started, the ECI Client runs to completion. Therefore, there is no opportunity to invoke calls into
the VM. Whilst restricting flexibility to a certain extent, this is outweighed by the enhanced control of the VM
execution (ensuring robustness of operation), the avoidance of race conditions, interference with time-critical
operations, etc.
As a consequence, the only means of passing data or messages to the ECI Client executing in the VM is on the basis of
requests issued by the ECI Client by invoking the appropriate SYSCALLs.
4.3 Isolation of individual ECI Clients
The ECI Client executes in a Virtual Machine, which exists as an application running in the firmware of the ECI Host.
It shall be possible to invoke multiple instances of the Virtual Machine, each potentially running a different ECI Client.
This places three fundamental requirements on the ECI Host operating environment:
1) The Operating System shall allocate sufficient resource to each VM Instance such that the performance
requirements laid out in [i.2] are met by all instances running simultaneously.
2) The libraries defined in clause 6 and annex C shall be fully re-entrant or implemented separately for each
instance of the VM.
3) The Operating System and VM shall ensure no information can be exchanged between running ECI Clients
and the outside world, including other ECI Clients by means other than those explicitly specified for such
purpose as part of the SYSCALL interface. This among others implies that all memory mapped into the data
space of a VM Instance is wiped from its previous content beforehand, and any attempts to use exceptional
conditions in the VM to trigger unspecified behaviour shall be prevented. This also implies that there is no
means for an ECI Client to change its bytecode. It specifically implies that the ECI Host and VM shall make
all required checks to prevent an ECI Client inducing unintended behaviour in the ECI Host or VM
implementations that may for instance lead directly or indirectly lead to the ECI Client being able to
manipulate (hack) the ECI Host.
4.4 Specifying the Virtual Machine
In subsequent clauses of the present document, the following are explicitly detailed regarding the VM itself:
1) The technical architecture of the VM.
2) The instruction set of the VM.
3) The ECI Host interface.
ETSI
12 ETSI GS ECI 001-4 V1.1.1 (2017-07)
4.5 ECI Client loader
In order to execute the ECI Client, the bytecode shall first be loaded into the code space of the VM memory and the
data space initialized. In clause 7, the present document addresses some specific aspects of the format of the ECI Client
container and initialization of the VM.
5 The Virtual Machine
5.1 Execution environment
Figure 1: VM Host environment
As depicted in Figure 1, the VM shall be executed in a sandboxed environment that ensures isolation from the ECI
Host's operating system, other Virtual Machine instances and any other applications executing in the ECI Host.
The VM comprises a native application of the ECI Host, with associated memory, and interface library and a loader for
installing the bytecode forming an ECI Client. The interface library provides the ECI Client with access to features of
the ECI Host operating system and hardware and also to other applications that may be executing in the ECI Host and
with which the ECI Client may need to interact. A typical example would be interaction with an Electronic Programme
Guide (EPG) application that would require authorization status for specific content for display to the user.
ETSI
13 ETSI GS ECI 001-4 V1.1.1 (2017-07)
5.2 Virtual Machine Architecture
5.2.1 CPU architecture
VM RAM
Register
Stack
file
Data
Code
ALU
Control bus
Program
Counter
Control
Core stack
logic
Figure 2: Virtual processor architecture
Figure 2 shows architecture of the virtual machine CPU. The VM is a register machine with the following
characteristics.
• A register file with general purpose registers of 32 bits. The registers are organized in register windows. Each
register window contains 32 registers. The last 16 registers of each window overlap with the first 16 registers
of the next window. Two of these registers in each window serve as stack pointer and frame pointer. The total
number of registers in the register file is REGISTER_FILE_SIZE, specified in annex A.
• A Harvard CPU architecture. Data is stored in a 32-bit flat memory space. Code is stored in a read-only, non-
addressable memory space.
• A separate control stack keeps track of return addresses. The contents of this stack are inaccessible to the
bytecode or external applications. The stack can store up to CONTROL_STACK_SIZE return addresses
(see annex A).
• Load and store instructions for signed and unsigned byte, half-word and word data types, which are 8, 16 and
32 bits respectively.
• An instruction set with many data processing instructions tailored for the application domain.
• Native byte ordering for efficient load and store, independent of endianness. Natural alignment
(alignment = size) is used for the basic types to make the bytecode maximally portable. In other words, the
memory address of a half-word is always even, and the address of a word is always a multiple of four.
• A System Call instruction (SYSCALL) which can be used to implement system services. This also allows the
VM to be extended with built-in functions, e.g. to perform frequently occurring data processing natively.
ETSI
Data bus
14 ETSI GS ECI 001-4 V1.1.1 (2017-07)
• Paged memory supporting a fragmented memory space. It allows mapping of native memory into the VM's
memory space.
5.2.2 Registers
In each register window, 32 registers are visible, R0 through R31. Two registers are reserved for special treatment. R0
is the Frame Pointer and R16 is the Stack Pointer. The use of these registers is further detailed below.
At entry of a function, the ENTER instruction shifts the register window up by sixteen registers. This turns the old stack
pointer into the new frame pointer, and makes a new stack pointer and fifteen more registers available. The new stack
pointer is initialized by subtracting the frame size supplied by the ENTER instruction from the frame pointer.
The RETURN instruction reverses this process. It shifts the window down by sixteen registers, thus restoring the old
frame pointer and stack pointer.
Since the original R0 through R15 cannot be reached from the called routine, they are automatically callee-saved. Since
the return address is saved on a separate control stack, there is no data stack used for callee-saved registers and return
addresses.
The true number of registers is limited, so there is a maximum on the call depth of an ECI Client
(CONTROL_STACK_SIZE). Exceeding this depth will abort the VM program. The number of registers and the
corresponding depth of the control stack can be specified when creating the VM process.

Figure 3: Register file architecture
ETSI
15 ETSI GS ECI 001-4 V1.1.1 (2017-07)
5.2.3 Data space
The base data address of the VM defined as DATA_BASE_ADDRESS (see annex A) shall be 0x1000000 (16 Mbyte).
The smallest address above the addressable memory that is not addressable is DATA_BASE_ADDRESS +
ADDRESSABLE_DATA_SIZE (see annex A). The base address of the stack shall be defined by the VM
implementation, but shall be towards the high end of the address space. The VM may reserve a maximum of
VM_RESEVED_SIZE (see annex A) for private purposes in the address space of the ECI Client "below" the bottom of
the stack (at a higher address). At VM initialization the stack pointer shall point to the first free stack location. The ECI
Client can assume that the top of the (empty) heap at initialization is equal to the size of the initialized data + size of the
uninitialized data segments, both rounded up to multiple of 4.
The data memory layout is sketched in Figure 4.
Address:
DATA_BASE_ADDRESS
Initialized
= 0x1000000
data
Uninitialized
data
heap
stack
VM reserved
DATA_BASE_ADDRESS +
ADDRESSABLE_DATA_SIZE
Figure 4: VM data memory layout
At ECI Client initialization, the ECI Client loader shall load the initialized and uninitialized data segments starting at
address DATA_BASE_ADDRESS. All bytes of the uninitialized data segment shall be set to zero. The initialized data
segment is not write protected.
NOTE 1: The stack size is initially restricted. Since local data structures defined in c-functions are typically
allocated to the stack the stack segment should be set by the ECI Client to an appropriate size in case
large local variables are used in the c-code.
NOTE 2: The ECI Host may map message buffers in the VM reserved memory below the base stack address.
Future VM versions might reserve more addressable memory for ECI Clients; i.e. might have a larger
ADDRESSABLE_DATA_SIZE. For backward compatibility purposes ECI Clients shall not depend on the specific
value or value range of the stack pointer presently defined, but simply use the stack pointer as passed on initialization.
The ECI Client Loader shall not load any image files that do not adhere to the above memory layout convention for the
initialized and uninitialized data segments.
5.2.4 Code space
Code cannot be directly accessed by the program. The program may obtain 32-bit opaque references to static code
objects (e.g. routine entry point, jump target) called code references (see MOVF instruction). code references may only
be used with indirect control flow instructions (JMPR and CALLR). code references are not pointers to code memory
space, and no pointer arithmetic shall take place with them.
The start address of the code segment in the code address space shall be 0x00000000. The maximum size of the code
segment is defined as CODE_SIZE (see annex A).
ETSI
16 ETSI GS ECI 001-4 V1.1.1 (2017-07)
5.2.5 Stack
The stack is conventionally defined to be located in data memory, to contain words only, to grow toward lower
addresses, and to have its tip (word that was pushed last) always pointed to by the R16 register (stack pointer) of the
current register window.
R0, the frame pointer, is used as a pointer into the callee's stack so that parameters or other data pushed onto the stack
may be accessed by a called routine (see clause 5.2.8).
5.2.6 Endianness
Multi-byte data (half-words and words) are represented in system memory in little-endian format. The ECI Client
software shall use little-endian.
5.2.7 Exceptions
The VM CPU does not issue any exception during execution. If an instruction operates under conditions outside those
outlined in the present document (e.g. unaligned access to a half-word or word in memory, access to any memory
address which has no corresponding memory, a branch to an unknown code reference), the behaviour is undefined. The
VM may choose to terminate the kernel. The VM shall ensure that under no circumstances may an ECI Client
operating outside the present document gain access to unauthorized data or to influence any other application.
5.2.8 Calling convention
The calling conventions pass the first seven scalar parameters (pointers and integers) in R17 through R23. The callee
will see these as R1 through R7.
Scalar parameters beyond the seventh are passed on the stack by the caller in a right-to-left order. Because of the
register window mechanism, the callee will always find the eighth parameter (if present) pointed to by R0. R0 is
therefore the frame pointer. Structure parameters are always passed on the stack, or by reference. Pointers always refer
to the VM memory space.
NOTE: All SYSCALLs pass any structures and arrays by reference only. This approach should be used for other
calls, too.
The callee leaves the return value in R1, which will be seen as R17 by the caller. Types smaller than 32 bits are passed
(and returned) as 32 bit values.
Structure return is implemented by passing an implicit first parameter which is a pointer to the memory area where the
return type is expected to be stored (passed by reference). The callee writes its result to the location to which this
parameter points. This return pointer is treated like a normal argument (passed in R17 R1), which implies that the
regular arguments of a function, which returns a structure, shift to other calling convention registers
(R18.R23 R2.R7) or via the stack.
5.3 Virtual Machine instruction set
5.3.1 Notation
The following notation is used:
rx    Register x.
uimm5  5 bit unsigned immediate.
uimms9  9 bit unsigned immediate. Always a multiple of two.
uimms10 10 bit unsigned immediate. Always a multiple of four.
simm11  11 bit signed immediate.
simm16  16 bit signed immediate.
uimm16  16 bit unsigned immediate.
pcr16  16 bit signed PC-relative
pcr24  24 bit signed PC-relative
imm32  32 bit immediate.
low8(x) The least significant 8 bits of x.
low16(x) The least significant 16 bits of x.
ETSI
17 ETSI GS ECI 001-4 V1.1.1 (2017-07)

The functional descriptions use C-semantics on 32 bit integer types. The ability of the operation to support signed or
unsigned data types is indicated as comments. Memory access is given by MEM1(), MEM2() and MEM4(), accessing
1, 2 or 4 bytes of memory, respectively. The operand of these is an offset into the data segment. When relevant, MEM is
prefixed by U for unsigned operations or S for sign-extended operations.
5.3.2 Arithmetic Instructions
5.3.2.1 Register operands
ADD   r1,r2,rd    ; rd = r1 + r2;
SUB   r1,r2,rd    ; rd = r1 - r2;
OR   r1,r2,rd    ; rd = r1 | r2;
AND   r1,r2,rd    ; rd = r1 & r2;
XOR   r1,r2,rd    ; rd = r1 ^ r2;
SRA   r1,r2,rd    ; rd = r1 >> r2;   signed shift right
SRL   r1,r2,rd    ; rd = r1 >> r2;   logic shift right
SLL   r1,r2,rd    ; rd = r1 << r2;
MUL   r1,r2,rd    ; rd = r1 * r2;
SDIV  r1,r2,rd    ; rd = r1 / r2;   signed divide
SMOD  r1,r2,rd    ; rd = r1 % r2;   signed remainder
UDIV  r1,r2,rd    ; rd = r1 / r2;   unsigned divide
UMOD  r1,r2,rd    ; rd = r1 % r2;   unsigned remainder
EQ   r1,r2,rd    ; rd = r1 == r2;
NE   r1,r2,rd    ; rd = r1 != r2;
LT   r1,r2,rd    ; rd = r1 < r2;   signed less than
GE   r1,r2,rd    ; rd = r1 >= r2;   signed greater or equal
LTU   r1,r2,rd    ; rd = r1 < r2;   unsigned less than
GEU   r1,r2,rd    ; rd = r1 >= r2;   unsigned greater or equal
NOT   r1,rd     ; rd = ~r1;
NEG   r1,rd     ; rd = -r1;
ABS   r1,rd     ; rd = abs(r1);
MOV   r1,rd     ; rd = r1;
EXTB  r1,rd     ; rd = (int8_t) r1;  sign-extend from 8 bits
EXTH  r1,rd     ; rd = (int16_t) r1; sign-extend from 16 bits
ZEXTB  r1,rd     ; rd = (uint8_t) r1; zero-extend from 8 bits
ZEXTH  r1,rd     ; rd = (uint16_t) r1; zero-extend from 16 bits
MASKHI r1,rd     ; rd = ~(-1) >> r1;  logic shift right

5.3.2.2 Register, immediate
ADDI  r1,imm32,rd    ; rd = r1 + imm32;
RSUBI  r1,imm32,rd    ; rd = imm32 - r1;
ORI   r1,imm32,rd    ; rd = r1 | imm32;
NO
...