SPO600's Blogs Post

Introduction In the world of compilers and optimization, understanding the intermediate representation of code is crucial. This blog post delves into the investigation of the proof-of-concept Automatic ifunc tool and the Gimple intermediate representation produced by the GCC compiler. We'll explore the steps involved, analyze the outputs, and discuss my key findings while working on this project. Part I: Automatic ifunc Tool Exploration Step 1: Obtaining the Proof-of-Concept Code The journey begins by obtaining the autoifunc proof-of-concept code from the specified file and unpacking it on an aarch64 machine. The provided commands guide the user through this process, resulting in a directory structure at ~/spo600/autoifunc-preprocessor-poc/. cd tar xvf /public/spo600-autoifunc-preprocessor-pos.tgz cd spo600/autoifunc-preprocessor-poc/ Step 2: Building and Comparing Outputs The "make" command is used to build the assembly language code. The subsequent diff command compare

Writing and debugging assembly code is a unique and challenging experience that offers a deep understanding of the underlying architecture of a computer system. In this blog post, I'll share my experiences with writing and debugging assembly code while completing the tasks for the lab 4, and drawing comparisons between the AArch64 and x86_64 architectures. Task 1: Hello World Loop Starting with a simple "Hello World" loop in both AArch64 and x86_64, we encountered the raw power of registers. The minimalistic yet powerful nature of assembly language became apparent as we directly manipulated registers, delving into the bare metal of the architecture. In AArch64, the mov, add, cmp, and b.ne instructions orchestrated the loop. Meanwhile, in x86_64, the dance of %rax, %rdi, and %rsi registers choreographed the elegant routine. Writing assembly code felt like composing a symphony of registers, each playing its part in harmony. For AArch64 Assembly :- .text .globl _start min =

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