The budget session of the Gujarat Legislative Assembly has begun, and today, the state's Finance Minister, Kanu Desai, will present the Gujarat government's general budget. This will be Kanu Desai's fourth budget presentation.

Gujarat Budget 2025 LIVE Finance Minister Kanu Desai to Present Gujarat’s Fourth Budget

Members of the Virginia General Assembly are currently engaged in a number of debates about public policy issues. But some of the important issues are NOT being debated.

Efforts to reform Virginia's campaign finance laws have died again this year | WVTF

General Assembly bills banning personal use, enabling public financing advance.

Campaign finance bills now need to survive the other chamber

General Assembly, a leading provider of tech talent and training solutions, today announced new cybersecurity and IT training programs designed to hel

General Assembly Launches Cybersecurity & IT Training Programs in Partnership with CompTIA to Close Enterprise Cybersecurity Skills Gap | Business Wire

Urgent responsibility was the overriding theme of the 15th annual International Renewable Energy Agency (IRENA) assembly, which convened on Jan. 12 in Abu Dhabi.

IRENA Assembly 2025: Unequal access to clean energy finance needs attention – pv magazine International

Business News: Get latest news on share market, personal finance news, economy news, stock market updates, company news, politics news, Assembly Election Results 2024, breaking news at Business Standard. Catch all the latest Nifty Sensex news live updates.

Business News, Finance News, India News, Assembly Election Results 2024, Stock Markets BSE/NSE News, SENSEX, NIFTY

Assembly

assembly

Imagine you are in the 1950s with only one programming language developed. Now, return to the present where there are more than 8000 programming languages developed. Among those, only 100s of them are widely used and promise an easy and promising career. So, the race for a programming language is high here, but let's go back to a time when there was only assembly language ruling over the market. All the system programs and application programs were entirely built on Assembly language. You know Assembly, you know the computers, and you get hired. But in current times, all those programming languages with all those frameworks and competitions make it easier for programmers to get into this field and make a career out of it. But is it even easier for a programmer with knowledge of assembly to make it big into the market? The Question Arises: Is Assembly Still Good Enough to Make It Up With These Languages? The simple answer to the question is assembly is still good and better than these languages because assembly was the foundation for the building of all these available languages like: Python
Javascript
C
C++
Swift etc. The Current Market Situation of Programming: Most Used Programming Languages According to a survey done by a site named Statista, the most used programming languages in 2023 are: Javascript (63.61%)
Python(49.28%)
Typescript(38.87%)
Java(30.55%)
C#(27.62%) etc. Where Assembly languages don’t even make it to the list. The Current Situation of Assembly in A Professional Context Although Assembly doesn’t make it on the list, malware analysts and reverse engineers use assembly for their daily work. Different software developed are not written on assembly due to their complexity. But still, some professions require the need of assembly language. So, Assembly is still in the race. Why Even Learn Assembly Then? Now with this in your head, everybody is wondering why learn assembly if you have to go through such a hard time, and the chances of using Assembly in your career are low. First of all, in the tech industry, if you are just for money, you are never gonna make it long or big in the field. Learning is the key to success in the industry. So, the most basics of technology are working off a computer and all for which the best resources may be understanding the fundamentals of computers and programs in Assembly. Assembly language requires a deep understanding of OS, syscalls, memory, interrupts, drivers, etc. which makes you a tech wizard. Moreover, there goes a saying “Everything Is Open Source If You Can Read Assembly” You can understand the workings of every technology and software if you know how to program in assembly language. The Dying Art of Assembly Currently in the market, most of the programming languages have their own community  to learn together and grow. So goes assembly, but due to a lack of knowledge of the invincible power of assembly, the community is smaller and consists mostly of people who don’t use assembly as their primary language. The real art and capability of assembly language are being hindered by the obsolete talents following the assembly languages. Moreover, the hardware being developed also puts restrictions on assembly being used to its fullest. In the current scenario, people want to learn assembly to be cool rather than to understand the core of computer systems. Most of them follow the tutorial and miss the essence of true programming. Closing Thoughts As we travel from the basic days of the 1950s to today's tech-savvy world, things sure have gotten complex. Back then, assembly language was the boss. You knew assembly, you knew computers, and you got hired. Nowadays, it's a different story. There are thousands of programming languages out there, but only a handful really make the cut for a solid career. So, where does assembly fit in? Sure, newer languages might seem fancier, but assembly was there from the start. It's like the great-grandparent of all the cool languages we use today, like Python, JavaScript, and C++. But does that mean assembly is still relevant? Absolutely. It's the OG—the original gangster. Understanding assembly gives you a deep insight into how computers really work. And in a world where speed and efficiency matter more than ever, that's a pretty big deal. So, while assembly might not be the easiest language to learn, it's definitely worth it. It's like having a secret weapon in your programming arsenal—one that sets you apart from the crowd and opens doors to endless possibilities. Imagine you are in the 1950s with only one programming language developed. Now, return to the present where there are more than 8000 programming languages developed. Among those, only 100s of them are widely used and promise an easy and promising career. So, the race for a programming language is high here, but let's go back to a time when there was only assembly language ruling over the market. All the system programs and application programs were entirely built on Assembly language. You know Assembly, you know the computers, and you get hired. But in current times, all those programming languages with all those frameworks and competitions make it easier for programmers to get into this field and make a career out of it. But is it even easier for a programmer with knowledge of assembly to make it big into the market? The Question Arises: Is Assembly Still Good Enough to Make It Up With These Languages? The simple answer to the question is assembly is still good and better than these languages because assembly was the foundation for the building of all these available languages like: Python Javascript C C++ Swift etc. Python Javascript C C++ Swift etc. The Current Market Situation of Programming: Most Used Programming Languages The Current Market Situation of Programming: Most Used Programming Languages According to a survey done by a site named Statista, the most used programming languages in 2023 are: Javascript (63.61%) Python(49.28%) Typescript(38.87%) Java(30.55%) C#(27.62%) etc. Javascript (63.61%) Python(49.28%) Typescript(38.87%) Java(30.55%) C#(27.62%) etc. Where Assembly languages don’t even make it to the list. The Current Situation of Assembly in A Professional Context The Current Situation of Assembly in A Professional Context Although Assembly doesn’t make it on the list, malware analysts and reverse engineers use assembly for their daily work. Different software developed are not written on assembly due to their complexity. But still, some professions require the need of assembly language. So, Assembly is still in the race. Why Even Learn Assembly Then? Why Even Learn Assembly Then? Now with this in your head, everybody is wondering why learn assembly if you have to go through such a hard time, and the chances of using Assembly in your career are low. First of all, in the tech industry, if you are just for money, you are never gonna make it long or big in the field. Learning is the key to success in the industry. So, the most basics of technology are working off a computer and all for which the best resources may be understanding the fundamentals of computers and programs in Assembly. Assembly language requires a deep understanding of OS, syscalls, memory, interrupts, drivers, etc. which makes you a tech wizard. Moreover, there goes a saying “Everything Is Open Source If You Can Read Assembly” “Everything Is Open Source If You Can Read Assembly” You can understand the workings of every technology and software if you know how to program in assembly language. The Dying Art of Assembly The Dying Art of Assembly Currently in the market, most of the programming languages have their own community  to learn together and grow. So goes assembly, but due to a lack of knowledge of the invincible power of assembly, the community is smaller and consists mostly of people who don’t use assembly as their primary language. The real art and capability of assembly language are being hindered by the obsolete talents following the assembly languages. Moreover, the hardware being developed also puts restrictions on assembly being used to its fullest. In the current scenario, people want to learn assembly to be cool rather than to understand the core of computer systems. Most of them follow the tutorial and miss the essence of true programming. Closing Thoughts Closing Thoughts As we travel from the basic days of the 1950s to today's tech-savvy world, things sure have gotten complex. Back then, assembly language was the boss. You knew assembly, you knew computers, and you got hired. Nowadays, it's a different story. There are thousands of programming languages out there, but only a handful really make the cut for a solid career. So, where does assembly fit in? Sure, newer languages might seem fancier, but assembly was there from the start. It's like the great-grandparent of all the cool languages we use today, like Python, JavaScript, and C++. But does that mean assembly is still relevant? Absolutely. It's the OG—the original gangster. Understanding assembly gives you a deep insight into how computers really work. And in a world where speed and efficiency matter more than ever, that's a pretty big deal. So, while assembly might not be the easiest language to learn, it's definitely worth it. It's like having a secret weapon in your programming arsenal—one that sets you apart from the crowd and opens doors to endless possibilities.

Is Assembly Language a Dying Art?

In the exciting journey of developing a RISC-V assembler using C#, we delve into the intricate processes that bring assembly code to life. In this article, we focus on the Label Processing phase and discuss the essential aspects of handling labels, calculating addresses, and dealing with offsets. Phase 1: Label Processing The Label Processing phase is crucial for creating a robust assembler. Labels provide a symbolic representation of memory addresses and play a pivotal role in facilitating jumps and branches in the code. Let's break down the steps involved in processing labels. Identifying Labels The first step is to iterate through the assembly code and identify labels. Labels in assembly code typically end with a colon “:”. We use a simple algorithm to extract and store these labels along with their corresponding addresses. public static void ProcessLabels(string[] code)
{
    foreach (var assemblyLine in code)
    {
        var line = assemblyLine.Trim();
        if (string.IsNullOrEmpty(line)) continue;
        if (line.StartsWith(".")) continue;
        if (line.EndsWith(":"))
        {
            string label = line.Substring(0, line.Length - 1);
            AddressLookupTable.Add(label, Address.CurrentAddress);
            continue;
        }
        Address.CurrentAddress += 4;
    }
} Calculating Addresses To maintain the coherence of memory addresses, we increment the address by 4 (decimal) for each instruction, excluding empty lines, labels, and directives. In RISC (Reduced Instruction Set Computing) architectures, all instructions are of the same fixed size. Each instruction is 32 bits (4 bytes) long. By incrementing the address by 4 for each instruction, the assembler ensures that subsequent instructions are stored in consecutive memory locations. This sequential arrangement facilitates easier memory access during the execution phase, as the processor can fetch instructions efficiently without having to perform complex calculations to determine the next instruction's location. Addressing Offsets The concept of offsets is crucial for resolving the actual memory addresses of labels during execution. Since the assembler does not know the final memory layout, we use offsets to bridge the gap. The offset is calculated by subtracting the current address ( ) from the label's address. This difference represents the distance between the current instruction and the target label in terms of memory locations. Address.CurrentAddress The calculated offset is then utilized in the machine code generation process. It allows the assembler to generate machine code instructions that incorporate the correct memory addresses, accounting for the relative positions of labels within the code. For example, if the current address is 28 and a label is at 10, the offset is -18. During execution at address , the location of the label is ( ). 0x00FF28 0x00FF06 0x00FF28 - 0x12 Machine Code Generation During the generation of machine code, we encounter the challenge of handling labels, especially when they represent memory addresses. If an immediate value is not an integer, it implies a label reference. In such cases, we retrieve the address from the lookup table. int labelAddress = AddressLookupTable[assemblyLine];
int offset = labelAddress - Address.CurrentAddress; As we progress in developing the assembler, understanding labels, addresses, and offsets lays a solid foundation for the subsequent phases. SharpRISCV The repository serves as the starting point for enthusiasts eager to explore and contribute to the project. SharpRISCV If you find the project helpful and informative, don’t forget to give it a star on GitHub to show your support. In the previous parts, we delved into i , and now, with a grasp of addressing modes, labels, and offsets, we eagerly anticipate the exploration of directives in the upcoming part. Stay tuned for the next installment in our journey through the world of RISC-V assembly and C# magic. nstruction types, parsing instructions, and converting to machine code

Understanding RISC-V Assembly Language by Building an Assembler in C# - Part 2

RISC-V is an open-source instruction set architecture (ISA) that has gained popularity due to its simplicity and flexibility. In this article, we’ll explore the fundamentals of RISC-V assembly language by building an assembler in C#. Our goal is to read RISC-V assembly code, identify the instruction type, and convert it into machine code. We’ll use Visual Studio as our development environment for this project. Setting Up the Project Let’s begin by creating a new project in Visual Studio. We’ll build our RISC-V assembler step by step. We mention that we will be building the assembler incrementally, and the first task is to set up a loop to read a file containing RISC-V assembly code and iterate over each line. This loop will serve as the foundation for processing the assembly code. string[] lines = File.ReadAllLines(filePath);

foreach (string line in lines)
{
  // Process the 'line' here, e.g., identify instruction type, parse, and convert to machine code
} Identifying Instruction Types RISC-V instructions are categorized into different types: R, U, I, B, S, and J. To determine the type of instruction, we’ll use a lookup table for opcodes, func2, and func7. You can find the lookup table in this . file Here’s an example of how to identify the instruction type: switch (opCode)
{
    case (OpCode)0b0110011:
        return InstructionType.R;
    case (OpCode)0b0010111:
        return InstructionType.U;
    case (OpCode)0b0110111:
        return InstructionType.U;
    case (OpCode)0b0010011:
        return InstructionType.I;
    case (OpCode)0b1100011:
        return InstructionType.B;
    case (OpCode)0b0000011:
        return InstructionType.I;
    case (OpCode)0b0100011:
        return InstructionType.S;
    case (OpCode)0b1101111:
        return InstructionType.J;
    default:
        return InstructionType.Unknown;
} You can find the implementation of this function in the file. RiscVAssembler.cs Parsing Instructions Now that we can identify the instruction type, let’s parse each instruction based on its type. We’ll start with the R-type instructions, which have the syntax: . op rd, rs1, rs2 For example, the instruction can be parsed as follows: add x10, x1, x2 Regex rTypeRegex = new Regex(@"^(\w+)\s+(\w+),\s+(\w+),\s+(\w+)$");
Match rTypeMatch = rTypeRegex.Match(instruction);
if (rTypeMatch.Success)
{
    return new RiscVInstruction
    {
        Instruction = instruction,
        Opcode = rTypeMatch.Groups[1].Value,
        Rd = rTypeMatch.Groups[2].Value,
        Rs1 = rTypeMatch.Groups[3].Value,
        Rs2 = rTypeMatch.Groups[4].Value,
        Immediate = null,
        InstructionType = InstructionType.R
    };
} You can find the complete implementation of the R-type instruction parser in the file. R_Parser.cs Converting to Machine Code Once we’ve parsed an instruction, we can convert it into machine code. Each instruction type has its own format. For R-type instructions, the format is as follows: R type: .insn r opcode6, func3, func7, rd, rs1, rs2
+-------+-----+-----+-------+----+---------+
| func7 | rs2 | rs1 | func3 | rd | opcode6 |
+-------+-----+-----+-------+----+---------+
31      25    20    15      12   7        0 For example, the instruction is translated into , where: add x10, x1, x2 00000000001000001000010100110011 Opcode 6: 0110011 Rd = 01010 Func 3 = 000 Rs1 = 00001 Rs2 = 00010 Func7 = 0000000 Here’s an example of how to convert the parsed instruction into machine code: string opcode = ((int)instruction.OpcodeBin).ToBinary(7);
string rdBinary = Convert.ToString(int.Parse(instruction.Rd.Substring(1)), 2).PadLeft(5, '0');
string func3 = ((int)instruction.Funct3).ToBinary(3);
string rs1Binary = Convert.ToString(int.Parse(instruction.Rs1.Substring(1)), 2).PadLeft(5, '0');
string rs2Binary = Convert.ToString(int.Parse(instruction.Rs2.Substring(1)), 2).PadLeft(5, '0');
string func7 = ((int)instruction.Funct7).ToBinary(7);

return new MachineCode($"{func7}{rs2Binary}{rs1Binary}{func3}{rdBinary}{opcode}", instruction.Instruction); You can find the complete implementation of machine code generation in the file. R_MachineCode.cs Conclusion In this article, we’ve embarked on a journey to learn RISC-V assembly language by building an assembler in C#. We’ve covered the basics of reading RISC-V assembly code, identifying instruction types, parsing instructions, and converting them into machine code. This project serves as a valuable learning experience for understanding the inner workings of RISC-V assembly language and its translation into machine code. To delve deeper into the RISC-V architecture, refer to the . RISC-V Specification Here’s the GitHub repository link for the project where you can find the code for building a RISC-V assembler in C#: . SharpRISCV GitHub Repository If you find the project helpful and informative, don’t forget to give it a star on GitHub to show your support. In the of our RISC-V assembly language learning series, we will explore , which are essential concepts for understanding and writing more complex assembly programs. Stay tuned for the next installment! next part addressing modes, labels, and offsets Also published . here

Understanding RISC-V Assembly Language by Building an Assembler in C#

Are you going to be writing code anytime soon in assembly? Maybe not, as it has very niche use cases. So then why should you bother learning it? Well, before we answer that, let’s take a small look into what assembly even is to better understand how it could help you. Assembly is a term for low-level programming languages that are limited to specific computer architectures. Today it is mainly used in hardware programming and low-level programming on embedded chips. Most mobile devices today use ARM chips written in ARM assembly. Processors execute commands in binary; they communicate with all the peripherals and handle all the instructions in 1’s and 0’s, which is called machine language. Except, writing complex programs and software in binary wouldn’t be practical or easy for us as programmers. That’s where the “assembler” steps in and translates your assembly code to something a bit more legible for the processor. Each instruction written in assembly is tied to a specific instruction on the processors, which is why assemblers are tied to specific instructions based on the architecture of the chip they’re made for. For example, Intel’s i386 processors (or x86) instruction set is very different from ARM’s instruction set. However, I’ll be looking into the specifics, differences, and evolution of each architecture another time as going into detail now will draw away from this topic. So you’re saying the assemble is a compiler? Well, yeah, it is essentially a compiler but for assembly language. Except there are a few differences between a compiler for C, C++, Java, etc. Most notably, a compiler converts a whole lot of code into machine language at once, while the assembler goes line by line. There are other differences that I encourage you to look into, as the inner workings of a compiler are very interesting. Enough about the assembler; let’s look a bit more into the cryptic language itself and what makes it so special. The assembly language isn’t like other higher-level programming languages such as Java, Python, C#, etc. The language syntax is symbolically much close to machine code as you’re working directly with memory locations and addresses inside the processor. We know that computers work with individual bits to compute some kind of action, be it a calculation or an I/O action. But since working with individual bits doesn’t happen all too often, we group the actions into chunks of a fixed size. This is where 32bit and 64bit processors come into play. These processors handle information at 4 bytes or 8 bytes at a time, respectively. To utilize the memory, the processor has two basic functions, and read write. The processor initiates a operation by sending a signal to the specified memory address and makes a copy that is then sent back to the processor to be read. read The processor initiates a operation by transferring information from the processor over to a specified memory address. This action overwrites any information that is currently in that specific memory address. write These two basic functions are very important because both program instructions and data are stored in memory. So writing to a location in assembly doesn’t imply just handling data, but also executing your desired instructions. This means that as an assembly programmer, you have to be very conscious about which memory addresses you’re using, how much memory you’re using (keep in mind that assembly is usually used on devices with very limited memory) to keep your program in check. This point does bring us to the main reason assembly would help you become a better programmer: being more careful with memory. A lot of the time, we become careless with the way we handle data in our code, and it leads to a lot of memory overflows that can sometimes cause serious or fatal runtime errors. Some of us (myself included) have become especially spoiled with garbage collectors like the GC in Ruby. Of course, most of the time, it isn’t a problem, and yes, utilizing a garbage collector is absolutely great. But being able to fully understand what your program is doing every step of the way alleviates a lot of the confusion of “This should work, but it doesn’t” and “This shouldn’t work, but it does.” Forcing yourself to work within this constraint of handling memory allocations properly in assembly will help you be more conscious about what exactly your program is doing in other languages. It gives you that better representation of how data is utilized in memory. Some of you may remember Donkey Kong 64 and how you needed to use the “expansion pak” to play it. This was due to a bug in the game that caused some kind of memory issues on the 4MB of the standard N64. This bug would cause any system without the pak to crash after a few minutes of game time. Rather than fix the bug, Nintendo had to sell every copy with an “expansion pak” that just added more memory, causing the game to crash long after a “regular” gaming session of about 10 hours. This is an example of how not properly managing your code and understanding the underlying issues of what is going on inside to have drastic effects. Chris Marlow (One of the developers of DK64) mentions this during a stream. We can gather from this that assembly forces the programmer to have a deeper understanding of how the device works for it to work. When writing assembly you have to look into how the instructions access different parts of the CPU, the memory, the other internal devices, and even how your program accesses external devices. This knowledge gives you, the programmer, extensive information on how everything comes together to control the entire system. Even when you’re not writing in assembly anymore, this knowledge stays with you and makes you aware of how even higher-level languages will be interfacing with other devices. Now it would be interesting to take a look into where and how assembly is even used today. Qualcomm Snapdragon chips that are used in millions of mobile devices today use the ARM architecture. Meaning they are all programmed in assembly to control the devices. A lot of IoT devices and mostly low-level hardware and microcontrollers are programmed in assembly. This is because assembly gives the most control over hardware as you have direct access to what is used and how. Coupled with the fact that assembly is not a heavy or big language allows it to be used with the least amount of memory. This makes it a no-brainer for these types of devices. Another popular use for assembly is in the reverse engineering of video games. The reason for this is since direct access to any code is basically non-existent when a video game is packaged and released, looking at how a game interacts with all the memory addresses allows programmers to understand how and what is being done. By doing this, communities can piece together bits of code, rebuilding a game’s source code like a jigsaw puzzle. It’s a fun exercise and allows you even to modify older games to do what you want. There are huge communities on older games, and new things are being found even today for games that were released decades ago. In 2019 a hidden coop mode was found in the game files for Luigi’s mansion on the GameCube. This goes to show how much there is to discover in these games. Suppose reverse engineering sounds interesting, and you are a fan of the older GameCube animal crossing games. In that case, I’d suggest reading mode. It goes into lengthy detail and could help get you interested in the topic. If this game, in particular, doesn’t interest you, you should have almost no trouble finding some info on a game that you do enjoy. You should also check out the jamchamb’s blog on how he reverse-engineered the games developer subreddit r/REGames/ In summary, assembly is a powerful language for programmers that forces you to work within specific constraints and understand the underlying concepts that go into building software and working with a computer. You have to focus on how your program interacts with each component of the processor, what data is being transferred, and how. This detailed level of thinking helps you with other languages that are not boxed into these constraints, leading you to develop more effective software. Let me know your thoughts on the matter and whether or not you use assembly in any way. If you’ve got any questions, reach out to me at ! info@maddwriting.com https://www.redpointwriting.com/assembly_better_programmer.html Previously published at

Should you Learn Assembly to Become a Better Programmer?

Ok so before we move on and jump into writing and running 64 bit programs (because all programs today are 64bit these days no? j.k.) let's have a look how to compile a simple program for each of those architectures. This knowledge should also help you better understand how to start a nano VM and "debug" problems that might arise. To produce binaries we will use nasm compiler and to explore them we will use radare2 (https://rada.re/n/). Program that we will compile and analyse will be extremely simple. This is so we can focus on important aspects of 16, 32 and 64 bit programs rather than complexities in the programs themselves. Source code for all examples and compiling them is available in GitLab repo: . https://gitlab.com/mvuksano/kvm-playground/-/tree/master/05-assemly-compiling Let's jump into it. 16 bit assembly Let's compile the following program: , , , , , BITS 16 mov ax 'A' add ax '0' mov dx 0x3f8 out dx al mov eax 0xc000 jmp eax As you can see, it starts with directive. This tells compiler that we are want to produce a 16 bit binary. BITS 16 To produce a binary we only need to invoke compiler. nasm nasm -o a16.bin a16.asm There are a lot of tools that we could use at this point look into the executable. I'll use radare2 as it comes with some bells and whistles (e.g. nicely formatted and colored disassembly) The first line ( ) is represented using 3 bytes. b8 is the opcode for mov instruction while the following two bytes is number 0x41 written using two bytes in little endian format. mov ax, 0x41 Next line ( ) encodes instruction to add to whatever value is in register and store it back into . Notice how ax is 16 bit register and the immediate operand (0x30) is 8 bits in size. ADD instruction ( ) has numerous options that customize its operation. In this case we use to tell ADD op to use register as source and destination. 0x83c030 0x30 ax ax 0x83 0xc0 ax Following that is .  This instruction does similar thing to in the first line. Notice how the second byte changed from to . This is because opcode of this instruction encodes which register is used. In this case this instruction tells CPU to use register . 0xbaf803 0xb84100 8 a dx instruction is a simple one. It's a one byte instruction telling our CPU. 0xee Following is . We've seen before. We also know that is target of our jump instruction written in little endian format. Two questions that remain are: 1. What is that in front of ? and what is that at the end of the instruction? 0x66b800c00000 0xb8 0x00c0 0x66 0xb8 0x0000 is part of the instruction which tells CPU to use non-default instruction length. In our 16bit program default length for instruction is 16 bits (e.g. register). Here we are putting value into 32bit register . In our case can be written as . We just added a number of zeros to get a 32bit number. Now if we write in little endian format we get . This is exactly sequence of digits that we see following . 0x66 MOV ax 0xc000 eax 0xc000 0x0000c000 0x0000c000 0x00c00000 0x66b8 is the last instruction in our program. 0x66 serves same purpose as in previous instruction - it tells CPU to "switch to" using 32 bit operands. is opcode for instruction. 0x66ffe0 0xffe0 jmp eax Before we move on to looking at 32bit version of the same program keep two things in mind: CPU expects operands to be 2bytes in size usually if we want to use 32bit operand size we need to use opcode prefix 0x66 to tell x86 CPU to do so. 32 bit assembly Let's have a look at what the same program looks like compiled using 32 bits: , , , , , BITS 32 mov eax 'A' add eax '0' mov edx 0x3f8 out dx al mov eax 0xc000 jmp eax You can notice a few changes. First line is directive that tells compiler that we want to output 32 bit binary. Also notice that instead of using as operand we use . is name of 32 bit register while is used to name 16 bit register. As a matter of fact represents lower 16 bits of register. nasm ax eax eax ax ax eax Looking at disassembly we can see that it's very similar. Another thing worth pointing out is that prefix in front of second last instruction is not there any more. In 32bit mode default operand size is 32 bits so there's no need for prefix in this case. 0x66 Size of binary has also slightly increased. Instead of being 13 bytes in size its not 15 bytes. 64 bit assembly Lastly let's look at equivalent 64 bit program: , , , , , BITS 64 mov rax QWORD 'A' add rax QWORD '0' mov rdx QWORD 0x3f8 out dx al mov rax QWORD 0xc000 jmp rax Besides directive telling compiler that it should output 64 bit program we use to explicitly specify that immediate operands should be 8 bytes in size. BITS QWORD Looking at the disassembly we can see that it grew in size again. This is expected as size of immediate operands is doubled. Besides the operand size this disassembly looks very similar to 32 bit one. One difference we can immediately notice is that a lot of instructions have prefix. This is so called REX prefix. It's available in 64 bit mode only and in this case tell CPU that the instruction should use 64 bit operand size. Keep in mind that some instructions, in 64 bit mode, do not use 64 bit operand by default but instead use 32 bit ones. MOV is an example of such an instruction. 0x48 Conclusion In this article we have taken a look at a very simple program and its representation as 16, 32 and 64 bit binary. I don't expect you will need to deal with assembly code day to day but being familiar with it is very useful when working with hypervisors and VMs. In the early stages of a VMs life there are very few tools for debugging and the best one you have is in knowing what the code does. In the following article we will modify our VM to switch into long mode and we will execute the 64 bit binary. References http://ref.x86asm.net/coder32.html https://c9x.me/x86/html/file_module_x86_id_222.html https://wiki.osdev.org/X86-64_Instruction_Encoding#togglelink:~:text=4.1.2%20REX%20prefix

16/32/64 Bit Assembly Programs

As I've continued my dive down the rabbit hole that is assembly, I've found a buoy to grab onto: NES programming. Early Beginnings The NES was my very first video game console, the remodeled version from the early 90s. Super Mario 3 was my absolute favorite, even though I couldn't really get past World 3, the water world, without using a warp whistle. In short, the NES was a huge part of my childhood. It's worth mentioning that I wanted to make games basically since I saw Crash Bandicoot for the first time. Since I found out making games was even an option. The idea that I can program my first console is almost dreamlike. Weapon of Choice Anyway, remember when I said in the last post that assembly is highly system specific? Well, that ain't the half of it, buddy! Assembly is like one piece of the puzzle when it comes to 80s era systems. I mean, with x86, you still have to program for the OS, but there's really only a few common APIs: Windows, Linux, macOS...I mean, if you need an executable for BSD, sure, it's an issue. But with 6502, my chosen language, you have to program for a specific computer model. Like the Apple II and Commodore 64 have entirely different APIs – shit, the Apple II and Apple II GS have entirely different APIs! My point is, you need to pick a system, I've found, if you want to learn these languages. I'm going with the NES and 6502 for now. Before I dive in, big shout out to , which has been an invaluable resource in my exploration. wiki.nesdev.com The Lay of the Land, or, How the Memory is Mapped Spoiler alert: everything is memory-mapped. The I/O, the picture processing unit (PPU), the audio processing unit (APU)...every time you need to communicate with another part of the system, you're probably reading or writing memory. This is so much cooler than using Yet Another Library to do I/O, or audio, or video – everything you need is right at your fingertips, a PEEK or a POKE away (or, since we're using assembly, LDA or STA). This integrated system is just the complete opposite of what I'm used to. From everything I've read about other 80s computers like the Apple II and Commodore 64, they're similar in nature. In other words, systems of that era were "batteries included". You see similar principles in languages like Python or Racket, but not at the same scale. Not on a system-wide level. Exploring the Territory To be honest, I'm still exploring what the NES can do. The one unit I've dug into so far is the APU, for generating music and sound effects, and playing samples (of a sort – it's delta modulated PCM, I think, but that's another article). The APU, if you've ever played Mario, Zelda, or Metroid on the OG NES, can be quite powerful (although limited in some ways). For example, it generates lively multi-instrument melodies on Super Mario 3, but you'll notice if you jump on certain levels or have a star power-up, it'll skip certain notes in the music because that channel's being used for the jump or the star. I've played this game a lot, if you couldn't tell, but I'm not sure if they used a custom sequencer or if this is straight up APU usage... Anyway, I'm trying to learn how to make this chip sing (literally). There's two square wave generators available, and a triangle wave, along with a noise channel (which makes me wonder if that's how speech sounds are generated in NES games). With the square wave generators, you can set up envelopes, even! Oh, and fun fact: since there's no easy echo or printf command for debugging, devs commonly use sound effects to denote points in the program, sections of code being executed. How cool is that?! Next Up Obviously, I'm still exploring the capabilities of this chip and how exactly I can use it. I think the first step here is to get a beep out of an emulator, to get a program running visibly (or audibly) on some form of the NES. To do this, I need to 1. figure out how data and code are formatted in a 6502 assembly file for the NES, 2. use cc65 to cross-compile this code, and 3. figure out how to load the result on an NES emulator. Previously published at https://insertdiskx.com/adventures-in-assembly-2/

Adventures in Assembly #2

I have this weird habit. When I find something that piques my interest, I can dive into a rabbit hole, not coming up for air for days. Naturally, this led me to a fairly deep dive over the past few nights on x86, 6502, and Z80 assembly language, as one does. Little did I know how much detail there is -- like a fractal, the more you zoom in, the more detail you find. It all started with x86. I vaguely recall how all of this started. One minute I was thinking about custom programming languages and virtual machines and LLVM and that sort of thing, and all of a sudden, there I was in assembly land. Before I knew it, I was knee-deep in Intel documentation on the x86 series, then x86-64 / x64 assembly. But, I wanted to simplify. Of course, rather than doing what any sane human would do, closing the page and walking away to do something useful, I dug in and thought, “80s era processors were way simpler, let’s explore those!” Simpler, I thought. 😂 How naive, how utterly ignorant I was. Of course, the main difference between processors of that era and modern processors is that 80s processors were designed for humans to use. x86, x64, these are built for machines to write and use. 80s machines, had no such luxury. Often, if you wanted any speed whatsoever, you had to touch bare metal, which means . C was sort of a newer thing at the time, too. assembly language You didn’t have the privilege of “ ” like you did in the 90s, with Java. You had nowhere near the ubiquitous platform of the web. No, you were writing for one machine. Your machine. write once, run anywhere And it was machine. You control the memory. You can set any pixel on the screen to any color supported by your system. You control the vertical, you control the horizontal. Do not adjust your set. your Or do! It’s . yours Why the obsession with these old processors though? What are they good for? Well, the biggest draw for me is that the NES was controlled by a 6502 variant, the Game Boy controlled by a sort of hybrid between the Z80 and 8080. These chips could be used to make games. In fact, some of them were made with that use case as a high priority. I started by exploring again, one of my favorite webpages of all time. Seriously, there’s a legible, playable, assembly language snake game at the end! I familiarized myself once again with concepts that are completely foreign to most web programmers: things like registers, status flags, “two’s complement” representation of negative numbers, how to use the carry bit for fun and profit, and much, much more. “Easy 6502” by Skilldrick As I dug into the instruction set, addressing modes (ways to access memory, basically), ways to branch...it became clear that this wasn’t going to be the nice little evening distraction I thought it would be. Yet I continued. Beyond the 6502 snake game, I thought, “the Z80 was used in the Game Boy [note: I was wrong], I’ll explore that chip!” This led to even more of a rabbit hole...I started reading a book on the Z80 and quickly started asking myself things like, what memory, anyway? is I stopped short of going beyond the lowest level language and into the microcircuitry employed in actual computers. Even I’m not crazy. But I continue reading about assembly langauges. I’ll continue to do so tonight. that did And next week, dear reader, I hope to introduce you to even more of the weird, the esoteric, and hopefully, some of the downright practical (like how page tables work!). Until then, I return to the world of Javascript, blissfully unaware of registers, memory, or anything even remotely resembling hex literals...

Adventures in Assembly #1 [How It Usually Begins]

In an earlier article, we have seen & . Here we will see "How C program converts into the assembly?"  and different aspect of its working at the machine level. C runtime: before starting main How C program stored in RAM memory /!\: Originally published @ . www.vishalchovatiya.com A bit about function stack frames During function code execution, a new stack frame is created in stack memory to allow access to function parameters and local variables. The direction of stack frame growth totally depends on compiler ABI which is out of our scope for this article. The complete information on stack frame size, memory allocation, returning from stack frame is decided at compile time. Before diving into assembly code you should be aware of two things : CPU registers of x86 machine. x86 assembly instructions: As this is a very vast topic & updating quite frequently, we will only see the instructions needed for our examples. x86 CPU Registers General Purpose Registers Pointer Register Segment Register Index Registers Apart from all these, there are many other registers as well which even I don't know about. But above-mentioned registers are sufficient to understand the subsequent topics. How C program converts into assembly? We will consider the following example with its disassembly inlined to understand its different aspect of its working at machine level : We will focus on a stack frame of the function . But before analysing stack frame of it, we will see how the calling of function happens func() Function calling Function calling is done by call instruction(see Line 15) which is subroutine instruction equivalent to: push rip + 1 ; return address is address of next instructions
jmp func Here, store the (not that +1 is just for simplicity, technically this will be substituted by the size of instruction) in the stack which is return address once call to ends. call rip+1 func() Function stack frame A function stack frame is divided into three parts /Entry Prologue User code /Exit Epilogue As you can see instructions(line 2 to 4) generated against start bracket is prologue which is setting up the stack frame for , Line 2 is pushing the previous frame pointer into the stack & Line 3 is updating the current frame pointer with stack end which is going to be a new frame start. 1. Prologue/Entry: { func() is basically equivalent to : push sub esp, 4   ; decrements ESP by 4 which is kind of space allocation
mov [esp], X ; put new stack item value X in Parameter passing Argument of is stored in register on Line 14 before calling instruction. If there is more argument then it will be stored in a subsequent register or stack & address will be used. func() edi call Line 4 in is reserving space by pulling frame pointer(pointed by register) down by 4 bytes for the parameter as it is of type . Then instruction will initialize it with value store in . This is how parameters are passed & stored in the current stack frame. func() rbp arg int mov edi ---|-------------------------|--- main()
             |                         |          
             |                         |          
             |                         |          
             |-------------------------|          
             |    main frame pointer   |          
rbp & rsp ---|-------------------------|--- func()
in func()    |           arg           |          
             |-------------------------|          
             |            a            |          
             |-------------------------|    stack 
             |            +            |      |   
             |            +            |      |   
             |            +            |      |   
          ---|-------------------------|---  \|/  
             |                         |          
             |                         | Allocating space for local variables Line 5 is reserving space for a local variable , again by pulling frame pointer further down by 4 bytes. instruction will initialize that memory with a value . 2. User code: a mov 5 Accessing global & local static variables As you can see above, is addressed directly with its absolute addressing because its address is fixed which lies in the data segment. g This is not the case all the time. Here we have compiled our code for  x86 mode, that’s why it is accessing it with an absolute address. In the case of x64 mode, the address is resolved using register which meant that the assembler and linker should cooperate to compute the offset of from the ultimate location of the current instruction which is pointed by register. rip g rip The same statement stands true for the local static variables also. After the user code execution, the previous frame pointer is retrieved from the stack by instruction which we have stored in Line 2. is equivalent to: 3. Epilogue/Exit: pop pop mov X, [esp] ; put top stack item value into X 
add esp, 4   ; increments ESP by 4 which is kind of deallocation from function Return instruction jumps back to the next instruction from where called by retrieving the jump address from stack stored by instruction. is subroutine instruction which is equivalent to: ret func() call ret pop rip ; 
jmp rip ; If any return value specified then it will be stored in register which you can see in Line 16. eax So, this is it for “How C program converts into assembly?”. Although this kind of information is strictly coupled with compiler & ABI. But most of the compilers, ABI & instruction set architecture follows the same more or less. In case, you have not gone through , here are simple FAQs helps you to understand better: my previous articles Intuitive FAQs Q. How do you determine the stack growth direction ? Simple…! by comparing the address of two different function’s local variables. A. *main_ptr = ; *func_ptr = ; { a; func_ptr = &a; } { a; main_ptr = &a;
    func();
    (main_ptr > func_ptr) ? ( ) : ( ); ;
} int NULL int NULL void func () int int main () int printf "DOWN\n" printf "UP\n" return 0 Q. How do you corrupt stack deliberately ? Corrupt the SFR values stored in the stack frame. A. { a; (&a, , ); } {
    func(); ;
} void func () int memset 0 100 // Corrupt SFR values stored in stack frame int main () return 0 Q. How you can increase stack frame size ? is the answer. Google about it or see . Although this is not recommended. A. alloca() this

How C Program Converts Into Assembly

Disclaimers: I’ll use Windows and more particularly Visual C++ with its Inline Assembler. If you use MacOs or Linux you will have significant differences comparing to what is described in the article. Everything below is shown mostly for demonstration purposes Introduction Java is mature self-sufficient language, though as we all know it is possible to “connect” java to C (via Java-Native-Interface or JNI) to speed up some critical pieces of code. Also for C/C++ it is possible to delegate some even more critical pieces of code directly to Assembly. In this article I want to show you how this Java-C-Assembly Matryoshka can look like. But note that example will be pretty simple so in real world there is no advantage of such delegation as it won’t speed up anything. The example we’ll look at will be: given a command line program (written in Java) we execute the program with providing 2 integers as arguments (with error handling on the client side) main business logic is the “sum” method, which we consider a critical piece of the program we’d like to “speed up” using C and Assembly Java Setup First of all we need to download . I have pretty old version installed, but feel free to install newer version. After installation verify that everything works: JDK >java -version
java version Java(TM) "1.8.0_121" SE Runtime Java Client Environment (build _121-b13) 1.8 .0 HotSpot (TM) VM (build -b13, mixed mode, sharing) 25.121 Code Here is our program: main function, parsing command line arguments and our target method “sum” (with implementation in java): { { (args.length != ) {
            System.out.println( ); ;
        } a; {
            a = Integer.parseInt(args[ ]);
        } (Throwable throwable) {
            System.out.println( ); ;
        } b; {
            b = Integer.parseInt(args[ ]);
        } (Throwable throwable) {
            System.out.println( ); ;
        }
  
        Test test = Test();
        System.out.println(test.sum(a, b));
    } { a + b;
    }
} public class Test public static void main (String[] args) if 2 "Error: wrong params count" return int try 0 catch "First param is not a number" return int try 1 catch "Second param is not a number" return new public static int sum ( a, b) int int return Compile In order to run the program we first need to compile it with java compiler. It will generate binary file which we’ll later on execute. Test.class > javac Test.java Execute To execute program call java and provide arguments. See that our program works correctly and prints sum of numbers. > java Test 3 4 7 C/JNI Setup Install and using it install Visual C++ build tools: Chocolatey choco install visualcpp-build-tools We’ll need these tools to compile C files into library dll file. Specifically for compilation we’ll need command, so check that it works: cl > cl C/C++ Optimizing Compiler Version 19.16.27031.1 x86 Microsoft Corporation.  All rights reserved. Microsoft (R) for Copyright (C) Code Java can communicate with C via JNI. In order to setup that communication we need to update our Java program: { { (args.length != ) {
            System.out.println( ); ;
        } a; {
            a = Integer.parseInt(args[ ]);
        } (Throwable throwable) {
            System.out.println( ); ;
        } b; {
            b = Integer.parseInt(args[ ]);
        } (Throwable throwable) {
            System.out.println( ); ;
        }
        System.loadLibrary( );
        Test test = Test();
        System.out.println(test.sum(a, b));
    } ;
} public class Test public static void main (String[] args) if 2 "Error: wrong params count" return int try 0 catch "First param is not a number" return int try 1 catch "Second param is not a number" return "Test" new public native int sum ( a, b) int int First, instead of static method with implementation we provide so called native method. It doesn’t have any implementation because we expect it to be provided via JNI. Second, we need to load our C library — and we do that with method. System.loadLibrary After we updated our program we need to generate Test.h header file: > javah Test Generated header file will contain all the setup for our C program. We had one native method in our Java program and here we have method declaration for our method generated in header file: #include <jni.h> #ifndef _Included_Test
#define _Included_Test
#ifdef __cplusplus
extern {
#endif ;
#ifdef __cplusplus
}
#endif
#endif /* DO NOT EDIT THIS FILE - it is machine generated */ /* Header for class Test */ "C" /*
 * Class:     Test
 * Method:    sum
 * Signature: (II)I
 */ JNIEXPORT jint JNICALL Java_Test_sum (JNIEnv *, jobject, jint, jint) We need to have an implementation of our function, so create Test.c file and implement method: #include { a + b;
  } {} "Test.h" JNIEXPORT jint JNICALL Java_Test_sum (JNIEnv *env, jobject obj, jint a, jint b) return void main () Compile Compile our C library into Test.dll: > cl -I -I -LD Test.c -FeTest.dll "%JAVA_HOME%\include" "%JAVA_HOME%\include\win32" Execute Recompile our Java program as shown above and execute to see that it still works: > java Test 3 4 7 Assembly Code Previously we had C implementation which looked basically as on java: . When we work with Assembly we work on a lower level so such small operations require quite more code. Let’s update our C program to use Assembly — for this we add — which is Inline Assembler for Visual C++. Inside that block we write instructions. You see that we put our variable a into register , put our variable into register . Then we make a sum from contents of registers and store it in the register (this is what add command does). Lastly we store value of the register in our result field: a + b __asm block eax b ebx eax eax #include #include <stdio.h>
JNIEXPORT jint JNICALL Java_Test_sum
  (JNIEnv *env, jobject obj, jint a, jint b) {
    int result;
    __asm {
        mov eax, a
        mov ebx, b
        add eax, ebx
        mov result, eax
    } result;
} main() {} "Test.h" return void Recompile C library (no need to recompile Java program) and execute Java program again: > java Test 3 4 7 So, it works. Hope you’ve enjoyed and maybe learned something today. If not then I hope at least it was funny. Happy coding! References The javac tool reads class and interface definitions, written in the Java programming language, and compiles them into…docs.oracle.com If you have a few years of experience in the Java ecosystem, and you're interested in sharing that experience with the…www.baeldung.com Assembly language serves many purposes, such as improving program speed, reducing memory needs, and controlling…docs.microsoft.com

Java-C-Assembly Matryoshka

SIMD Assembly instructions let you manipulate batches of data in parallel, in a single core. and I’ll say it again: programming is the closest thing we have to magic. I’ve said it once are like small cantrips, Python scripts are little helpful Tulpas. We even have our own Daemons! But whenever we need to squeeze performance to the last byte–When we know a single misstep will make the program slow down drastically… That’s when Assembly, the darkest of black magicks, comes in. Shell commands I haven’t been writing too often lately, as you probably didn’t notice (incidentally, if this is your first time reading me, welcome! Nice to meet you!). That’s because I had a pretty harsh exam last week, and I had to prepare a lot. The subject is called ‘Computer’s Organization II’, and it’s been a huge challenge keeping up to date with it.So I decided I would take one of the exercises I made while I practiced, and turn it into an article. That way I can break two scissors with one stone (killing birds is bad and you should feel bad). Without delaying this further, let’s cut straight to the chase. As usual, the code is available at this . Github project What are processor instructions? All the code we write, be it in Python, Java, or C, is eventually interpreted, or compiled, into tiny, atomic (from a programmer’s perspective) instructions for our CPU(s).These instructions number in the thousands, and each of them does a very small thing, interacting directly with hardware. As an example, an instruction may write a value into memory (that’s what variable assignment translates into), turn a bit on or off, or do a logical . AND My PC has an Intel processor, which is also the architecture we learn about in class, so sorry to all my ARM using readers, I won’t be inclusive enough today. The language in which these instructions are written (which translates 1:1 to literal binary) is called Assembly. Translating C to Assembly: Let’s become compilers for a while. For this article we’ll be using a very small C function. Here’s it’s entire code: This function takes as parameters a pointer to a stream of bytes (a weighs a single byte), a char and a char.It’ll assume the stream ends in a 0 (and crash into a segmentation-fault if that’s not the case), and iterate it byte by byte, replacing each instance of ‘have’ with want.As far as C goes, this is as fast as it gets–And it’s faster than Python by a long shot (when I ran some benchmarks, the Python version of this function took two minutes for an input size that took 6 seconds in C). char have want What does this function look like in Assembly language, after going through the compiler? It will probably be something like this: Running that assembly function instead of the C version shouldn’t increase our performance. It may even lower it, since the compiler knows a few tricks we probably don’t, and does a few optimizations on this kind of code. There’s an optimization it doesn’t usually use, though, and when it does, it never uses it to its full potential. SIMD Instructions: Single Instruction, Multiple Data Whenever we think of parallelism, we think of multicore processes, or even clusters. But what if we made a single core do many things at a time? That’s the idea the people at Intel had a few decades ago, and the world of image processing hasn’t been the same ever since. You see, normally data are stored in general purpose Registers, like the ones we just used, in our CPU. Most of them are 64 bits in size, and thus can store a a or an Well, technically two , but it’s still not enough to be worth making the instructions to use them in parallel. long, float, int. ints However, most processors have even bigger registers available: , with 128 bits on them. That’s enough for 16 whole bytes! XMMs Let’s get this party started. source: . Pixabay Imagine what we could do if we could process 16 bytes at a time, and make our programs 16 times faster. Reading from memory once and fetching 16 different bytes? Check. Processing them in batches and them writing them all at once into memory again? Check. The possibilities are endless. Especially at image or signal processing, this opens the possibility to make trivially concurrent computations a lot faster. Like, a whole order of magnitude faster. And you know what function is trivially concurrent? processing a stream of bytes with no dependencies between them. There’s a catch, though: if regular Intel instructions seem counterintuitive or ugly to you, get ready for the SIMD ones. Their names are batpoop crazy, and most of us can’t write 5 of them in a row without looking them up in the official manual (which is thankfully ). available for free With all those caveats dealt with, let me guide you through the SIMD implementation of the function I just showed you. Let me warn you: it’s not pretty, but it’s pretty darned fast. First example: getting a string’s length with SIMD Assembly instructions. First, I iterate the stream once to size it up. This function assumes the stream has a size that’s divisible by 16 (padded with zeroes in the end, with at least one 0 byte to indicate the end of the stream) for simplicity’s sake, since otherwise I’d just have to add a new and run the non-SIMD version of the size function. Let’s assume our users are willing to pad their arrays before passing them to us to make them divisible, in exchange for the performance boost and the saved therapy sessions. if If any of you need to throw up, or go have a bath, I’ll understand. Bookmark this article and come back in an hour.But, we reading from memory once every 16 bytes.That makes this program 16 times faster than the C version! are Now, for the second part, let’s actually do what we were asked: Let’s replace some bytes! That’s it. Since boolean operations byte by byte are concurrent, and so are comparisons, we can actually process each set of 16 bytes completely in parallel. Disclaimer: To those who really care about performance, note that I’ve done 2 memory reads to fetch the same data every time: once to calculate the length, and then another to do the replacement. It would be optimal to do everything in one swoop, but the code would be a lot uglier and not that educational. That’s the reason we should expect this program to be only 8 times faster than the C version, instead of 16. It’s still a very nice improvement. How much faster is using SIMD? Benchmarks! To run these benchmarks I just used the C library in a small program (available at the ). All I did was: time.h Github project Pick an array size (multiple of 16) Initialize an array of bytes with alternating values of the given size Run the C version of the function, and measure the time it takes to complete the cycle. Do the same with the SIMD Assembly version. I repeated these steps with input sizes of 1.6e7, 1.6e8 and 1.6e9. I stopped there because the next one would’ve taken a bit longer than I wished to wait, but the trend was pretty clear: INPUT_SIZE | ASM  | C (Seconds)1.6e7  |  0.005 | 0.0691.6e8  |  0.050 | 0.6871.6e9  |  0.466 | 6.868 It’s even more linear than I expected! And the ratio is around 13, so it’s even better than I estimated as well. I guess it has to do with doing less memory reads, but feel free to leave your own hypothesis in the comments. Conclusions My first conclusion here was, learning assembly is fun. My second conclusion was, there’s no way I’m passing that exam. For the sake of practicality, my third conclusion is writing SIMD programs is very efficient, and whenever we need to do something quicker, we could try using it. Or, if you’re more into higher level languages, you could look for a framework that already uses SIMD instructions in its implementation (cough, NumPy, Pandas). In any case, I think learning about low-level stuff and the inner workings of our processors can help us write better code, and get a better idea of how things are working under the hood. That’s all for today. I hope you’ve found this article entertaining, or even useful. If you wish to read further into this topic, I’d advise you to think of a problem where parallel processing may be useful, try and write it using SIMD, and then consult the Intel manual every couple steps to learn new instructions. As usual, if you find any bugs in my code, or a way I could have optimized this further, or even a typo, please let me know in the comments! The same goes for any positive feedback as well, as that is always appreciated. I’ll see you around, keep coding! Follow me on Twitter or Medium to keep receiving more articles and tutorials. Please share this article in any social media you use. Maybe you got a friend who’s been meaning to learn more Assembly lately? Hit him up with this! Originally published at www.dataden.tech on October 6, 2018.

Stories, News & Mentions about ASSEMBLY

Assembly’s Stories on HackerNoon

Assembly's News & Mentions