]
10-10-2017, 05:55 AM
Well, it's that time of year again. The time I sit down and crank out a bunch of really complex tutorial threads that some members will read, learn, and apply over the next year. While I was discussing options on Discord, @"Ender" brought up compiler theory, which was the subject of last year's
So, the assembler, an integral part of software development in the days of old and today. We've already learned how to parse human written source code into a machine understandable format, from there it's optimized and so forth through a compiler and converted to assembly language. This assembly language is important, but also interesting. You're used to writing your code in the same language and compensating for minor library differences in how you do things. This is totally different with assembly. Every processor has its own features, and therefore its own assembly language. For this series, we will be using ARM processors, specifically the ARM1176 series (the CPU's found in the original rPI). This series won't be ultra long, but it won't be short. Maybe 5 parts total. I will be leaving off many of the processor capabilities, my goal is simply to describe how it operates so you can extend it. The original assemblers were written in either assembly language or machine code, we will be writing ours in C, so brush up on that.
Ok, so we have a few questions to ask ourselves before we dive in:
What is an assembler and assembly language?
The assembler is a translator (or interpreter in cases with JIT) for human or machine written code. Your compiler doesn't make a binary file, in fact it just produces more source code (a lot more). It's up to the other tools you use to convert these into something that you can use. As for the assembly language, it's a series of mnemonics that we as programmers have the honor of memorizing and stressing over so that we don't have to write our programs directly with a hexedecimal editor.
What essential role does the assembler play?
The assembler serves as the bridge between code and action. Many people often confuse it with a compiler, it is not. This program is responsible for translating that code your compiler spit out (or that you wrote because you hate yourself), into a specific format for your processor. This format, and often even the input code changes from processor to processor (AMD is very different from ARM, which is worlds apart from TI), so you need a different assembler for each CPU. This separation between compiler and assembler is what allows you to write the same code for whatever system you're using. Without this, you would have versions of windows source code for every CPU made (Phenom, FX, Ryzen, i7, i9, Coffee Lake, etc). The linker also plays an integral part in this, but we won't talk about that much in this series (maybe next time).
How do they function on a basic level?
Consider them an intermediate, a translator of sorts. Assemblers are just find and replace engines on a basic level. There are very few lines that you can write, so it's technically feasible to just hard code them all in and use straight find replace (some disassemblers do this). We won't be doing it that way, we will do it properly. It is important to not though, that assemblers do not optimize your code. If you write the assembly code for the processor to do something, it does that thing exactly how you asked it to, nothing more, nothing less.
Alright, I hope you're salivating by now, this is going to be an exciting series. I'll be working on a way for you to test your code out as you play with the assembler, so that we don't have to reverse engineer it all. More than likely we will use a linux operating system with qemu and lldb installed, so be prepared to install one if you don't already use one (like a real man).
[To see links please register here]
series, where members got some inside knowledge on how parsers and compilers work. This year, we will continue that spirit by adding the next step in the software development chain: The Assembler.So, the assembler, an integral part of software development in the days of old and today. We've already learned how to parse human written source code into a machine understandable format, from there it's optimized and so forth through a compiler and converted to assembly language. This assembly language is important, but also interesting. You're used to writing your code in the same language and compensating for minor library differences in how you do things. This is totally different with assembly. Every processor has its own features, and therefore its own assembly language. For this series, we will be using ARM processors, specifically the ARM1176 series (the CPU's found in the original rPI). This series won't be ultra long, but it won't be short. Maybe 5 parts total. I will be leaving off many of the processor capabilities, my goal is simply to describe how it operates so you can extend it. The original assemblers were written in either assembly language or machine code, we will be writing ours in C, so brush up on that.
Ok, so we have a few questions to ask ourselves before we dive in:
- What is an assembler and assembly language?
- What essential role does the assembler play?
- How do they function on a basic level?
What is an assembler and assembly language?
The assembler is a translator (or interpreter in cases with JIT) for human or machine written code. Your compiler doesn't make a binary file, in fact it just produces more source code (a lot more). It's up to the other tools you use to convert these into something that you can use. As for the assembly language, it's a series of mnemonics that we as programmers have the honor of memorizing and stressing over so that we don't have to write our programs directly with a hexedecimal editor.
What essential role does the assembler play?
The assembler serves as the bridge between code and action. Many people often confuse it with a compiler, it is not. This program is responsible for translating that code your compiler spit out (or that you wrote because you hate yourself), into a specific format for your processor. This format, and often even the input code changes from processor to processor (AMD is very different from ARM, which is worlds apart from TI), so you need a different assembler for each CPU. This separation between compiler and assembler is what allows you to write the same code for whatever system you're using. Without this, you would have versions of windows source code for every CPU made (Phenom, FX, Ryzen, i7, i9, Coffee Lake, etc). The linker also plays an integral part in this, but we won't talk about that much in this series (maybe next time).
How do they function on a basic level?
Consider them an intermediate, a translator of sorts. Assemblers are just find and replace engines on a basic level. There are very few lines that you can write, so it's technically feasible to just hard code them all in and use straight find replace (some disassemblers do this). We won't be doing it that way, we will do it properly. It is important to not though, that assemblers do not optimize your code. If you write the assembly code for the processor to do something, it does that thing exactly how you asked it to, nothing more, nothing less.
Alright, I hope you're salivating by now, this is going to be an exciting series. I'll be working on a way for you to test your code out as you play with the assembler, so that we don't have to reverse engineer it all. More than likely we will use a linux operating system with qemu and lldb installed, so be prepared to install one if you don't already use one (like a real man).
