Continued from last week progress, I started to port the previous debugger code and simulator code into the simulator without the web worker. For the moment, I still unable to find any drawbacks of not using a web worker. Luckily, there is no major modification on the debugger code, which makes my life a little bit simpler. I had also worked with the other project code to call the simulator. This really took me some time as I would need to figure out why Witty application works in this way.
The Mouse Event Code
One of my biggest concern this week is to figure out how to hook a global mouse event in Witty web application. I could not find any Witty API that supports the global mouse event. I found that there was a discussion about the mouse event from the Redmine forum, as the Witty Application API states that there should be a global mouse and keyboard events API that can be used for. One thing I found to be interesting is that I can actually change the Witty API by just calling the Witty API function and overwrite it. I tried to overwrite some functions, which I hoped that it could be implemented to hook for the global mouse event, but it fails due to the different template class that has been initialized by the Witty API function itself.
At last, I used pure JavaScript to hook the global mouse event, which does not use any Witty API. I found that mouse event can really be a useful and convenient tool for the StepIn function to be called, but seems like normally mouse scroll buttons are already used for scrolling pages, addition of modifiers such as “Ctrl”, “Alt”, or “Shift” can be an interesting feature as well. For the mean time, I added the feature of calling StepIn function using the modifier “Alt” with mouse scroll. However, I found that this usage is not usable in Mozzilla Firefox as “Alt” Modifier in Firefox will trigger the toolbar tab.
The Communication of JSignal
I had discussed previously on the experimenting on Signalling between widget set and host witty application. This week, I had tried to prove that the code will actually work in the real project. However, it does not success initially, which took me some time on debugging it. The primary problem found was because CodeMirror actually generates their own HTML id. Therefore, I cannot self define an ID for the CodeMirror and try to communicate it using JSignal in the WidgetSet.
Thus, I did a reverse engineering, in which I used JSignal to pass the HTML ID that generated by CodeMirror, along with other objects, to the WidgetSet. By saving the ID in JavaScript variable, I used Wt.emit(id_obtained, objects_to_send) to send the current line information back to the CodeMirror in the host witty application. Thanks to my colleague Sumia, who helped me to add in the CodeMirror JavaScript code for the highlighting of current line, the debugger is now working fine and the interface is almost complete now.
The RISC-V Proxy Kernel
Well, in order to solve the undefined error 0, which maybe solved by providing appropriate the boot loader code. I had tried to look through how the SPIKE simulator and the proxy kernel works. The first thing I have to understand about is how the MakeFile works, and how the proxy kernel is compiled to be used. The MakeFile is written in quite complex form, unlike those learning of basic MakeFile that has been used for. Next, I look through the code of the proxy kernel, I found that the code is actually run in the way that the Assembly code calling the function from the C programs, which is a mixed match of C programming and Assembly. After learning about the MakeFile, I learned about how to link Linker Scripts and external library to link the files to be compiled manually. However, it seems like there are errors in between due to some C program macro definition which I think there must be another way to compile them manually.
Searching over the internet, and reading the code of Proxy Kernel, I found that the proxy kernel itself is an OS kernel that runs on the SPIKE simulator. The compilation of RISC-V GNU toolchain selected the compilation by default for the usage of proxy kernel + spike simulator. Since I am using the RISC-V Angel Simulator, I tried to search over the internet, but I could not find any similar proxy kernel that works with the RISC-V Angel Simulator. While looking at how Spike and proxy kernel running the C program, I noticed that the simulator is configured in a way that it will trigger exception interrupt in certain instruction (eg. sw zero, 0(t0) ) that will run another set of instructions. After running those instructions, it will come back to the following address and run the next instruction. My current aim would be extracts the specific boot loader code that will be able to run both C/C++ program properly without triggering any error. Currently, I am still getting error on the manual compilation of proxy kernel code, and maybe my way of doing is incorrect yet, I will try different methods to solve it. However, I am still doubting on how to deal with the system call instructions of the RISC-V ISA if this boot loader code works.
0 Comments