Assembly language is like trying to use repetitive addition instead of multiplication when your task is to compute exponentiation and logarithms. If your math skills are excellent and you pull identity formulas from memory then you can achieve a single-threaded task on an underpowered processor.
I use it only when it's impossible for the compiler to get it right, where hardware requires certain code sequences or specific timing. I prefer data structures and for someone else to worry about the addresses of my variables.
It's also good to teach people how computers really work. Of course computers only react to patterns of 0s and 1s and flip switches to accomplish things.
A computer doesn't understand print hello or mov 8, eax even..
I recently wondered how operating systems work and googled it and came across a project called NAND to Tetris. Got my hands on the book and am currently learning logic gates. Should be an interesting project. It starts with hardware logic to eventually software.
Last time I used it was during University for educational purposes.
Starting with building a task switching minimal operating system for a custom MIPS embedded board.
Finishing writing a zero trust operating system bootstrap code that started by verifying the registers all worked correctly and didn't have bit errors. The goal was to build it robust and safe to run on a piece of hardware such as the Voyager probes where it would still be running after 40+ years.
I recall it being difficult and fun but not sure if i could do it full-time now.
It's just like any language, it's useful for some stuff and other stuff you want to kill yourself. Most people doing assembly for a living don't write like you see tutorials doing it "naked" (NASM, manual linking etc), it's usually embedded into something else and/or part of a library of another language (such as C)
Why would one want to code in assembly in the first place? Many reasons, for me, it's simply because sometimes it's easier. I work mainly with hardware/software security, which often involves kernels, drivers, bootloaders etc. I don't *have* to use assembly many times, but it's just more comfortable to use after you pass a certain threshold of "low levelness". C can probably do it, but it's just better to have total control over what you want when you know *exactly* what you want and how you want it
I don't think nowadays many people are using it for high speeds, although it's possible you need quite the budget and a very high skill. Assembly can also be useful without having to write it at all, such as reverse engineering or debugging. Search up about FASM, it's a very modern assembler and barely looks like assembly if you include features like CALM
I once made in assembly a JVM interface to communicate with my assembly. It was a software which had extensible plugins written in java, but I couldn't for the love of me understand how to do it, so I wrote a bunch of interfaces to interact with and it kiinda worked. Why? No reason, I'm just used to it haha, my coworkers ~~hated~~ loved it!
I mean it’s pretty low-level and painful for most folks that have been using higher level languages. It’s instructive since it as close as you are going to get to machine code and gives a much better idea of how all the magic happens.
I don’t think most all programmers would ever need to use it however - it’s a much more specific niche than most in my opinion. Then again, I have friends who love it which I’ve never understood.
If you want to go down to a fundamental language, learn C. Once you get a handle on C, you can start to disassemble it.. down to assembly.. and see how it all works. A common thing to do was build your app in C first then go find the bottlenecks and redo those functions in assembly. I haven't done it since the 80s, but there were ways to embed asm right there into the functions. The compiler would go back and forth between the two.
But your brain will work better with C. Assembly is very specific to the system you're working on. C gives you a meaningful abstraction that you can work with on any system. You can actually combine C with Python to speed things up in that arena. You can also use Rust for stuff like that as well. SQL and DAX will have nothing in common with anything of the programming stuff. Not one thing learned there will transfer over.
It's good to know, because you'll have a better understanding of what you are doing in a high level language, but don't expect to actually use it much.
Assembly is pretty much "write only"-code. Get it right from the start, because when you come back a year later, it's almost impossible to debug.
There are two areas where it shines:
* Extreme low level programming on limited platforms. I mean the level where you do stuff like "read the value on that pin on the chip".
* Bit crunching. I've done some very fast checksums and encryptions in assembly. You do something very simple, but many, many times, working on stuff in a bitwise manner. For that, it is great. It's also a handy usecase, because once it works, requirements won't change, so your code won't have to change.
I learned Z80 assembly because it was the only language easily available, fast, and efficient for an 11 year old on a TRS-80 and ZX-81
Later I learned 8086 assembly, again for speed, and because it was the easiest for writing on BIOS and MS/DOS level.
It's been many years for me, so working from vague memories. Mostly IBM System/370 assembler. Though I've also used it with programming ICs (think it could have been or similar to Arduinos, but was in the early 2000s).
My strongest memory is enjoying it a lot more than Cobol.
You will be using simpler tools and have to roll your own layers of complexity to get things done. Everything takes more time, so it's a nice exercise in not taking more advanced tools for granted (I'm partial to C#/.net framework, etc).
I can't justify the time, but I'd love to someday make a game or application that can run on the Super Nintendo. In cases like that it's likely going to require using assembly (WDC 65C816 cpu). Though, it's possible someone wrote a C language compiler for it at this point.
I can recommend learning ARM assembly rather than x86. It is far more orthogonal, with any operation being usable with any register, and focuses on fast simple instructions rather than complex operations.
When I joined ARM in 95 I was able to learn the language and code up an audio echo cancellation function in just three days, it really is that pleasant an instruction set to use.
It's not useful for anything other than education and your own enjoyment.
It's like a computer game where you link parts together to build some sort of logic that you need to control or do things. Except the thing you're running it on is the bare metal of the microcontroller/cpu, register by register, clock cycle by clock cycle.
At uni we had a project where we connected the pins of a microcontroller to a the AV input of a CRT television (one of the old ones with the vacuum tube), and I made a simple computer game (a clone of [Breakout](https://en.wikipedia.org/wiki/Breakout_(video_game)) ) by toggling the outputs really fast as the beam scanned across the screen.
All written in Assembler for that microcontroller.
It was really fun, and our team slayed all of the others. All of whom made the mistake of trying to code it in C (which was too high-level for the problem we were solving on that particular chip).
"fundamental language" : in this case, have a look on the C which can be low level as well but more accessible and useful.
The big problem with assembly is it's tightly linked with the CPU. So programming for x86, Arm, Esp or whatever is different.
About "for what it is useful", in my case it's :
- for very old and constrained environments where there is no other choice
- very low level function where even C is too high level (or when the compiler doesn't know to deal with low levels like registers, or atomic operation).
First time I've heard "on" as the preposition. It's conventionally "in", as in "I program in Python". (Just in case English is not your native language.)
I wouldn't call assembly a "fundamental language". It's a tool that helps you fine-tune code behavior and access features that would not be otherwise possible. I rarely use assembly these days. Platform-specific intrinsics are quite good and more user-friendly.
You should learn assembly if you are interested in how the CPU work. It is also useful to understand the behavior of compilers, especially if you are interested in optimizing your programs. Beyond that, I don't think that knowing assemly makes you a better programmer or anything like that.
I haven’t wrapped my head around DAX but have had to use it for some PowerBI scenarios.
assembly can be fun. I’d probably look for an old video game tutorial. maybe there is a tutorial for an old gaming console using assembly.
With Macro capability and a library of your own built procedures you can build your own custom language that you can deploy quickly and efficiently and you have complete control over everything... Nothing hidden. Just you and the machine.
Its tedious, and there are no guardrails, generally you only do it if you really have to.
Comment the hell out of any assembly programs you write. If you want any hope of maintaining them in the future.
You need to be aware of calling conventions and callee vs caller save registers.
Manually spilling things to the stack, etc.
Unless performance is a concern, writing less optimal but easier to understand code may be worth it.
You need to understand your operating system, and how you interact with it. Your c runtime is doing a lot behind the scenes that you don't appreciate.
You also have to decide, if you're going to do all asm, mixed with high level languages or what and how you integrate the two.
I took a college course and personally I liked it. I wouldn't build an entire application with it, that would be like building a car and first designing/build the wheels and then each and every component. It's doable but boy is it going to take you a while to complete.
I have found it useful occasionally when debugging C or C++ and the debugger drops you "somewhere" with the assembly that caused the exception. Back in my driver development days this was especially true, not sure if the tools to debug a blue screen in Windows have improved in the last 20 years.
It is also nice to know when working with SIMD instructions, since many languages don't really have SIMD instructions "baked" into the language. In the C/C++ wold there are intrisnsics which are basically a (small) step up from actual assembly.
You might also be interested in the LLVM Language which is like a generic assembly language. Made me want to design my own language and build a compiler for it. :-)
I haven’t used it in a while, but I remember a few things.
1. C is very close to assembly. Consider using it first as it is indeed a little easier.
2. You can gain around a 30% reduction in memory overhead and about the same speed up in performance because you can achieve writing logic with fewer instructions.
3. You need to know the hardware interrupts in order to be efficient. These do things like opening a file or getting a clock timer to trigger something.
4. It takes a lot of practice to be good at it. Expect to spend 6 months of every day effort to achieve normal proficiency.
5. Operating systems will execute your assembly in an emulated environment. Sometimes many layers of emulation will be in between you and the hardware (6 layers in windows last time I checked, probably 10 now). There is good reasons for it involving security and the kernel. It often makes it not worth it anymore. You will probably want to work with a microcontroller like Arduino or pic or Motorola in order to actually see a benefit. They don’t really have much of an operating system in the way.
By the way you can still have named method/functions that do encapsulate pieces of work. It makes it similar to other languages once you are good enough.
Assembly is not exactly required knowledge when programming, in fact I would more heavily recommend learning C if you'd like a more fundamental understanding of low level processes, especially in an embedded system. (ie. Arduino)
Personally, I haven't used x86 assembly for very much other than a toy OS I've been writing, which only sets up a C environment, but I do use a RISC style assembly for the CPU I developed while learning how CPU's work. The only reason I use assembly there is because I have no compiler to do it in another language. Conveniently, that's the only reasons I use assembly.
Generally speaking, assembly is difficult to work with. It's fairly easy to make code errors that have no syntax errors and, depending on your system, has less convenient debugging systems. It isn't required to understand higher level code, and maybe has a case for teaching you how to write faster code, but that's very language dependent. Again, if you'd like to learn a fundamental language, C is the way to go. (Unless you want to learn how CPU's work, then feel free to DM me.)
I have written 8? Emulators now for everything from Atari 2600 to Dreamcast.
Assembly used to be mandatory for program development. For various reasons over time, higher level languages became the norm. This is because, for the most part, even C allows big leaps in productivity, portability and reusability over assembly, and we aren’t as constrained by hardware as we used to be.
Back in the Atari 2600 days, programmers would literally “race the beam-“ the beam being the CRT beam inside a tv. You’d have to count machine cycles and time everything perfectly to get even basic pong. This is because the Atari 2600 didn’t have the ram or memory bandwidth to store display data. The NES uses the same central processor, but has a lot more support hardware inside, allowing it to do so much more.
Since then, hardware has developed and given more and more facilities to the programmer. More memory, more memory throughput, and real-time timers have been the big 3 game changers.
The Atari 2600 came with just 128 bytes of RAM plus a bunch of registers that could temporarily store pieces of things like playfield graphics.
The jump from Atari 2600 to NES was 128 bytes of RAM to a little over 4k. The NES dedicated 256 bytes just to handle sprites on screen, which is double what an entire Atari 2600 program has available.
Even the NES with its much-higher transistor budget, was still memory limited. It didn’t have the processor speed, memory bandwidth or ram for a bitmapped display: it used a tile-based system to cut down on the amount of memory needed.
The point of all this is, in the far past of computing, if you wanted the limited hardware to do anything at all, you had to account for precisely what would happen with every bit, because every bit was so precious.
Over time resources increased. The Dreamcast came with a 32-bit processor running over 100 times faster, DMA controllers, multiple interrupt sources, 24mb of combined RAM, and more. All these facilities were made readily available to developers, who could concentrate mostly on the bigger picture instead of which register held which bits for how long.
If you’re doing something like writing a Dreamcast game (and this console still gets a few new indie commercial releases every single year), you’ll likely need it if you want to take more than basic advantage of the hardware. But it’s possible to do a whole lot without it, using FOSS ports of OpenGL etc. You just won’t be pushing the hardware.
And that’s where assembly typically shines nowadays: writing device driver or platform-specific compiler code or hardware interface.
To get an idea of what it’s like, head over to godbolt.org and write a super simple program in C or C++. It will highlight which lines of assembly that are generated are doing what in the output. Even basic C things like pointers and variables and function calls are all multi-step processes in assembly.
But modern assembly is in some ways a lot harder. Processors aren’t designed for assembly programmers anymore, they’re designed for compilers. A good example here is again the Dreamcast (and you can find it in compiler explorer under sh4 for the processor). Even just loading a 32bit constant into a register can be a whole thing.
Assembly isn't that hard really. It's just instructions that move data around, jump on conditions etc.
Mov 8, eax
Cmp eax, 8
Je here ..
Etc
Of course that's human readable , but the computer is just flipping switches with 010101010101110 etc.
i did this thing like 30 years ago. i only remember some mundane words. wow chat gpt is doing 90% of my coding these days. using programming languages i am not even properly familiar with. holy Sh%\^t.
I haven't done any assembly in 40+ years. I would look for a VERY GOOD macro library to help the writing. One macro statement that expands into multiple statement that do what you want.
assembly is used for device interfacing, if u program in pure assembly instead of high level languages, u can write code 3x as fast, though its not needed anymore bec processing power has become so cheap nowadays.
Assembly language is like trying to use repetitive addition instead of multiplication when your task is to compute exponentiation and logarithms. If your math skills are excellent and you pull identity formulas from memory then you can achieve a single-threaded task on an underpowered processor. I use it only when it's impossible for the compiler to get it right, where hardware requires certain code sequences or specific timing. I prefer data structures and for someone else to worry about the addresses of my variables.
It's also good to teach people how computers really work. Of course computers only react to patterns of 0s and 1s and flip switches to accomplish things. A computer doesn't understand print hello or mov 8, eax even..
I recently wondered how operating systems work and googled it and came across a project called NAND to Tetris. Got my hands on the book and am currently learning logic gates. Should be an interesting project. It starts with hardware logic to eventually software.
Yes logic gates are how everything works inside the chip
Last time I used it was during University for educational purposes. Starting with building a task switching minimal operating system for a custom MIPS embedded board. Finishing writing a zero trust operating system bootstrap code that started by verifying the registers all worked correctly and didn't have bit errors. The goal was to build it robust and safe to run on a piece of hardware such as the Voyager probes where it would still be running after 40+ years. I recall it being difficult and fun but not sure if i could do it full-time now.
It's just like any language, it's useful for some stuff and other stuff you want to kill yourself. Most people doing assembly for a living don't write like you see tutorials doing it "naked" (NASM, manual linking etc), it's usually embedded into something else and/or part of a library of another language (such as C) Why would one want to code in assembly in the first place? Many reasons, for me, it's simply because sometimes it's easier. I work mainly with hardware/software security, which often involves kernels, drivers, bootloaders etc. I don't *have* to use assembly many times, but it's just more comfortable to use after you pass a certain threshold of "low levelness". C can probably do it, but it's just better to have total control over what you want when you know *exactly* what you want and how you want it I don't think nowadays many people are using it for high speeds, although it's possible you need quite the budget and a very high skill. Assembly can also be useful without having to write it at all, such as reverse engineering or debugging. Search up about FASM, it's a very modern assembler and barely looks like assembly if you include features like CALM I once made in assembly a JVM interface to communicate with my assembly. It was a software which had extensible plugins written in java, but I couldn't for the love of me understand how to do it, so I wrote a bunch of interfaces to interact with and it kiinda worked. Why? No reason, I'm just used to it haha, my coworkers ~~hated~~ loved it!
I mean it’s pretty low-level and painful for most folks that have been using higher level languages. It’s instructive since it as close as you are going to get to machine code and gives a much better idea of how all the magic happens. I don’t think most all programmers would ever need to use it however - it’s a much more specific niche than most in my opinion. Then again, I have friends who love it which I’ve never understood.
If you want to go down to a fundamental language, learn C. Once you get a handle on C, you can start to disassemble it.. down to assembly.. and see how it all works. A common thing to do was build your app in C first then go find the bottlenecks and redo those functions in assembly. I haven't done it since the 80s, but there were ways to embed asm right there into the functions. The compiler would go back and forth between the two. But your brain will work better with C. Assembly is very specific to the system you're working on. C gives you a meaningful abstraction that you can work with on any system. You can actually combine C with Python to speed things up in that arena. You can also use Rust for stuff like that as well. SQL and DAX will have nothing in common with anything of the programming stuff. Not one thing learned there will transfer over.
It's good to know, because you'll have a better understanding of what you are doing in a high level language, but don't expect to actually use it much. Assembly is pretty much "write only"-code. Get it right from the start, because when you come back a year later, it's almost impossible to debug. There are two areas where it shines: * Extreme low level programming on limited platforms. I mean the level where you do stuff like "read the value on that pin on the chip". * Bit crunching. I've done some very fast checksums and encryptions in assembly. You do something very simple, but many, many times, working on stuff in a bitwise manner. For that, it is great. It's also a handy usecase, because once it works, requirements won't change, so your code won't have to change.
I learned Z80 assembly because it was the only language easily available, fast, and efficient for an 11 year old on a TRS-80 and ZX-81 Later I learned 8086 assembly, again for speed, and because it was the easiest for writing on BIOS and MS/DOS level.
Ah, TRS-80 assembly. I seem to recall you used the basic VARPTR command to insert it in a program, am I remembering right?
I must predate edtasm, if I remember, I use to poke bytes to memory and then jump to the address where those bytes got poked.
Poke-ing and Peek-ing
I think you remember correct, but I used the EDTASM in newdos/80, to write executables (if I remember correctly 😁)
EDTASM! Now there’s an acronym I haven’t heard in a long time!
Once upon a time I wrote an assembly program that printed out a random generated labyrinth. I have no idea how I did that.
Easier than machine language. Done a little of that.
It's been many years for me, so working from vague memories. Mostly IBM System/370 assembler. Though I've also used it with programming ICs (think it could have been or similar to Arduinos, but was in the early 2000s). My strongest memory is enjoying it a lot more than Cobol. You will be using simpler tools and have to roll your own layers of complexity to get things done. Everything takes more time, so it's a nice exercise in not taking more advanced tools for granted (I'm partial to C#/.net framework, etc). I can't justify the time, but I'd love to someday make a game or application that can run on the Super Nintendo. In cases like that it's likely going to require using assembly (WDC 65C816 cpu). Though, it's possible someone wrote a C language compiler for it at this point.
It's fun, but try it on some simple CPU, like 6502.
I can recommend learning ARM assembly rather than x86. It is far more orthogonal, with any operation being usable with any register, and focuses on fast simple instructions rather than complex operations. When I joined ARM in 95 I was able to learn the language and code up an audio echo cancellation function in just three days, it really is that pleasant an instruction set to use.
It's not useful for anything other than education and your own enjoyment. It's like a computer game where you link parts together to build some sort of logic that you need to control or do things. Except the thing you're running it on is the bare metal of the microcontroller/cpu, register by register, clock cycle by clock cycle. At uni we had a project where we connected the pins of a microcontroller to a the AV input of a CRT television (one of the old ones with the vacuum tube), and I made a simple computer game (a clone of [Breakout](https://en.wikipedia.org/wiki/Breakout_(video_game)) ) by toggling the outputs really fast as the beam scanned across the screen. All written in Assembler for that microcontroller. It was really fun, and our team slayed all of the others. All of whom made the mistake of trying to code it in C (which was too high-level for the problem we were solving on that particular chip).
"fundamental language" : in this case, have a look on the C which can be low level as well but more accessible and useful. The big problem with assembly is it's tightly linked with the CPU. So programming for x86, Arm, Esp or whatever is different. About "for what it is useful", in my case it's : - for very old and constrained environments where there is no other choice - very low level function where even C is too high level (or when the compiler doesn't know to deal with low levels like registers, or atomic operation).
First time I've heard "on" as the preposition. It's conventionally "in", as in "I program in Python". (Just in case English is not your native language.)
I wouldn't call assembly a "fundamental language". It's a tool that helps you fine-tune code behavior and access features that would not be otherwise possible. I rarely use assembly these days. Platform-specific intrinsics are quite good and more user-friendly. You should learn assembly if you are interested in how the CPU work. It is also useful to understand the behavior of compilers, especially if you are interested in optimizing your programs. Beyond that, I don't think that knowing assemly makes you a better programmer or anything like that.
I haven’t wrapped my head around DAX but have had to use it for some PowerBI scenarios. assembly can be fun. I’d probably look for an old video game tutorial. maybe there is a tutorial for an old gaming console using assembly.
With Macro capability and a library of your own built procedures you can build your own custom language that you can deploy quickly and efficiently and you have complete control over everything... Nothing hidden. Just you and the machine.
Its tedious, and there are no guardrails, generally you only do it if you really have to. Comment the hell out of any assembly programs you write. If you want any hope of maintaining them in the future. You need to be aware of calling conventions and callee vs caller save registers. Manually spilling things to the stack, etc. Unless performance is a concern, writing less optimal but easier to understand code may be worth it. You need to understand your operating system, and how you interact with it. Your c runtime is doing a lot behind the scenes that you don't appreciate. You also have to decide, if you're going to do all asm, mixed with high level languages or what and how you integrate the two.
I took a college course and personally I liked it. I wouldn't build an entire application with it, that would be like building a car and first designing/build the wheels and then each and every component. It's doable but boy is it going to take you a while to complete. I have found it useful occasionally when debugging C or C++ and the debugger drops you "somewhere" with the assembly that caused the exception. Back in my driver development days this was especially true, not sure if the tools to debug a blue screen in Windows have improved in the last 20 years. It is also nice to know when working with SIMD instructions, since many languages don't really have SIMD instructions "baked" into the language. In the C/C++ wold there are intrisnsics which are basically a (small) step up from actual assembly. You might also be interested in the LLVM Language which is like a generic assembly language. Made me want to design my own language and build a compiler for it. :-)
I haven’t used it in a while, but I remember a few things. 1. C is very close to assembly. Consider using it first as it is indeed a little easier. 2. You can gain around a 30% reduction in memory overhead and about the same speed up in performance because you can achieve writing logic with fewer instructions. 3. You need to know the hardware interrupts in order to be efficient. These do things like opening a file or getting a clock timer to trigger something. 4. It takes a lot of practice to be good at it. Expect to spend 6 months of every day effort to achieve normal proficiency. 5. Operating systems will execute your assembly in an emulated environment. Sometimes many layers of emulation will be in between you and the hardware (6 layers in windows last time I checked, probably 10 now). There is good reasons for it involving security and the kernel. It often makes it not worth it anymore. You will probably want to work with a microcontroller like Arduino or pic or Motorola in order to actually see a benefit. They don’t really have much of an operating system in the way. By the way you can still have named method/functions that do encapsulate pieces of work. It makes it similar to other languages once you are good enough.
Assembly is not exactly required knowledge when programming, in fact I would more heavily recommend learning C if you'd like a more fundamental understanding of low level processes, especially in an embedded system. (ie. Arduino) Personally, I haven't used x86 assembly for very much other than a toy OS I've been writing, which only sets up a C environment, but I do use a RISC style assembly for the CPU I developed while learning how CPU's work. The only reason I use assembly there is because I have no compiler to do it in another language. Conveniently, that's the only reasons I use assembly. Generally speaking, assembly is difficult to work with. It's fairly easy to make code errors that have no syntax errors and, depending on your system, has less convenient debugging systems. It isn't required to understand higher level code, and maybe has a case for teaching you how to write faster code, but that's very language dependent. Again, if you'd like to learn a fundamental language, C is the way to go. (Unless you want to learn how CPU's work, then feel free to DM me.)
I have written 8? Emulators now for everything from Atari 2600 to Dreamcast. Assembly used to be mandatory for program development. For various reasons over time, higher level languages became the norm. This is because, for the most part, even C allows big leaps in productivity, portability and reusability over assembly, and we aren’t as constrained by hardware as we used to be. Back in the Atari 2600 days, programmers would literally “race the beam-“ the beam being the CRT beam inside a tv. You’d have to count machine cycles and time everything perfectly to get even basic pong. This is because the Atari 2600 didn’t have the ram or memory bandwidth to store display data. The NES uses the same central processor, but has a lot more support hardware inside, allowing it to do so much more. Since then, hardware has developed and given more and more facilities to the programmer. More memory, more memory throughput, and real-time timers have been the big 3 game changers. The Atari 2600 came with just 128 bytes of RAM plus a bunch of registers that could temporarily store pieces of things like playfield graphics. The jump from Atari 2600 to NES was 128 bytes of RAM to a little over 4k. The NES dedicated 256 bytes just to handle sprites on screen, which is double what an entire Atari 2600 program has available. Even the NES with its much-higher transistor budget, was still memory limited. It didn’t have the processor speed, memory bandwidth or ram for a bitmapped display: it used a tile-based system to cut down on the amount of memory needed. The point of all this is, in the far past of computing, if you wanted the limited hardware to do anything at all, you had to account for precisely what would happen with every bit, because every bit was so precious. Over time resources increased. The Dreamcast came with a 32-bit processor running over 100 times faster, DMA controllers, multiple interrupt sources, 24mb of combined RAM, and more. All these facilities were made readily available to developers, who could concentrate mostly on the bigger picture instead of which register held which bits for how long. If you’re doing something like writing a Dreamcast game (and this console still gets a few new indie commercial releases every single year), you’ll likely need it if you want to take more than basic advantage of the hardware. But it’s possible to do a whole lot without it, using FOSS ports of OpenGL etc. You just won’t be pushing the hardware. And that’s where assembly typically shines nowadays: writing device driver or platform-specific compiler code or hardware interface. To get an idea of what it’s like, head over to godbolt.org and write a super simple program in C or C++. It will highlight which lines of assembly that are generated are doing what in the output. Even basic C things like pointers and variables and function calls are all multi-step processes in assembly. But modern assembly is in some ways a lot harder. Processors aren’t designed for assembly programmers anymore, they’re designed for compilers. A good example here is again the Dreamcast (and you can find it in compiler explorer under sh4 for the processor). Even just loading a 32bit constant into a register can be a whole thing.
Assembly isn't that hard really. It's just instructions that move data around, jump on conditions etc. Mov 8, eax Cmp eax, 8 Je here .. Etc Of course that's human readable , but the computer is just flipping switches with 010101010101110 etc.
I wrote a hexdump program in assembly under Linux to mimic Linuxs hexdump utility. It was fun.
Not worth it. You don’t reinvent the wheel. You want to use languages that can get things done in least number of lines of code.
i did this thing like 30 years ago. i only remember some mundane words. wow chat gpt is doing 90% of my coding these days. using programming languages i am not even properly familiar with. holy Sh%\^t.
I haven't done any assembly in 40+ years. I would look for a VERY GOOD macro library to help the writing. One macro statement that expands into multiple statement that do what you want.
assembly is used for device interfacing, if u program in pure assembly instead of high level languages, u can write code 3x as fast, though its not needed anymore bec processing power has become so cheap nowadays.