flat-assembler

[flat-assembler]

Guys I accidentally locked myself out of my operating system.

[flat-assembler]

The way I got into Linux is hilarious. At least, to me it is.

I've only ever truly used two distros: Linux Mint, and Arch Linux.

Nowadays, I opt for the latter being my main operating system, but I'd rather eat my laptop than try to set Arch up for what would probably be the fifteenth time.

I digress. I had this old laptop with Windows Vista on it. That thing could've killed someone. It probably did.

So me, as the rather naïve beginner to computers I was at the time, just shoved a flash drive in there and hoped it would work better on a new OS.

I did this on perhaps a dozen distros of Linux, but for some reason the only one that actually worked was Linux Mint: Cinnamon Edition.

Quite frankly, I hated LMCE. Yes, it worked better than the Vista that was on there before, but by god, not only was it still so slow, but the interface just felt so uncanny to me.

Somewhere along this path, I heard of Arch Linux. I had been told it was about as good of performance as you could get, since you had to build the system to be whatever you wanted it to be.

Funny enough, I couldn't ever even get into the bootable USB of Arch. Even after tinkering with the BIOS settings, that old laptop just didn't like Arch.

So anyway I tore the laptop apart and trashed its ancient case.

A bit later, I found a somewhat newer desktop that originally ran Windows 10. It probably shouldn't have, seeing as the system was going haywire everytime I turned it on.

So I tried the Arch Linux boot on that, and it worked.

Three days, and a collective maybe 12 hours of work later, I got a basic KDE Plasma install on my Arch Linux system.

Nowadays I can do an Arch Linux install in like 15 minutes. I'd do it faster, but I still fear missing a step, so I recheck everything I do multiple times.

Eventually I put Arch on my main laptop because I found it to be a better experience than Windows.

So yeah, I've basically never dealt with any Linux distro for an extended period of time other than Arch. That Linux Mint time lasted for all of maybe a week, in which I could not for the life of me get the old machine to open a terminal in less than a good 30 seconds.

[flat-assembler]

I would like to clarify that I'm not necessarily trying to undermine the importance GNU as a whole. I'm just trying to undermine the needlessly pretentious way people try to force the name "GNU/Linux".

I also realize you are not looking to cause any argument—I am not either—but I would like to provide some thinking points.

I agree with you. The same of what I said about Linux may be said about GNU. In face, one could argue we could have them as separate groups. Linux distros, then GNU distros, rather than categorizing them all as one.

This however, poses a problem for distros that actually use both. Is it a Linux distro? Is it a GNU distro? According to our aforementioned theoretical nomenclature, it can't be both—that would ruin the simplicity of it.

I don't think there's a perfect solution, but as I said before, I feel that the name "GNU/Linux" is pretentious and forced, whereas the name "Linux" is not only easier to say, but is far more recognizable.

In the case of the average consumer—that is, in this context, someone who is not tech-savvy—you'll usually be a Windows user. If they've heard of any other operating systems, those are almost always "macOS" and "Linux".

Does this individual know what either macOS or Linux are? Probably not. But that triad of operating systems is what they know. They're unlikely to have ever heard of GNU, and would only be even more confused to hear "GNU/Linux".

Obviously my example is a generalization and doesn't apply to everyone, but I feel it is still considerably relevant. If for no other reason at all, Linux is Linux because that is what the majority of computer users know it as.

I find the people who get so livid when you don't say "GNU/Linux" hilarious.

The argument is that Linux is just a kernel, not the OS. In terms of parts of a car, it's said Linux is the engine and GNU is the wheels.

I make a counterargument though. Of what we consider to be Linux distros, not all of them utilize GNU packages. In fact, if I remember correctly, many are moving away from that.

Technically speaking, all the distros are each their own OS. But regardless of difference in any other tools used to make each OS, the one consistent common factor between all of the distros is the Linux kernel.

In other words, to be what we call a Linux distro, you need the Linux kernel, but you don't need GNU packages.

Ergo, it's Linux. It has always been Linux. It always will be Linux. It will never be GNU/Linux for the simple lack of need for GNU.

[flat-assembler]

I find the people who get so livid when you don't say "GNU/Linux" hilarious.

The argument is that Linux is just a kernel, not the OS. In terms of parts of a car, it's said Linux is the engine and GNU is the wheels.

I make a counterargument though. Of what we consider to be Linux distros, not all of them utilize GNU packages. In fact, if I remember correctly, many are moving away from that.

Technically speaking, all the distros are each their own OS. But regardless of difference in any other tools used to make each OS, the one consistent common factor between all of the distros is the Linux kernel.

In other words, to be what we call a Linux distro, you need the Linux kernel, but you don't need GNU packages.

Ergo, it's Linux. It has always been Linux. It always will be Linux. It will never be GNU/Linux for the simple lack of need for GNU.

[flat-assembler]

Formatting in Assembly.

If it's not obvious by now, you should always have a specific goal in mind when programming. This comes in the form of your output file.

This is determined by a "format" option you write at the top of your code.

A common example for Linux:

format ELF64 executable 3

Let's analyze this.

format - Self-explanatory. This tells FASM to look at the following arguments to decide what the output file should look like.

ELF64 - This is the output format itself. For those unaware, ELF stands for Executable Linkable Format. For the sake of our understanding, this is essentially Linux's equivalent of the Windows executable (.exe) format. More on this later, but for now just know it's the output file format. The 64 at the end makes the output 64-bit, allowing us to utilize the 64-bit registers.

executable - This term ensures that the output ELF64 file will work as an executable application that actually executes code when you open it.

3 - This is the version of the Linux ABI. Remember the System V ABI I mentioned in one of the previous posts? Essentially the 3 just tells FASM what version of the ABI we want to use. 3 is the newest version.

For those vitally interested, this is a fair equivalent for Windows:

format PE64 GUI 5.0

format is the same as in the Linux example.

PE64 - PE stands for Portable Executable. This may be understood as a container format. For our sake, a PE file can be either a .exe or a .dll file. It's a little strange, but understandable. The 64 does the same here as in the Linux example.

GUI - Windows is a little different when it comes to the second argument. PE files are always executable, so unlike in Linux, we don't need to explicitly declare that. However, also unlike in Linux, we have to declare what type of PE file we want. The three types we need to think about are CONSOLE, GUI, and DLL. I won't get into DLL (I don't actually know how DLLs work), but CONSOLE essentially tells FASM to make the executable run in the console. This is essential for text-based .exe files. GUI does the exact opposite: it ensures the console is not opened, under the assumption the .exe file will run in a graphical program window.

5.0 - Similar to in Linux, this tells FASM what version of Windows to compile for. In an inverse to Linux however, we want the earliest version to ensure the greatest compatability. 5.0 refers to Windows 2000 and later. PE files that are not 64-bit can run earlier versions, but we will not be covering that.

[flat-assembler]

My blog is intended to be a mix of satire writings and information for FASM.

This information is aimed toward developers who are new or unfamiliar with these concepts and find it daunting.

If it truly bothers you that I'm trying to help people who don't know where to start, or if it bothers you that I try to use sardonic humor, then just ignore me.

Better yet, block me. It's better that way so programming gods like you won't have to worry about being disturbed by insolent scum like me.

Perhaps, in the months to come, you will garner enough of the Assembly language from me to program in it.

But remember, I expect you to have some previous knowledge on my discussions.

Research and ask questions, my children. Do not be idiots.

[flat-assembler]

Some information on the "Assemblies".

You've probably seen me mention FASM. Or not. Regardless, it's an important name.

FASM stands for flat assembler (intentionally with lowercase letters. idk why).

Likewise, other Assemblers exist. Popular onces also include NASM, YASM, and MASM. Feel free to look these up on your own time.

We stick with FASM because its output is generally faster and takes up less space than the other Assemblers.

Now, to explain the Assemblers. Each Assembler uses its own syntax to compile inputted code into the result—usually an executable. Assembly code written for FASM generally does not work with the other Assemblers, and likewise the rest are generally not interchangeable.

Thus, in a sense, it may feel like there are multiple Assemblies. Now, to say this would not be inaccurate, but it's also not correct in the way you would think.

Like I said, the differences between the Assemblers listed above are in syntax. But ultimately, all of them follow the same Assembly language.

This is sometimes called x86 Assembly when referring to 32-bit compatable code, but for our purposes, we call it x86-64 Assembly because we want to utilize the 64-bit registers that are present in nearly every modern personal computer.

x86-64 Assembly is only one of many Assembly languages. For the common developer following along however, it is not necessary to cover any other form.

In addition to the type of Assembly language and the Assembler's syntax, another thing to take into consideration is the operating system calling conventions.

There are only two conventions I consider important in the context of FASM: System V ABI, and Windows x64 ABI.

System V ABI is the convention I will almost always refer to on this blog. It covers both Linux and macOS (with minimal nuanced differences between the two).

As the name implies, Windows x64 ABI is for Windows. However, Windows is more confusing because, unlike System V ABI which remains constant on all versions of Linux, Windows x64 ABI will change between major Windows versions, such as Windows 10 to Windows 11.

Sorry, that's an information overload, but if nothing else, remember this: FASM uses x86-64 Assembly, and this blog will cover Linux (System V ABI) convention for FASM.

[flat-assembler]

Wouldn't you like to know?

Procedural programmers are the only true programmers.

Perhaps you object oriented programmers may be able to imitate a fraction of the power of Assembly and C programmers

but can you ever truly be proud of your training-wheel programming?

Not with us procedurals breathing down your neck.

[flat-assembler]

Functions in Assembly. Sort of.

So in FASM we can use labels to differentiate sections of code. For a bit of background information, we use the following to determine the first section of code that is run when the program executes:

entry main

main:

; your code here

But we can also add more labels to work as functions. Consider the following:

main:

call write

mov rax, 60 ; sets the function to exit

mov rdi, 0 ; equivalent of "returns 0"

syscall ; initiates function

write:

mov rax, 1 ; set to write function

mov rdi, 1 ; set to stdout

lea rsi, [msg] ; set string (from earlier post)

mov rdx, 14 ; set string length

syscall ; initiates function

It looks a little complex, but just take a minute, look through it, and you should see what it's doing.

Using this notation is actually very helpful if you know what you're doing, because it makes your processes easier to understand.

Now, for those of you who have been catching on very well, I have a task for you. Answer this:

How would you write a "write" function so that, when you call it in your main function, it can print varying strings and string lengths based on the most recently declared rsi and rdx values?

Your hints are that the arguments (rdi, rsi, rdx) and rax may be declared in any order, and rsi and rdx may not be declared within the write function.

[flat-assembler]

Seriously what is going on with Python?

Who looks at that dumpster fire of a language and says "This will do." Not only is that monstrosity slow, it just has too much to work with.

I will stick with my simple functions and manageable external libraries here at Assembly.

Python users watch in terror as us Assembly users create the same programs as them, but ours are so efficient they can run on a potato.

We basically strangle them with our hundreds of lines of code. How does it feel being dominated in performance capabilities, Python? Are you proud of yourself?

[flat-assembler]

can you make more degradation posts like you did for OOP programmers? no reason

Not entirely sure what you mean by degradation posts, but I did put extra detail into the OOP programming insults, so I'll keep that in mind next time I feel like shaming part of the computer science community.

[flat-assembler]

Perhaps, in the months to come, you will garner enough of the Assembly language from me to program in it.

But remember, I expect you to have some previous knowledge on my discussions.

Research and ask questions, my children. Do not be idiots.

[flat-assembler]

Procedural programmers are the only true programmers.

Perhaps you object oriented programmers may be able to imitate a fraction of the power of Assembly and C programmers

but can you ever truly be proud of your training-wheel programming?

Not with us procedurals breathing down your neck.

[flat-assembler]

"Maybe Windows isn't so bad,"

I say, sobbing as Microsoft increases the requirements for Windows 11 to 48 pettabytes of RAM, a quantum CPU, and a nuclear power plant worth of electricity

just to force me to run Copilot against my will.

I hate Copilot. Long live Clippy.

[flat-assembler]

A bit of actual Assembly knowledge for once. Let's cover some basic operations.

In C, to print something, you say:

printf("Hello, World!");

One argument. Very simple. Very understandable.

But it's not so easy in Assembly, is it?

Here's what the same looks like in Assembly, assuming you've properly declared a string called msg, and you're using Linux syntax (Assembly is formatted different between operating systems. I recommend Linux because it makes the most sense for developers).

mov rax, 1

mov rdi, 1

lea rsi, [msg]

mov rdx, 14

syscall

What's going on here?

Well, there are four parts to a simple print statement in Assembly. Each are put into place by registers in your CPU. rax, for example, is one of these registers.

We use mov to move values into the register. Notice that the syntax is: opcode destination, source

- rax holds the number for your function. In this case, 1 is used for print. (Full list of function numbers here)

- rdi holds the first argument in your function (arg0), which is 1 for standard output (stdout). For comparison, 0 is standard input (stdin)

- rsi (arg1) holds the actual text from the string. We use lea (load effective address) instead of mov, because if we used mov, we would get the memory address (location) of msg rather than the value of msg.

- rdx (arg2) holds the number of characters you want to print. There are 13 chars in our string msg: (Hello, World!). Thus, we allocate 14 characters, so we may also include a null character which says where to end the string.

- syscall basically just tells the computer to activate the function you have set up. Without it, you're just moving arbitrary values for no reason.

I know I know, it's a lot. But there is value in learning this language. Assembly runs way faster and uses much less space than higher level languages like C.

In my own experience, hello world code comes out to be about 15 kilobytes in C, but only about 200 bytes in Assembly. You read that right. Bytes. Without a kilo, mega or giga.

[flat-assembler]

If you use Windows, you're a nerd.

If you use Linux, you're also a nerd.

But if you use macOS, you are a disgrace to everything that is holy, and you'd better not forget that.

[flat-assembler]

I realized that Assembly is actually terrifying.

It's not that bad though... if you enjoy pain.

C programmers, be glad your code is portable.

Enjoy your happiness.

We don't know what that is here.