-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathinstr.txt
68 lines (53 loc) · 2.51 KB
/
instr.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
/*
instr.txt
Copyright (C) 2015 Juha Aaltonen
This file is part of standalone gdb stub for Raspberry Pi 2B.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
Now that I got the instruction sets (ARM and THUMB) into spreadsheet,
I saw that the decoding by the bits of the instructions would have made a
terribly long and ugly code due to the "wandering" of the bits significant
for decoding.
I decided to go with a table approach instead. It's a bit slower to execute,
but a lot faster to implement. I think it's justified - at least in this phase.
The masks and match-data will be generated with spreadsheet.
Also, because there are "overloaded" instruction bit patterns, the order of
instructions in the search table is crucial. For example
If in immediate LSL the immediate value is zero, the instruction is
MOV (register) instead. The MOV needs to be checked first, because the
LSL would match it too.
Also bit patterns that make an instruction UNPREDICTABLE need to be included.
The idea:
instruction table is of form:
mask, data, extra, handler
where
mask has '1' for each bit used for comparison
data has '1' for each bit known to be '1' in the instruction
'extra' is a code for the instruction handling - it carries extra information
like unpredictability, state-related anomalities, etc.
'handler' is a pointer to the instruction type decoder function.
For handler, function pointers are used, even if, in my opinion, that makes
the code less readable and some debuggers get confused with them.
The number of handlers is, however, relatively small.
The table method can easily be modified to include Thumb instructions and to
deal with endianness changes (bits 'E' and 'T' in SPSR).
The pseudocode:
PROC arm_decode (instruction)
FOREACH table_element
temp = instruction & table_element.mask
IF (temp == table_element.data) THEN
CALL table_element.handler(instruction, table_element.extra)
BREAK
ENDFOR
IF (instruction is not found in the table) THEN
treat the instruction as UNDEFINED
ENDIF
ENDPROC