SPO600's Blogs Post

Introduction: Building a compiler from source code is an informative yet intricate process that provides insights into the heart of programming languages and system architectures. In this blog post, I'll share my experience building the GNU Compiler Collection (GCC) on both an x86_64 system and an AArch64 system, highlighting the steps, time considerations, the impact of parallel building, and ultimately, how I confirmed the functionality of the newly built compiler. Building on x86_64 System: Step 1: Cloning the GCC Repository The journey began by cloning the GCC repository from the official Git repository: git clone git://gcc.gnu.org/git/gcc.git Step 2: Creating a Build Directory To maintain a clean separation between the source and build files, I created a dedicated build directory outside the source tree: mkdir build_x86_64 cd build_x86_64 Step 3: Configuring t

Introduction As a beginner delving into the world of assembly language programming, I recently had the opportunity to explore the realms of the 6502 Jumps, Branches, and Procedural Math (including Bitwise Operations). In Lab 3, I got the learning opportunity to work with 6502 Math and String in order to develop and understand how we can utilize user interaction to receive our desired output. My quest led me to a captivating code adventure - a color selector with live updates. This blog chronicles my journey, highlighting the code's working functionality, critical elements, and my reflections on the experience. The Actual Code Block The code begins with a warm welcome, invoking the SCINIT routine to initialize and clear the screen, setting the stage for the colorful escapade. A delightful list of color names is then printed, each ready to be chosen by the user.   ; Colour selector - live updates ; ROM routine entry points define                    SCINIT              

Introduction: Welcome to our lab experiment where we delved into the fascinating world of Assembly Language, seeking to understand its intricacies and uncover ways to optimize code execution. In this blog post, we'll take you through our journey, from calculating the performance of an initial assembly program to the creation of a significantly faster version, and finally, share our experiences and reflections on the process. Calculating Performance: In the first part of our experiment, we analyzed a provided assembly program designed to fill a bitmap display with a solid color. The challenge was to calculate its execution time accurately. To achieve this, we meticulously evaluated the code, considering the number of clock cycles for each instruction and loop iteration. The time depends on the specific processor you are using, as different 6502-compatible processors might have slightly different timing characteristics. Considering my 6502 processor to be a standardized processor, h

     In the open-source world, contributing to established projects like the Linux kernel or the Python programming language can be a rewarding experience. However, the journey from having a great idea to getting your code accepted can be quite different from one community to another. In this blog post, I'll try to introduce and explain the patch submission process in two prominent open-source communities – Linux and Python – while highlighting the advantages and disadvantages of each approach. Linux Kernel: The Linux Patch Submission Process: Development : Like most open-source projects, contributors begin by developing their code changes. Version Control : Developers work in their own branches, forking the Linux kernel repository in Git. Patch Submission : Patches are submitted through the Linux kernel's mailing list as plain text email messages. Mailing List : The "linux-kernel" mailing list is the primary channel