-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrisc16-debug.tex
115 lines (91 loc) · 5.73 KB
/
risc16-debug.tex
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
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
\documentclass[12pt,a4paper]{extarticle}
\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage[breaklinks=true,hidelinks]{hyperref}
\usepackage{fullpage}
% \def\labelitemi{\makebox[0pt][l]{$\square$}\raisebox{.15ex}{\hspace{0.1em}$\checkmark$}}
\def\labelitemii{$\rightarrow$}
\newcommand{\done}{\makebox[0pt][l]{$\square$}\raisebox{.15ex}{\hspace{0.1em}$\checkmark$}}%Note: the argument of \makebox is the width of the box as seen by the rest of the text. If set to 0pt, the content of the box (here a \square) will overlap with the text (here a \checkmark).
\newcommand{\notdone}{\makebox[1em][l]{$\square$}}
% \author{Quentin Delhaye}
% \date{October 25th, 2015}
\title{RISC16 Simulator Debugging}
\begin{document}
\maketitle
\section{Bugs}
\begin{itemize}
\item[\done] In the sequential version, writting instructions in the program memory is not enough.
It must first be saved in ROM, then imported back and only then can be executed.
\begin{itemize}
\item You just need to press the ``Assembly" button, you moron.
\end{itemize}
\item[\done] If there are multiple comment symbols after an instruction, the whole line is ignored all together.
\begin{itemize}
\item e.g. When importing \texttt{addi 1,1,0//double//comment}, the line does not appear in the program memory.
\item The problem probably comes from the comment parsing when importing the file in \texttt{MemProg::fileopen()}.
\end{itemize}
\item[\done] When coding a label in the program memory, the said label is not recognized as an address and generates errors.
The code needs to be exported and imported back again so that the label is set in the address column correctly.
\begin{itemize}
\item We can only code using the ASM column, the others are read-only.
However, the label needs to be in the Address column.
Hence, when we input something like \texttt{loop: beq 2,0,end}, the label \texttt{loop} stays in the same column as the opcode even though it should be considered as an address.
To work around that, we can export and import back the code; the labels are then moved away from the ASM column to the Address column.
\item When using the \texttt{Assembly} function (through the dedicated button), the labels should be parsed and moved to the Address column.
\item The problem comes from \texttt{MemProg::getIns}, the function parsing the ASM instruction upon assembly.
It supposes that the first token of the assembly line is always an instruction, otherwise it throws an ``error : bad instruction" at the face of the poor user.
We should probably first check if there is no label before the instruction.
\item Checking first for the label was a good idea.
Now the label is correctly put in the address column upon assembly.
However, when parsing the rest of the code, if a label is used on a line and has not been defined before that line, it throws a warning fucking everything up (``Unknown label or format error").
Assembling twice, first to parse the label and second for the rest, does not help.
\item The label parsing needs to be a full step on its own.
See the new \texttt{getLabel} loop in \texttt{MemProg}.
\end{itemize}
\item[\done] When using a label as the signed immediate operand of \texttt{addi}, the RiSC stores the relative address of the label, not its absolute.
Hence, if we want to jump with \texttt{jalr} to the address taken from a register filled with an \texttt{addi} operating with a label, it won't go to the expected place.
\begin{itemize}
\item All the jumps where considered relative.
However, jumps using \texttt{beq} are relative, but jumps using \texttt{jalr} are absolute.
It's just a matter of selecting the good jump type uppon arguments parsing.
\end{itemize}
\item[\done] The shifting in \texttt{lui} is wrong.
\begin{itemize}
\item The program uses a rotation instead of a shift.
\item For some reason, it rotates to the right instead of the left.
\item It also conflicted with \texttt{movi}
\end{itemize}
\item[\notdone] When there are too many arguments, the editor does not complain.
\item[\notdone] If there is the name of an instruction in a label, it crashes.
\item[\notdone] In the ASM simulator, if there are instructions after the \texttt{halt}, it keeps going instead of stopping.
\item[\done] Jump after overflow does not work.
\begin{itemize}
\item In the ASM simulator, when an overflow occurs (in an ADD operation, for example), if a label is used to point to the exception routine, it does not jump to the right place.
Instead of converting the label to a relative jump, it takes the address of the label and does \verb|PC + 1 + label_address|.
\item It was only a matter of label translation.
\end{itemize}
\item[\done] The ASM LUI is so fucked up.
\begin{itemize}
\item The shifting seems to be right, but the operand is completely different to what is expected.
\item \texttt{lui 1,0x200} should yield \texttt{r1=0x8000}.
\item The operand was indeed shifted on two different places.
\end{itemize}
\item[\notdone] MOVI does not correctly in extended instruction set (16 regs, 24bit IS).
\begin{itemize}
\item It's okay, LUI is not supposed to shift in 24bit mode.
However, the movi is still broken because it adds the same value twice in the register, multiplying it by 2.
\end{itemize}
\end{itemize}
\section{Performance improvements}
\begin{itemize}
\item[\notdone] When loading a ROM, the file is opened twice in a row.
\begin{itemize}
\item See \texttt{Memprog::fileopen(String path)}.
\end{itemize}
\end{itemize}
\end{document}