Good day to all! I want to talk about my experience of participation in the summer school
"Computer Continuum 2014" , where I read my course. School events were held from 25 to 30 August. However, I got only for three days, in which the trainings were held: from 26 to 28 number.

And although I spent only three days at the events itself, the preparation took a significant part of the summer outside the holidays. The task before me was not easy.
- An unusual place for me. I haven’t spent a long time doing classes outside the office or my own MIPT.
- Short deadlines. I usually read my course for a semester or even a school year. What can be done in three days? I had to carefully limit and balance the scope of theory and practical tasks that I could throw out to the audience.
- I was completely unknown to the level of preparation of the public. Working with students of the same course, you can roughly imagine what they have already passed; besides, we usually interview them. Who will be at this school and what will be the level of their training - for me it was a mystery. And in fact, people came very different (more on that later).
About school
The event was held with the participation of the following organizations and companies: St. Petersburg State University, St. Petersburg State Polytechnic University, Northern Arctic Federal University. Mv Lomonosov (Arkhangelsk), Euler Foundation (St. Petersburg), Nizhny Novgorod Foundation for Education and Research, Intel, EMC, JetBrains. School participants were offered a choice of several activity tracks. My
track had number 4 - “Basics of software modeling”. In addition, Intel was represented on track 5 by its
XDK .
What was the track Intel
In the first and second days, I devoted part of my time to the theoretical foundations of software simulations, namely, why this technology is
an important component of the development of hardware and software, how the
processor models are arranged and how
peripheral devices differ from them.
')
But still, I decided to devote most of the course time to practical work on creating processor models and peripherals of the
OpenRISC 1000 architecture. When preparing the course, I decided for quite a long time what model we would write. Why was this architecture chosen by me?
I really didn’t want to once again do the 100,500th MIPS.- Open and free specification .
- A modular structure with a lot of optional parts - in the worst case, even if you implement only the core and a dozen instructions, you can still see the result. On the other hand, if you delve into the support of the details, then the work will definitely be more than three days.
- Simplicity of specifications with the simultaneous presence of important concepts such as interrupts and exceptions, external devices, timers, floating point operations, vector instructions, etc., which makes the architecture completely non-playable.
- Community support - if someone wants to continue working with OpenRISC 1000, then its services include ready-made tools : GCC and Clang compilers, Libc libraries, Linux kernel, and even Verilog designs.
Thus, OpenRISC 1000 left me a lot of room for maneuver - for any audience there is a task to do.
Wind River® Simics was used as a simulator and framework on which models were written and debugged.

For academic organizations who wish to conduct training or non-commercial research in the field of architecture or computer performance, there is an opportunity to get a free license for Simics for 50 seats and a set of packages with ready-made models of Intel® Core ™ processors and Intel® Atom ™ processors. According to this program in Russia, Simics has already been installed in two universities - at the Moscow Institute of Physics and Technology and now at the St. Petersburg Institute of Information Technology.
Why was Simics chosen?
- I have been working with this product for a long time and quite intensively, and it was natural to use it.
- Simics provides a rich and well-documented API for writing a variety of models and tools for researching computing systems and developing system software.
- In the delivery for academic users, there are a large number of examples of implementing devices with source codes, which made it possible to start the study with an already working code and gradually modify it for course tasks. So, the
or1k
kernel or1k
was made on the basis of sample-risc
, and the Tick-timer - on the basis of sample-timer-device
.
Who participated

14 people came to my classes. Some were students of SPbSU, SPbPU, TUSUR, as well as from Nizhny Novgorod (HSE NN) and Volgograd (VolSTU). Other participants turned out to be pretty senior lecturers who were also interested in what they were going to say. Finally, several colleagues from the St. Petersburg branch of Intel Labs, who were largely driven by professional interest, “sneaked in”. Everyone got to the third day, even colleagues from Intel, although they were always torn between very important working meetings and my occupation. In addition, each interested in programming their part of the platform being created.
results
By the end of the third day, we had a nice set: one common
or1k
kernel
or1k
, two implementations of the PIC interrupt controller and a half (one worked, and the second remained slightly underdeveloped) a timer, unit tests for the kernel instructions made and a common script for the platform, which looked like this:

What was the most pleasant and unbelievable - we managed to connect all the models into a common configuration and observe how periodic interrupts either reach or fail to reach the core, which, in turn, processes them according to the specification, passing on the vector specified in it exception handler code. Of course, we didn’t have much: implement a full set of instructions, ensure fair translation of addresses, write a TLB model, etc. But it earned the same!
What is given to students is easy
As the new school year began, it was interesting for me as a teacher to find out what difficulties in the perception of this type of practical work may arise from the participants, especially since I will conduct a similar, but more detailed course in this school year. First I will list what turned out to be relatively easy.
- Work in Linux. Although not all participants felt confident, no one complained about the impossibility of work. I was surprised that many used Midnight Commander, as I did - I had never seen anything like this before.
- The general idea of ​​interpretation. Many of the participants were familiar with the principle of pipelining commands to the CPU.
- Count bitmasks in your mind. Surprisingly, it was easier for some to write a constant as 0xc0000000 than to leave it as (1 << 31) | (1 << 30).
- Support for feature branch instructions - delay slot. For a number of RISC processors, the instruction immediately after branching is executed, even if a transition to a new address is to occur. Some of the participants boldly rushed to model this (optional in general) functionality and successfully coped with it.
- Writing DML code. DML is a specialized language used to quickly write Simics models. It combines a declarative description of device registers with an imperative description of the processes occurring during their reading and writing. At first, I planned to limit myself to pure C (since I almost always write models for Simics on it myself), but it turned out that DML really speeds up the process of writing models - two dozen lines of C were replaced by two with DML. To learn the basic ideas of his by the examples available was not difficult for anyone.
What caused difficulties
On the other hand, there were also surprises in the fact that some concepts were unknown or were given with some difficulty to the participants (and sometimes to the teacher).
- Work with git. Only one person without prompts was able to push his edits into the common repository himself. Nevertheless, this version control system helped a lot with getting the common code with the final result.
- Endianness. It would seem that everyone knows about the existence of two orders of bytes to represent multibyte sequences. And yet, it was very difficult for me, like the other participants, to reason quickly about whether we put the data in memory correctly, whether bytes were extracted for decoding, and so on.
- Simulation using the event queue. Discrete event simulation (DES) is a key technique for effectively modeling a large number of agents with asynchronous events. The timer model actively used events. For some reason it turned out to be more complicated than the synchronous model of the processor.
- The need to expand the sign. Many processor arithmetic instructions require the expansion of signed operands before they are used in an operation. Sometimes their initial width was not equal to 8, 16 or 32 bits, and it was necessary to invent a correct C code in order to properly account for the position of the mark and its extension.
What surprises met
Pure technical moments that are remembered.
- GDB in Linux Mint by default is not allowed to connect to processes that are not descendants of the debugger (the ptrace () call returns "Permission denied"). It is treated simply:
# echo 0 > /proc/sys/kernel/yama/ptrace_scope
Alternatively (enable debugging and after reboot): write 0 to the /etc/sysctl.d/10-ptrace.conf
file. - Having the -l option on the command is dangerous: it can be confused with -1, which will lead to a long debugging with a broken head.
Conclusion
As I have repeatedly noted for myself at the end of the next course, I can not say who as a result learned more - students or teacher. So here - plunging into a slightly different environment, on the other hand, going up to the tools I used daily, I learned about them new. And of course, I met a large number of interesting people and, I hope, I was able to interest them.
Thanks to all the school participants for their interest in modern technologies and their diligence in solving tasks, and for its organizers for very good coordination, clear timetable and technical support for the event. And readers of this post - thank you for your attention!