Updates from October, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • K 9:46 AM on October 25, 2010 Permalink
    Tags: , , , , ,   

    First Hands-on with Assembly Language Programming 

    I always wanted to learn assembly language programming. I had never tried do it myself and was disappointed to know that it was not there in our Logic Design course this semester (this because it was mentioned in the syllabus and I had taken pains to find good books on assembly from the library and get them issued, just to return them after learning that the syllabus for the course was too less compared to what was given on the department’s website).

    But today Murali Sir gave a lecture on Compilation of Expressions in Program Design course, which somehow, to my astonishment, reached assembly language programming. I was delighted. In the class, a simple input n, input n integers and print their sum program was done which was enough to demonstrate most of the features of the instruction set of the Simple Integer Machine we were following.

    As soon as the classes were over, I read the Description of the Target Machine (SIM) and downloaded the simulator. The tar file seemed to contain some source files and I had no idea what to do with them. Then, thankfully, I found a makefile among the files. The next steps seemed clear to me. Here are the steps I followed to run my first assembly code:

    Please note, I am using an Ubuntu 10.04 32-bit machine.

    • As a first step to compile the simulator, I installed build-essential, bison and flex packages using apt-get.
    • It gave some crude warnings but an executable named sim was generated.
    • Then after trying out some simple commands, I wrote the full fledged program we did in class earlier today. Here’s the code:
      IN R0
      MOV R1, 0
      L1: JZ R0, L2
      IN R3
      ADD R1, R3
      DCR R0
      JMP L1
      L2: OUT R1
    • I saved this file as first.asm
    • Then the only step remaining was running the code, for which I did a ./sim first.asm

    And I am a proud assembly programming newbie now.


  • K 5:18 PM on October 16, 2010 Permalink
    Tags: , , ,   

    Installing 64-bit version of Flash Player on Fedora 13 

    I have been using Fedora 64-bit KDE for many months now, but was too lazy to install flash player (I don’t usually need it as I am no YouTube junkie) until now. But today I had to visit some sites whose content seemed next to none without flash plugin on my browser. This forced me to install flash player finally.

    Such a person who always wants to remain at the cutting edge as I am, I tried installing the latest Flash Player “Square” Preview Release 64-bit available from Adobe Labs. Here are the steps:

    1. Download 64-bit Release Flash Player for GNU/Linux from http://labs.adobe.com/downloads/flashplayer10.html OR you can use the command: wget -c http://download.macromedia.com/pub/labs/flashplayer10/flashplayer_square_p2_64bit_linux_092710.tar.gz to download using the command line.
    2. Extract the archive using the command: tar xvf flashplayer_square_p2_64bit_linux_092710.tar.gz You will obtain the extracted file libflashplayer.so
    3. Now switch to root user by issuing the command: su and supplying your root password.
    4. Remove any old instance of flash plugin if installed by the command: yum remove flash-plugin
    5. Now you can move the .so file to the plugins directly of Firefox by the following command: mv libflashplayer.so /usr/lib64/mozilla/plugins/
    6. Restart the browser and check whether the plugin installed successfully by typing about:plugins in the Address bar and hitting enter.
    7. You are done!

    Be warned though, Adobe Labs says this on the preview release download page:

    Important: Please note that if you install the Flash Player “Square” preview, you will need to keep this version up to date by manually installing updates from the Flash Player “Square” download page on Adobe Labs. You will not receive automatic update notifications for future final releases of Flash Player, and you will need to manually uninstall Flash Player “Square” before installing a final shipping version of Flash Player.

    If you faced any problem, feel free to ask by posting a comment.

  • K 5:07 PM on October 5, 2010 Permalink
    Tags: , , ,   

    Using gdb to see through your program flow! 

    Using GDB was something I wanted to learn since I started programming in GNU/Linux environment. I read through man pages, info pages, and some vague guides on the net over the weeks but couldn’t figure out why wasn’t I able to use it properly.

    Then somehow I found this: RMS’s gdb Debugger Tutorial and learned that the I was making a very small mistake every time while compiling the code.

    This post is a summary of what I learned and a little guide to use gdb – The GNU Debugger to debug your C code.

    1. First of all, here is the setup I am using which won’t make a big difference if you are using a similar setup:
      • Programming Language: C
      • Compiler: gcc – GNU project C and C++ compiler
      • OS: Ubuntu (GNU/Linux) 10.04.1 32-bit
    2. Let’s say we have a program called source.c ready created using your favorite editor (vim, emacs, gedit, etc).
    3. Compile the program using gcc but using the following syntax:
      • gcc -g source.c -o run_source
      • -g is used for producing debugging information. GDB can work with this debugging information. This was the place I was making mistake all the time :).
      • -o is used to specify the name of binary to be generated by the compiler gcc which is used to run the program. In this case the binary’s name is run_source
    4. Now, as you may be know, you can run the program using ./run_source but here we want to debug it. So we use:
      • gdb run_source
    5. Now we are in GDB environment. You can use the following commands to debug your program:
      • break <function name> – to set a breakpoint at a function
      • watch <variable name> – to watch the value of a variable and compare between old and new value
      • list – to list out the code in proximity of current line
      • run – to run the program or to initiate the debugging process
      • print <variable name> – to see the value of a variable at the current state of program
      • s or step – to step through the program line by line
      • n or next – same as step but doesn’t enter inside a function when a function call is encountered
      • set var <variable name> – to change the value of a variable at run time
      • quit – to quit the debugger environment

    There are a lot more commands available for GDB, a sophisticated debugger. I have presented only what I found really useful and have learned to use. You can explore more by exploring the man page for gdb (man gdb). Of course, you can also refer to RMS’s gdb Debugger Tutorial (linked above) or any other good guide to learn more.

    Do tell if this was useful to you. 🙂

    EDIT (2010-11-18): Found a really nice document explaining how to use gdb and other Unix Programming Tools: http://cslibrary.stanford.edu/107/

    Plus if you are interested in learning pointer intensive coding (linked lists, binary trees, etc.), a really good resource is Stanford CS Ed Library. I learned a lot from this for my Program Design exam today.

    EDIT (2011-01-04): For seeing the values of an array, the following syntax comes in handy: p *array@len

    • Ershad K 11:33 PM on January 4, 2011 Permalink | Reply

      Really a helpful article. It would be nice if you could explain debugging process with a suitable example, going through each line and outputs of commands. Thank you very much for the article and the link you shared.

      • Kartik 11:55 PM on January 4, 2011 Permalink | Reply

        As I have mentioned I am just learning to use gdb, it may not be possible for me to explain using some examples yet. But you can try googling for it, you will find many suitable examples.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc