Browse Prior Art Database

TABLE DRIVEN EXECUTOR FOR A SMART CARD'S VIRTUAL MACHINE INTERPRETER

IP.com Disclosure Number: IPCOM000009057D
Original Publication Date: 1999-Jan-01
Included in the Prior Art Database: 2002-Aug-05
Document File: 3 page(s) / 140K

Publishing Venue

Motorola

Related People

Paul Arnott: AUTHOR [+5]

Abstract

In a smart card, applications are often written in an interpreted language for a virtual machine. Interpretation of applications has two distinct advat- tages over the execution of native code.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 3

0 M

MOTOROlA Technical Developments

TABLE DRIVEN EXECUTOR FOR A SMART CARD'S VIRTUAL MACHINE INTERPRETER

by Paul Arnott, Flostyslav Buglak, Dipendra Chowdhary, Eunice Ong and David Wright

OVERVIEW

  In a smart card, applications are often written in an interpreted language for a virtual machine. Interpretation of applications has two distinct advat- tages over the execution of native code.

  The fetching and decoding of an instruction depends upon the syntax ,of the instruction whereas the execution of an instruction depends upon the semantics of the instruction. The semantics of instruction have a lot of commonalties between them. For example, the instructions for arith- metic/logical operation and stack manipulation require micro-operations,, such as pushing/popping data items from stacks, calculating physical address- es, loading/storing data items from/to those address- es, setting/resetting of the condition flags (such as overflow, carry) etc.

  This scheme involves dividing the semantics of an instruction into a sequence of micro-operations. There are many micro-operations which are used for more than one instruction, and this reduces the code size.

  The relationship between instructions and the micro-operations are captured in a set of tables. The tables contain a list of micro-operations for each instruction.

THE INTERPRETER TABLES

  There are two tables: Instruction Table and Semantic Table. Examples of the Instruction Table and the Semantic Table are given in Figure 1.

There are many possible structures of the Instruction Table. Here otte of them is described.

It makes the applications independent of the platform, and

l It provides an extra layer of security by enforc- ing an exclusive environment for each application.

Interpretation of applications also has two disad- vantages.

l

l

It slows down the execution of an application,

and

l the Interpreter occupies a significant amount of code space.

  In the scheme described below, every instruction of the interpreted language is treated as a composi- tion of a sequence of micro-operations. The relation- ship between instructions and micro-operations are stored in tables. To execute an instruction, the list of micro-operations for the instruction is obtained from a table and the micro-operations are executed in sequence.

DESCRIPTION

  An interpreted language consists of a set of instructions. These instructions are similar to those found in an assembly language of a CPU.

The execution of an instruction involves:

   It has one entry for all possible values of opcode (e.g. If an opcode is 8 bits long, then the table has 256 entries). Each entry has two fields : St-index and num-mops. For valid opcodes, the St-index is an index to the Semantic Table otherwise it has an illegal value. The second field is the num- ber of micro-operations for the instruction.

l

l fetching an instruction,

decoding the instruction, and

l executing the instruction.

l

0 Momok, 1°C. ,999 286 January 1999

!

[This page c...