OSD600: Release 0.2

I took issue#319 in Webmaker for this release. I already completed it. Please find it here. 

This issue is about the UI, to align the line on the homepage with the text instead of centralize it. 

Now it looks as following:

OSD600: Release 0.2 – Webmaker – issue#319

In project release 0.2, I would like to take the issue #319 in webmaker. And I already left a message on github to ask and am still waiting for the response. This issue is about the UI, making the line to align with the text in the homepage. It is a small bug and easy to fix. However, it will a good start for me to go through the whole project and get the ideas about how it works. Whenever I get confirmed, I will send the pull request to make my first contribution on a real open source project. 

I have been hesitating in taking bugs for a while. Inspired by David's article "Minimum Viable Product" in Oct. 8, I decide to start with small bugs. Taking a small bug makes me feel more confident on open source development. And I am willing to take more bugs. 

Also, there is another small bug (#315) I am interested in. After I am done with this, I am most likely to work on that if it’s still available.

OSD600: Project for Release 0.2

Kate Hudson introduced Mobile Webmaker project in last Wednesday. It is a mobile application providing users the framework to create the mobile apps. In other words, it is a software being used to create software. She also showed some examples and gave the links of how to start. This is a cool project, which also have the clear information to start.

Moreover, I have some friend who are going to work on this project as well. Thus, I can discuss with them. And we may help each other although we work on different issues.

I need to look at the issues in detail and then decide which one to take. I will do so no later than this Wednesday, and will post which issue I would like to take.

SPO600: Lab3 - Loop in Assembly

In lab3, we were asked to write the assembly programs in both x86_64 and aarch64 to display number 0-29 in a loop.

This was my first assembly code. And it took me one night and 2 whole days to get them work. Now the loop is working to display the numbers. But I still have the problem for the newlines. My outputs do not have the newlines as I expect.  In other words, my output is on one line. I spent some time on this issue, but have not found the solution.

One frustrating thing in assembly is that different platform requires different syntax. The code I run in one platform without problems could not smoothly transform to the other platform. I still need to spend amount of time to recode it even though both programs have the same logic and same output.

Here is the code on X86_64 in GAS syntax.

 .text  
 .globl _start  
 start = 0  
 max = 30  
 _start:  
     mov  $start,%r15       /* starting value for the loop index*/  
 loop:  
     /*showing digit*/  
     mov   $'0',%r14  
     mov   $10,%r13  
     mov   $0,%rdx  
     mov   %r15,%rax  
     div   %r13  
     cmp   $0,%rax  
     je   singledigit  
     mov   %rax,%r13        /*store the second digit from right*/  
     add   %r14,%r13  
     mov   %r13,msg+5  
 singledigit:  
     mov   %rdx,%r12  
     add   %r14,%r12  
     mov   %r12,msg+6  
     /*showing loop in front of digit*/  
     mov   $len,%rdx  
     mov   $msg,%rsi  
     mov   $1,%rdi  
     mov   $1,%rax  
     syscall  
     inc   %r15              /* increment index*/  
     cmp   $max,%r15            /* see if we're done */  
     jne   loop              /* loop if we're not */  
     movq  $0,%rdi             /* exit status */  
     movq  $60,%rax            /* syscall sys_exit */  
     syscall  
 .data  
 msg:  .ascii   "loop:  '\n'"  
 .set len, . - msg  

And ARM assembly in aarch64:

 .text  
 .global _start  
 _start:  
     start = 0  
     max = 30  
     mov   x15,start        /*starting value for the loop index*/  
 loop:  
     mov   x28,0  
     mov   x27,10  
     adr   x12,msg         /*loading the message*/  
     udiv  x10,x15,x27       /*getting the quotient*/  
     msub  x9,x10,x27,x15     /*getting the reminder*/  
     cmp   x10,0          /*if quotient equals 0, then go to execute single digit*/  
     beq   singledigit  
     add   x14,x10,0x30      /*display quotient - second digit from right*/  
     str   x14,[x12,6]  
 singledigit:  
     add   x11,x9,0x30       /*display reminder - first digit from right*/  
     str   x11,[x12,7]  
     /*system call write*/  
     mov   x1,x12  
     mov   x2,len  
     mov   x0,1  
     mov   x8,64  
     svc   0  
     /*loop*/  
     add   x15,x15,1  
     cmp   x15,max  
     blt   loop  
     /*system exit*/  
     mov   x0,0  
     mov   x8,93  
     svc   0  
 .data  
 msg:  .ascii  "loop: ##\n\r"  
 len=  . - msg  

Through the practice in this lab, I got the basic idea how assembly works with memory and register, how to do the system call and how loop works.

In the end, I would like to ask if anyone has any good tutorials in assembly for beginners or suggestions, please comment it because I could not find one good for beginners. I highly appreciate.   

OSD600: Release 0.1

I have done the project 0.1 release and send David the pull request (https://github.com/humphd/filer/pull/5)  today. Project 0.1 release was to add the du command to filer project. Following project instruction, I did not have much difficulties to finish it.

First of all, I got the code and had my github ready by forking filer to my github account and coloning it to my local computer.

Then I installed the node.js in order to have npm package installer in my computer.

Next, following the instruction to install the grunt both locally in project (filer) folder and globally in my computer. At this step, I had the trouble to install grunt locally with the errors during the installation. After discuss with the classmate, I found out that I need use Linux command line instead of Windows command line to run the command “npm install”. Then I used git bash to run this command, and it turned out that installation was successful eventually.

Following, I run “grunt test” to test the code. I met the problems as well here. After asking David, it was resolved by updating to the latest code. The problem I met was just solved and updated quite recently, and I had not updated my code yet.

At this point, I had all the required environment ready. Then I started to write the code. I reviewed the code for cat command and ls command because du command has the similarity with these two commands. Both du and cat commands have two parameters – data and callback. And both du and ls commands need to return deep content of a directory tree, and have the file size, file path and file content. Having the reference to these two blocks of code, I built du command without much difficulties. There were 5 files that needed to be modified and/or added. They were:

•        MODIFY: /README.md
•        MODIFY: /test/index.js
•        MODIFY: /src/shell/shell.js
•        MODIFY: /dist/filer.js
•        ADD: /test/spec/shell/du.spec.js

At last, it passed the test with no error. 

SPO600: Static linking vs. Dynamic linking

Linker as a system program takes relocatable object files and command line arguments in order to generate an executable object file. The linker is responsible for locating individual parts of the object files in the executable image, ensuring that all the required code and data is available to the image and any addresses required are handled correctly.

Static and dynamic linking are two processes of collecting and combining multiple object files in order to create a single executable. 

Static linking is the process of copying all library modules used in the program into the final executable image. This is performed by the linker and it is done as the last step of the compilation process.

During dynamic linking the name of the shared library is placed in the final executable file while the actual linking takes place at run time when both executable file and library are placed in the memory.

Differences between Static linking and Dynamic linking:

	Static linking	Dynamic linking
Sharing external program	External called program cannot be shared. It requires duplicate copies of programs in memory.	Dynamic linking lets several programs use a single copy of an executable module.
File size	Statically linked files are significantly larger in size because external programs are built into the executable files.	Dynamic linking significantly reduces the size of executable programs because it uses only one copy of shared library
Easiness to update	In static linking if any of the external programs has changed then they have to be recompiled and re-linked again else the changes won't reflect in existing executable file.	In dynamic linking individual shared modules and bug fixes can be updated and recompiled.
Speed	Programs that use statically-linked libraries are usually faster than those that use shared libraries.	Programs that use shared libraries are usually slower than those that use statically-linked libraries.
Compati-bility	In statically-linked programs, all code is contained in a single executable module. Therefore, they never run into compatibility issues.	Dynamically linked programs are dependent on having a compatible library. If a library is changed, applications might have to be reworked to be made compatible with the new version of the library.

Advantages:

Static linking	Dynamic linking
•      Static linking is efficient at run time. •      It has less system calls. •      Static linking can make binaries easier to distribute to diverse user environment. •      It let the code run in very limited environments.	•      Dynamic linking is more flexible. •      It is more efficient in resource utilization, taking less memory space, cache space and disk space. •      It is easy to update and fix the bugs.

	Static linking	Dynamic linking
Source: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0242a/ch04.html http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking http://cs-fundamentals.com/c-programming/static-and-dynamic-linking-in-c.php

SPO600: Lab2

Brief description: 

Wrote a simple c program to display “Hello World!”, and  compiled it using command “gcc –g –O0 – fno-builtin”. Then using command “objdump” with options –f, -d, -s, --source to display the information of the output file.

And then do the following changes to see the changes and difference in the results.

5) Move the printf() call to a separate function named output(), and call that function from main().




Original output file: a.out

Output file after change: hello_all5.out

Before change:

When run the command: 

It only has main section for the source code:

After change

When run the command: 

It shows following:

6) Remove -O0 and add -O3 to the gcc options. Note and explain the difference in the compiled code.

-O3 is to optimize more for code size and execution time. It reduces the execution time, but increase the memory usage and compile time.

Output file before change: hello_all5.out

Output file after change: hello_all6.out

I use “time” command to check the execution time of above files, and get following result.

hello_all6.out is complied with the option –O3. It supposes to have less execution time. However, it takes much longer in real time than the previous one. Well, it does take less time in sys time.

I also compared the sizes of the output files with –O0 and –O3. The hello_all5.out, which is compiled with –O0, has smaller size than hell0_all6.out, being compiled with –O3. Apparently, compiling file with option –O3 does not reduce the file size. Instead, it increases the file size.

Following sreenshots are the result by running “objdump –source” command for both of the files.

Comparing the two results, I found:

1       --- The sequences of <main> section and <output> section in both results are different. For the output file hello_all5.out, being compiled with –O0 option, <main> section appears after <frame-dummy> section. And <output> section is after <main> section. By contrast, for the output file hello_all6.out, being compiled with –O3 option, <main> section appears right after the line “ Disassembly of section .text”. And <output> section still appears after <frame-dummy> section.

2   ---The contents of <main> section and <output> section are different for both results. For the output file hello_all6.out, the contents of both <main> section and <output> section are shorter than those in the result of hello_all5.out. It has 6 actions in <main> section of hello_all5.out and 9 actions in <output> section of hello_all5.out. By contrast, there are only 3 actions in <main> section of hello_all6.out and 4 actions in <output> section of hello_all6.out.

When I ran “objdump –s” for both files, I found more differences.

Contents of section .debug_line and contents of section .debug_str are shorter than the result of hello_all6.out. Moreover, the result generate by hello_all6.out has one more section – contents of section .debug_ranges.

Contents of section. debug_str generated by hello_all5.out

It is good to know that using different compiling options, the compiler compiles the program in different ways. Each option serves the different purposes. Accordingly, the assembler contents of each object files are different as well.

Using “objdump” command, it is good to see the assembler contents of the object file. It’s a good start to learn the assembly language. However, I still don’t fully understand what the assembler contents stand for. With learning more assembly language, I think it won’t be a problem for me anymore.