Project

General

Profile

Template Description Language » History » Version 7

Artemiy Utekhin, 03/13/2013 09:22 AM

1 5 Alexander Kamkin
h1. Template Description Language
2 4 Alexander Kamkin
3
_~By Artemiy Utekhin~_
4 1 Alexander Kamkin
5 6 Alexander Kamkin
{{toc}}
6
7 3 Artemiy Utekhin
*Ruby-MT (Ruby for MicroTESK)* is a Ruby-based domain specific language geared towards writing compact and reusable tests for microprocessors and other programmable devices. The language intends to look similar to the assembler of the target CPU (*TL, Target Language*) complemented by higher level features consisting of both standard Ruby and features specific to the Ruby-MT implementation (*ML, Meta Language*). Ruby-MT, in a sense, is similar to a macro processor - it generates code in the target language based on the provided meta language.
8 1 Alexander Kamkin
9 3 Artemiy Utekhin
Since Ruby-MT is built as a Ruby library providing an internal DSL no additional parsers are required. Currently, because of the extensive use of Java, Ruby-MT templates can only be executed by the JRuby interpreter. CRuby will probably be supported at a later stage.
10 1 Alexander Kamkin
11 3 Artemiy Utekhin
h2. The translation process
12 1 Alexander Kamkin
13 3 Artemiy Utekhin
Ruby-MT code describes a template of a test program which is then translated into TL code using the API of the MicroTESK CPU model parser and simulator (and, by extension, the constraint solver and other MicroTESK components). The process can be described as follows:
14 1 Alexander Kamkin
15 3 Artemiy Utekhin
# Receiving model metadata from the simulator;
16
# Template pre-processing;
17
# Constructing commands in the simulator;
18
# Executing commands in the simulator;
19
# Receiving the assembler code from the simulator (based on the CPU Sim-nML description);
20
# Writing the TL output to target files.
21 1 Alexander Kamkin
22 3 Artemiy Utekhin
Depending on the circumstances some of these steps may be done concurrently. 
23 1 Alexander Kamkin
24 3 Artemiy Utekhin
h2. Configuration
25 1 Alexander Kamkin
26 3 Artemiy Utekhin
_Pending..._
27 1 Alexander Kamkin
28 3 Artemiy Utekhin
h2. Execution
29 1 Alexander Kamkin
30 7 Artemiy Utekhin
Right now there is a simple execution script that requires the name of a package containing the CPU model (which is responsible for simulating the target processor and is generated by the [[Sim-nML Translator]]), a template file and an optional output file (if it''s not provided the library uses the standard output to print out the results). To run a template, execute the following command:
31 1 Alexander Kamkin
32 7 Artemiy Utekhin
<pre>generate <model package> <template file.rb> [<output file.asm>]</pre>
33
34
Example:
35
36
<pre>generate arm mytemplates\arm_template.rb myresults\executable.asm</pre>
37 1 Alexander Kamkin
38 3 Artemiy Utekhin
h2. Writing templates
39 1 Alexander Kamkin
40 3 Artemiy Utekhin
h3. Basic features
41 1 Alexander Kamkin
42 3 Artemiy Utekhin
The two core abstractions used by MicroTESK parser/simulator and Ruby-MT are an *instruction* and an *addressing mode*. An instruction is rather self-explanatory, it simply represents a target assembler instruction. Every argument of an instruction is a parametrized *addressing mode* that explains the meaning of the provided values to the simulator. The mode could point to the registers, for instance, or to a specific memory location. It can also denote an immediate value - e.g. a simple integer or a string. Thus, a basic template is effectively a sequence of instructions with parametrized addressing modes as their arguments.
43 1 Alexander Kamkin
44 3 Artemiy Utekhin
Each template is a class that inherits a basic Template class that provides most of the core Ruby-MT functionality. So, to write a template you need to subclass Template first:
45 1 Alexander Kamkin
46 3 Artemiy Utekhin
<pre>require_relative "_path-to-the-rubymt-library_/mtruby"
47 1 Alexander Kamkin
48 3 Artemiy Utekhin
class MyTemplate < Template</pre>
49 1 Alexander Kamkin
50 3 Artemiy Utekhin
While processing a template Ruby-MT calls its %pre%, %run% and %post% methods, loosely meaning the pre-conditions, the main body and the post-conditions. The %pre% method is mostly useful for setup common to many templates, the %post% method will be more important once sequential testing is introduced. Most of the template code is supposed to be in the %run% method. Thus, a template needs to override one or more of these methods, most commonly %run%.
51 1 Alexander Kamkin
52 3 Artemiy Utekhin
To get %pre% and %post% over with, the most common usage of these is to make a special non-executable class and then subclass it with the actual templates:
53 1 Alexander Kamkin
54 3 Artemiy Utekhin
<pre>require_relative "_path-to-the-rubymt-library_/mtruby"
55 1 Alexander Kamkin
56 3 Artemiy Utekhin
class MyPrepost < Template
57
  def initialize
58
    super
59
    @is_executable = no
60
  end
61 1 Alexander Kamkin
62 3 Artemiy Utekhin
  def pre
63
    # Your ''startup'' code goes here
64
  end
65 1 Alexander Kamkin
66 3 Artemiy Utekhin
  def post
67
    # Your ''cleanup'' code goes here
68
  end
69
end</pre>
70 1 Alexander Kamkin
71 3 Artemiy Utekhin
<pre>require_relative "_path-to-the-rubymt-library_/mtruby"
72 1 Alexander Kamkin
73 3 Artemiy Utekhin
class MyTemplate < MyPrepost
74
  def initialize
75
    super
76
    @is_executable = yes
77
  end
78
  
79
  def run
80
    # Your template code goes here
81
  end
82
end</pre>
83 1 Alexander Kamkin
84 3 Artemiy Utekhin
These methods essentially contain the instructions. The general instruction format is slightly more intimidating than the native assembler and looks like this:
85 1 Alexander Kamkin
86 3 Artemiy Utekhin
<pre> instruction_name addr_mode1(:arg1_1 => value, :arg1_2 => value, ...), addr_mode2(:arg2_1 => value, ...), ...</pre>
87 1 Alexander Kamkin
88 3 Artemiy Utekhin
So, for instance, if the simulator has an ADD(MEM(i), MEM(i)|IMM(i)) instruction, it would look like:
89 1 Alexander Kamkin
90 3 Artemiy Utekhin
<pre> add mem(:i => 42), imm(:i => 128) </pre>
91 1 Alexander Kamkin
92 3 Artemiy Utekhin
Thankfully, there are shortcuts. If there''s only one argument expected in the addressing mode, you can simply write its value and never have to worry about the argument name. And, by convention, the immediate values are always denoted in the simulator as the IMM addressing mode, so the template parser automatically accepts numbers and strings as such. Thus, in this case, the instruction can be simplified to:
93 1 Alexander Kamkin
94 3 Artemiy Utekhin
<pre> add mem(42), 128 </pre>
95
96
If the name of the instruction conflicts with an already existing Ruby method, the instruction will be available with an %op_% prefix before its name.
97
98
h3. Test situations
99
100
_This section is to be taken with a grain of salt because the logic and the interface behind the situations is not yet finalized and mostly missing from the templates and shouldn''t be used yet_
101
102
_Big TODO: define what is a test situation_
103
104
To denote a test situation, add a Ruby block that describes situations to an instruction, this will loosely look like this (likely similar to the way the addressing modes are denoted):
105
106
<pre> sub mem(42), mem(21) do overflow(:op1 => 123, :op2 => 456) end</pre>
107
108
h3. Instruction blocks
109
110
Sometimes a certain test situation should influence more than just one instruction. In that case, you can pass the instructions in an atomic block that can optionally accept a Proc of situations as its argument (because Ruby doesn''t want to be nice and allow multiple blocks for a method, and passing a Hash of Proc can hardly be called comfortable).
111
112
<pre>p = lambda { overflow(:op1 => 123, :op2 => 456) }
113
114
atomic p {
115
  mov mem(25), mem(26)
116
  add mem(27), 28
117
  sub mem(29), 30
118
}</pre>
119
120
h3. Groups and random selections
121
122
There are certain ways to group together or randomize addressing modes and instructions.
123
124
To group several addressing modes together (this only works if they have similar arguments) create a mode group like this:
125
126
<pre> mode_group "my_group" [:mem, :imm] </pre>
127
128
You can also set weights to each of the modes in the group like this:
129
130
<pre> mode_group "my_group" {:mem => 1.5, :imm => 2.5} </pre>
131
132
The name of the group is converted into a method in the Template class. To select a random mode from a group, use %sample% on this generated method:
133
134
<pre> add mem(42), my_group.sample(21) </pre>
135
136
_TODO: sampling already parametrized modes_
137
138
The first method of grouping instructions works in a similar manner with the same restrictions on arguments:
139
140
<pre> group "i_group" [:add, :sub]</pre>
141
142
<pre> group "i_group" {:add => 0.3, :sub => 0.7]</pre>
143
144
<pre>i_group.sample mem(42), 21</pre>
145
146
You can also run all of the instructions in a group at once by using the %all% method:
147
148
<pre>i_group.all mem(42), 21</pre>
149
150
The second one allows you to create a normal block of instructions, setting their arguments separately. 
151
152
<pre> block_group "b_group" do
153
  mov mem(25), mem(26)
154
  add mem(27), 28
155
  sub mem(29), 30
156
end</pre>
157
158
In this case to set weights you should call a %prob% method before every instruction:
159
160
<pre> block_group "b_group" do
161
  prob 0.1
162
  mov mem(25), mem(26)
163
  prob 0.7
164
  add mem(27), 28
165
  prob 0.4
166
  sub mem(29), 30
167
end</pre>
168
169
The usage is almost identical, but without providing the arguments as they are already set:
170
171
<pre>b_group.sample
172
b_group.all</pre>
173
174
_Not sure how does it work inside atomics when the group is defined outside, needs more consideration_
175
176
_TODO: Permutations_
177
178
Any normal Ruby code is allowed inside the blocks as well as the %run%-type methods, letting you write more complex or inter-dependent templates.