Welcome Lunch

I was being informed that my blog posts were too technical until a point that it bored the readers. I felt pity for my supervisor, because he needs to read through all my dull blog posts before publishing them. The reason that I prefer to blog technical stuff is that it is has less restriction in terms of grammar, and also fewer vocabulary is needed. All in all, engineers are trained to write technical stuff, right? Since I’m now having internship, it is good for me to learn how to blog about experiences too. Let’s kick start with our story today.

Currently, we have a new intern named Jacky, who has officially started his first day in AESTE. Jacky was briefed with the overall project in AESTE, and he is given some time to decide the project he wants to work on. After the briefing, it was just about lunch time. In our company, besides the farewell lunch that we had on last month, it is our culture also for supervisor to treat welcome lunch for new staff. Well, although I’m not a new staff, I was invited to join the lunch. Since it is my habit to prepare and bring along my lunch to work, so I rejected initially, but after second thought, I decided to join them, because I was just reminded that I didn’t prepare today’s lunch.

Our Muslim intern was not around today, so we decided to have non-halal food, Bak Kut Teh at Restoran Xin Wah, which is located just downstairs of our office. This restaurant was initially located at Queen’s Park, Jalan Shelley, but it has just shifted to Jalan Bayam, because the initial place was bought over by Sunway group for development of Sunway Velocity. It took us less than two minutes to reach the restaurant. It was full house and it was hard to find any empty seats. After settled down, we ordered bak kut teh, signature tau fu, lettuce and a pot of Chinese tea.

Our dishes arrived after a short discussion, and considering the crowd during lunch time, I was pretty amazed with their efficiency. Since I’m not a BKT lover, I could not comment much about it. However, by judging that whole bowl was finished and only the claypot is left, I can concluded that this dish was just fantastic. For me, my favorite dish goes to signature tau fu. It is fried and topped with mincemeat, served along with onion source. This dish alone deserves my second visit. After we finished our meal, we sat and chit chat for a while.

My supervisor, who is also the founder of AESTE, shared his life and working experience with us. He also briefed us the open source business model, which currently practiced in AESTE. We talked since the restaurant was fully packed, until the crowd was slowly gone. After the lunch, we went back to office and resumed our work.

uCLinux: Processes in kernel

Processes can be classified as either I/O-bound or processor-bound. As the name suggests, the former is a process where much of the time is spent in waiting for relatively slow I/O operations to complete. For instance, a process taking input for a word processor will be I/O-bound as it spends most of its time waiting for characters input. Such a process is runnable for only short duration, because it is eventually blocked to wait for more I/O.

On the other hand, processor-bound process spends most of the time utilizing processor to perform computation. One of the examples include programs that perform a lot of mathematical calculations, i.e. MATLAB. This type of process tends to run until they are preempted, owing to its behavior that they do not block on I/O requests very often.

It is not always clear whether a process should be considered CPU or I/O bound, because processes can exhibit both behaviors simultaneously. The X Window server, for example, is both processor and I/O-intense. Other processes can be I/O-bound but intense processing can also happened at some time instance. As the result, the scheduling policy in a system must attempt to satisfy two conflicting goals: low latency and high throughput. To satisfy these requirements, schedulers often employ complex algorithms to determine the most worthwhile process to run while not compromising fairness to other, lower priority, processes.

Linux is aimed to provide good interactive response, and so it is optimized for favoring I/O-bound processes over processor-bound processes. Linux scheduling policy give programs that deal with human interaction a higher priority, since lack of speed and responsiveness is more likely to be observed when a human is expecting an immediate response than when a human is waiting for some large job to finish. Furthermore, the system gives higher priority to I/O-bound programs because it usually time consuming, and it is beneficial to get them started as early as possible.

LLVM: Compiling FreeRTOS with LLVM (Part 2)

Continue from my previous post, LLVM: Compiling FreeRTOS with LLVM (Part 1).

Anybody who might have some basic skills in programming, creating Makefiles especially, must be laughing hysterically if they come across and read my previous post in this topic. When I google the phrase “Compiling freertos with llvm” or “freertos llvm”, my post comes out first in the results.

I wonder how many read that post. Silly me, pity them.

I was laughing at myself and feel embarrassed when my supervisor told me that I can’t simply compile one file (main.c) and expect it to work. I mean what was I thinking?? There are more than half a dozen other files required to compile our FreeRTOS port, not to mention around five different directory needs to be included during the build process.

Well then, that was before my relationship with Makefiles started.

Now, I have a new quick task, which is learning how to make Makefiles! FYI, that is how interns work at AESTE – when you don’t know something, you take the initiative to learn it. Because if you don’t know, you’re probably not going to finish your project.

“I don’t know” is not a kind of sentence that we like to use, its just not our culture here at AESTE. I will keep on updating with this task. Lets jump into this LLVM Makefile Guide and learn something new.

“Try not, do or do not”, says Master Yoda.

uCLinux: Multitasking in Linux kernel

Multitasking operating system is a software that offers interleave execution of more than one process. It is capable of executing several processes concurrently and therefore giving an illusion of parallelism in the view of user abstraction. Multitasking operating systems come in two flavors: cooperative multitasking and preemptive multitasking.

In cooperative multitasking, a process does not stop running until it is voluntary to do so. As the result, process in a cooperative multitasking system can dominates processor time. Conversely, in preemptive multitasking, a running process is suspended involuntarily so that next process can be run.

Being one of the multitasking operating system, Linux kernel implements preemptive multitasking, where the time that a process runs before it is switched is usually predetermined. The predetermined time, called as timeslice of the process, gives each runnable process a slice of the processor’s time and by managing the timeslice, it enables scheduler to make global scheduling decisions for the system. It also prevents any one process from monopolizing the processor.

There are two main challenges on the implementation of multitasking in Linux kernel:

  • The kernel is responsible for the technical details of task switching, where each individual process must be given the illusion that the CPU is always available. This is accomplished by storing process state before task is switched, and the exact saved state is restored when the process is reactivated.
  • The kernel must also decide how processor time is shared between the existing processes, i.e. important processes are given a slice of time, less important processes a smaller slice. The linux scheduler is responsible for deciding the duration of each process.

LLVM: Compiling FreeRTOS with LLVM

It is about two more weeks before my internship at Aeste ends.

Yesterday, I finished my task of cleaning up LLVM floating points instructions and cache instructions. What I did was just hunt all these unwanted instructions inside AEMB target directory files and remove it without damaging the files or disrupt any dependencies. That was it, but I am not sure its going to be working or not.

Now, come the second part, testing the code by compiling FreeRTOS with it. You may download AEMB FreeRTOS from our git repository. The latest version of AEMB FreeRTOS, is quite different from the one originally created by Sam Ibrahiem, previous intern at Aeste, hence the wiki page might need to be updated.

By the way, lets continue with the task at hand. Now I have FreeRTOS source code and not-so-sure LLVM code. First I went to FreeRTOS code and see whats inside. It seems to have two directory called ‘demo’ and ‘FreeRTOS’. For this purpose, I’ll focus only inside demo directory. Inside it, you’ll see five files; aemb.ld, FreeRTOSConfig.h, LICENSE.txt, main.c and Makefile. That Makefile will use mb-gcc to compile the code. Then I try it:-

$ make

As a result:-

mb-gcc -Wall -mxl-barrel-shift -mno-xl-soft-mul -Os -I..
..
..
..
mb-objcopy -O srec freertos.o freertos.srec
mb-objdump -dSC freertos.o > freertos.S
srec_cat freertos.srec -fill 0xAE -within freertos.srec
-range-pad 4 -o freertos.vmem -vmem 32

Which eventually will give me freertos.vmem file, a file needed to simulate it with Icarus Verilog. (I will explain how can you simulate it later in next post). So, after simulating it with Icarus Verilog, FreeRTOS was running happily I may say.

FreeRTOS
V7.0.1
Task 1
..
..
..

Task 1
Task 2 8980
Task 2 A274
Task 2 BA84
Task 2 D26F
Task 2 EA49
Task 3 60000002
Task 3 E0000006
Task 3 E0000006
Task 3 E0000006
Task 3 E0000006
Task 1
..
..
..
Task 1
Task 2 20A5C
Task 2 2233A
Task 2 23B6E
Task 2 253C3
Task 2 26C64
Task 3 E0000006..
..
..
Task 1
Task 2 38CB0
Task 2 3A5D4
Task 2 3BE7E
Task 2 3D680
Task 2 3EF03
Task 3 E000000
Task 3 E0000006
Task 1
..
..
..
Task 1
Task 2 50E3D
Task 2 52788
Task 2 53FEC
Task 2 55856
Task 2 570C0
Task 3 E0000006

*** TIMEOUT    5000050 ***

And that was it, but that obviously not what I was planning to do. It was merely to see what should I expect when using LLVM to compile that FreeRTOS.

To create a new Makefile to compile FreeRTOS with LLVM will be quite a huge task to finish in one day, so I figure, I’ll just use a tedious way to compile it for now.

$clang -pipe -O3 -isysroot /home/users/shaiful/Downloads/mblaze/
-I/home/users/shaiful/Downloads/mblaze/lib/gcc/microblaze-xilinx-elf/
4.1.1/include -I/home/users/shaiful/Downloads/mblaze/microblaze-xilinx
-elf/include -I../FreeRTOS/Source/include/ -I../FreeRTOS/Source/
portable/GCC/AEMB2/ -I./ -ccc-host-triple "mblaze-unknown-unknown"
-ccc-gcc-name "mb-gcc" -S -emit-llvm -o main.ll main.c 

yes, it was a huge single command that will produce llvm code. And I convert .ll file into .bc file before asking llvm to spit out assembly .s file.

$llvm-as -o main.bc main.ll
$llc -march=aemb main.bc -o main.s

and the cruel terminal just give me this line

Segmentation Fault

Well. clearly now something somewhere is wrong with my LLVM code.