Assembly: One of those things I keep on trying
-
I previously worked through the book (by one of my favorite tech authors - Jeff Duntemann) x64 Assembly Language Step-by-Step: Programming with Linux[^] There was a lot of build-up to read just to get to the meat. At least 100 pages or so. It was tough & I read a lot. This RISC-V Assembly Book Is Amazing! I recently stumbled upon this new book that I'm reading right now: RISC-V Assembly Language Programming: Unlock the Power of the RISC-V Instruction Set[^] This book : 1. gets right to the point - you start writing Assembly almost immediately. 2. Explains things really clearly -- It has helped me put some ideas together that I've never understood and things seem much more clear. Why Is It Easier? I believe a lot of it is easier because it is bas
Not all assembly languages are created the same. The Intel/CISC machine languages have their roots in the old IBM 360 mainframes. These are complex instruction sets that require a lot of hardware to implement. The newer RISC instruction sets trade some of this hardware complexity for a significantly simpler machine language implementation using a lot more instructions to do the same functions. We've found that the RISC machines generally operate faster and can be optimized in ways that CISC cannot, which is why even the CISC instruction set used by Intel to this day has become more of a macro language on an underlying RISC instruction set that Intel has highly optimized. As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly. It has nothing to do with the actual language. I ran into the same issue when learning Windows programming until I found Charles Petzgold's books. Same language, same OS, but his books were far better at teaching Windows programming.
-
Not all assembly languages are created the same. The Intel/CISC machine languages have their roots in the old IBM 360 mainframes. These are complex instruction sets that require a lot of hardware to implement. The newer RISC instruction sets trade some of this hardware complexity for a significantly simpler machine language implementation using a lot more instructions to do the same functions. We've found that the RISC machines generally operate faster and can be optimized in ways that CISC cannot, which is why even the CISC instruction set used by Intel to this day has become more of a macro language on an underlying RISC instruction set that Intel has highly optimized. As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly. It has nothing to do with the actual language. I ran into the same issue when learning Windows programming until I found Charles Petzgold's books. Same language, same OS, but his books were far better at teaching Windows programming.
obermd wrote:
As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly.
Yeah, it's a balance. I mean, to really learn what's going on underneath the surface, a lot has to be explained. And, since learning Assembly means you need to understand so many concepts (number bases, what hardware is actually doing, tools (compiler, linker, make, etc.)) there can be a lot to learn just to get to where you're learning the target thing. Petzold's books were long and in depth, but I really enjoyed his style and I felt like he was inviting me into a secret club to learn things that few others knew. :)
-
Not all assembly languages are created the same. The Intel/CISC machine languages have their roots in the old IBM 360 mainframes. These are complex instruction sets that require a lot of hardware to implement. The newer RISC instruction sets trade some of this hardware complexity for a significantly simpler machine language implementation using a lot more instructions to do the same functions. We've found that the RISC machines generally operate faster and can be optimized in ways that CISC cannot, which is why even the CISC instruction set used by Intel to this day has become more of a macro language on an underlying RISC instruction set that Intel has highly optimized. As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly. It has nothing to do with the actual language. I ran into the same issue when learning Windows programming until I found Charles Petzgold's books. Same language, same OS, but his books were far better at teaching Windows programming.
-
I previously worked through the book (by one of my favorite tech authors - Jeff Duntemann) x64 Assembly Language Step-by-Step: Programming with Linux[^] There was a lot of build-up to read just to get to the meat. At least 100 pages or so. It was tough & I read a lot. This RISC-V Assembly Book Is Amazing! I recently stumbled upon this new book that I'm reading right now: RISC-V Assembly Language Programming: Unlock the Power of the RISC-V Instruction Set[^] This book : 1. gets right to the point - you start writing Assembly almost immediately. 2. Explains things really clearly -- It has helped me put some ideas together that I've never understood and things seem much more clear. Why Is It Easier? I believe a lot of it is easier because it is bas
If... I do PLC, haven'T touched a uC since college.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
raddevus wrote:
One thing that was very difficult was getting the QEMU RISC-V emulator going.
I gave up. QEMU refused to operate in any of my environments. I tried several guides, and nada. :mad:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Check this out. I was searching everywhere to better understand how those risc-v 64 linux images were created. I finally stumbled upon all the steps you need here[^]. But that was way too much. I was thinking, "Why can't I just download the rv64 images I need?" Finally, I found this link: Debian Quick Image Baker pre-baked images[^] When you go there and you want a Linux image which runs on risc-v 64 which can be virtualized (run in QEMU), you have to pick the link that looks like: "Images for riscv64-virt" The link there ( Images for riscv64-virt[^] ) will automatically download a 331MB file named: 2baed3d2ab30e7a4ff39c7e587c8b16dce3885afb2dc047dae555a8bc13e which is a zip file, but doesn't have a zip file extension. Ok, fine. Well, when you unzip that file, you have everything you need to run the QEMU virtual OS which is Debian which runs on RISC-V. Oh, wow, after 2 days of sitting, staring, reading, searching I finally get it. "Oh, I'm trying to run a virtualized Debian linux which thinks it is running on a RISC-V Processor!" Ohhhhhh.... Man, I'm slow a lot. :rolleyes: The list of files in that zip are: * image.qcow2 -- image file * initrd - linux stuff * kernel - linux kernel * readme.txt - readme provides command line for QEMU * ssh_user_ecdsa_key -- stuff I don't know * ssh_user_ed25519_key -- don't know * ssh_user_rsa_key -- don't know. I think if you follow my steps you may really get your virtual environment finally running. But, of course maybe you don't care because much is different when you run on "real hardware" (ESP32) anyways. đŸ¤“ Just thought I'd share this with someone else who has been thru the pain of QEMU / RISC-V.
-
obermd wrote:
As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly.
Yeah, it's a balance. I mean, to really learn what's going on underneath the surface, a lot has to be explained. And, since learning Assembly means you need to understand so many concepts (number bases, what hardware is actually doing, tools (compiler, linker, make, etc.)) there can be a lot to learn just to get to where you're learning the target thing. Petzold's books were long and in depth, but I really enjoyed his style and I felt like he was inviting me into a secret club to learn things that few others knew. :)
If you want to learn assembler because you think that you are smarter than the compiler, able to write faster code (you are not!), then you need only learn the syntax of the essential instructions, and you can use the inline assembly facilities provided by a lot of C/C++ compilers. If you intend to write complete modules in assembly, whether you are developing the backend for a compiler, writing a driver, or a high performance library, then you must understand all that stuff in the first 100 pages. I very much doubt that there is any description of, say, x64 or AArch64 architecture in less than 100 pages to teach you what you need to know to write a runtime system, even an interrupt handler, a driver or a compiler backend, or a library function, in pure assembler. Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks. Disclaimer: I do not know that specific book you are referring to. There are lots of poor books out there. What I am saying is that if you find any book of significantly less than 100 pages introduction to basic concepts of the architecture, they have skipped a lot of stuff that you have to learn from other sources. Te page counts of all those sources will probably add up to a lot more than 100 pages.
Religious freedom is the freedom to say that two plus two make five.
-
If you want to learn assembler because you think that you are smarter than the compiler, able to write faster code (you are not!), then you need only learn the syntax of the essential instructions, and you can use the inline assembly facilities provided by a lot of C/C++ compilers. If you intend to write complete modules in assembly, whether you are developing the backend for a compiler, writing a driver, or a high performance library, then you must understand all that stuff in the first 100 pages. I very much doubt that there is any description of, say, x64 or AArch64 architecture in less than 100 pages to teach you what you need to know to write a runtime system, even an interrupt handler, a driver or a compiler backend, or a library function, in pure assembler. Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks. Disclaimer: I do not know that specific book you are referring to. There are lots of poor books out there. What I am saying is that if you find any book of significantly less than 100 pages introduction to basic concepts of the architecture, they have skipped a lot of stuff that you have to learn from other sources. Te page counts of all those sources will probably add up to a lot more than 100 pages.
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks.
Oh, I totally agree. And, like I said, Duntemann is one of my favorite authors. I read the first edition of the same book back in 1993. It was published as Assembly Language Step-by-Step[^] back then and the book taught me everything I know about low-level programming. It is the first book that helped me understand number bases (binary, decimal, hexadecimal). So, really my only point is that since I've read those first 100 pages numerous times over the years it was a bit difficult to chew through them again since I was chomping at the bit to get to the good x64 Assembly stuff. :) Duntemann's book is really like a complete school of computing and software development all wrapped up, so in many ways it is a very short book. :-D It is often difficult as an "Application Developer" to slow down so much with Assembly. The things we use now that obfuscate all that stuff below are amazing and troubling at the same time. Now the devs know "it's easy to create software". But it's still not easy when problems occur and you don't know where (or how) to look.
-
honey the codewitch wrote:
I gave up. QEMU refused to operate in any of my environments. I tried several guides, and nada. :mad:
I felt the same way yesterday. I had spent all day yesterday and could not find any help or get it working. It was a real pain. I even asked Copilot to help me but it wasn't helpful. I finally got it working because I found that blog site (mentioned in original post). I got very lucky. I really had no idea what I was doing. Even the blog site had so much information that I barely made it through it. But, here's the deal. First of all make sure you've installed QEMU properly on your dev machine:
$ sudo apt install qemu-system-riscv64
$ sudo apt install u-boot-qemu opensbiAfter that, all I had to do was: 1) run this command to download a debian image:
$ wget "https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/download?job=convert\_riscv64-virt" -O debian-rv64.zip
- Then follow these commands:
$ mkdir debian-rv64
$ cd debian-rv64
$ unzip ../debian-rv64.zip
$ cd artifactsNOTE: That last step was wrong bec the directory that gets unzipped is not named artifacts but is named something else. Inside that "artifacts" directory, there is a readme.txt. I ignored the rest of the blog author's instructions and followed that readme. There is a command in there for how to start it: Note: Edited command because I had line breaks incorrect
qemu-system-riscv64 -machine 'virt' -cpu 'rv64' -m 1G -device virtio-blk-device,drive=hd -drive file=image.qcow2,if=none,id=hd -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2222-:22 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs console=ttyS0"
3rd Edit - With Line Breaks For Easier Reading (tested & it works)
qemu-system-riscv64 -machine 'virt' \
-cpu 'rv64' \
-m 1G -device virtio-blk-device,drive=hd \
-drive file=image.qcow2,if=none,id=hd \
-device virtio-net-device,netdev=net \
-netdev user,id=net,hostfwd=tcp::2222-:22 \
-bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
-kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
-object rng-random,filename=/dev/urandom,id=rng \
-dThanks. I wish I felt up to right now, but I'll bookmark this. I appreciate it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If you want to learn assembler because you think that you are smarter than the compiler, able to write faster code (you are not!), then you need only learn the syntax of the essential instructions, and you can use the inline assembly facilities provided by a lot of C/C++ compilers. If you intend to write complete modules in assembly, whether you are developing the backend for a compiler, writing a driver, or a high performance library, then you must understand all that stuff in the first 100 pages. I very much doubt that there is any description of, say, x64 or AArch64 architecture in less than 100 pages to teach you what you need to know to write a runtime system, even an interrupt handler, a driver or a compiler backend, or a library function, in pure assembler. Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks. Disclaimer: I do not know that specific book you are referring to. There are lots of poor books out there. What I am saying is that if you find any book of significantly less than 100 pages introduction to basic concepts of the architecture, they have skipped a lot of stuff that you have to learn from other sources. Te page counts of all those sources will probably add up to a lot more than 100 pages.
Religious freedom is the freedom to say that two plus two make five.
Agreed that you really need to know the architecture to get the most out of assembly, but the reality is you can start your journey in a lot fewer pages as many assembly tasks don't require the in-depth knowledge of the hardware. And yes, I know and have worked in four different machine languages - Intel x86, Motorola 6502, IBM BAL, and Dec's PDP-11. You can learn the architecture as you're learning the machine language.
-
I previously worked through the book (by one of my favorite tech authors - Jeff Duntemann) x64 Assembly Language Step-by-Step: Programming with Linux[^] There was a lot of build-up to read just to get to the meat. At least 100 pages or so. It was tough & I read a lot. This RISC-V Assembly Book Is Amazing! I recently stumbled upon this new book that I'm reading right now: RISC-V Assembly Language Programming: Unlock the Power of the RISC-V Instruction Set[^] This book : 1. gets right to the point - you start writing Assembly almost immediately. 2. Explains things really clearly -- It has helped me put some ideas together that I've never understood and things seem much more clear. Why Is It Easier? I believe a lot of it is easier because it is bas
-
honey the codewitch wrote:
I gave up. QEMU refused to operate in any of my environments. I tried several guides, and nada. :mad:
I felt the same way yesterday. I had spent all day yesterday and could not find any help or get it working. It was a real pain. I even asked Copilot to help me but it wasn't helpful. I finally got it working because I found that blog site (mentioned in original post). I got very lucky. I really had no idea what I was doing. Even the blog site had so much information that I barely made it through it. But, here's the deal. First of all make sure you've installed QEMU properly on your dev machine:
$ sudo apt install qemu-system-riscv64
$ sudo apt install u-boot-qemu opensbiAfter that, all I had to do was: 1) run this command to download a debian image:
$ wget "https://gitlab.com/api/v4/projects/giomasce%2Fdqib/jobs/artifacts/master/download?job=convert\_riscv64-virt" -O debian-rv64.zip
- Then follow these commands:
$ mkdir debian-rv64
$ cd debian-rv64
$ unzip ../debian-rv64.zip
$ cd artifactsNOTE: That last step was wrong bec the directory that gets unzipped is not named artifacts but is named something else. Inside that "artifacts" directory, there is a readme.txt. I ignored the rest of the blog author's instructions and followed that readme. There is a command in there for how to start it: Note: Edited command because I had line breaks incorrect
qemu-system-riscv64 -machine 'virt' -cpu 'rv64' -m 1G -device virtio-blk-device,drive=hd -drive file=image.qcow2,if=none,id=hd -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2222-:22 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng -nographic -append "root=LABEL=rootfs console=ttyS0"
3rd Edit - With Line Breaks For Easier Reading (tested & it works)
qemu-system-riscv64 -machine 'virt' \
-cpu 'rv64' \
-m 1G -device virtio-blk-device,drive=hd \
-drive file=image.qcow2,if=none,id=hd \
-device virtio-net-device,netdev=net \
-netdev user,id=net,hostfwd=tcp::2222-:22 \
-bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
-kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf \
-object rng-random,filename=/dev/urandom,id=rng \
-d -
Yes, RISC assembly is fun. Trying to understand the compiler generated RISC assembly is less fun.
"In testa che avete, Signor di Ceprano?" -- Rigoletto
Any compiler generated assembly is anything but fun.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Â Â Â Â Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Any compiler generated assembly is anything but fun.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Â Â Â Â Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
That has been true since the late 1950s! I read a (physical!) paper from a "History of Programming" conference from the people developing the optimization functions of the Fortran II compiler. (I have tried to find it on the internet, but without success.) As the work progressed, they frequently saw that the result from a run of the code was as expected, so the optimization had produced 'correct' code. But when they inspected the code, they were scratching their heads: How the h*** did the compiler discover that it could do that?? It could take several hours and days to fully understand how the compiler had been "thinking", even though the compiler was their own work.
Religious freedom is the freedom to say that two plus two make five.
-
That has been true since the late 1950s! I read a (physical!) paper from a "History of Programming" conference from the people developing the optimization functions of the Fortran II compiler. (I have tried to find it on the internet, but without success.) As the work progressed, they frequently saw that the result from a run of the code was as expected, so the optimization had produced 'correct' code. But when they inspected the code, they were scratching their heads: How the h*** did the compiler discover that it could do that?? It could take several hours and days to fully understand how the compiler had been "thinking", even though the compiler was their own work.
Religious freedom is the freedom to say that two plus two make five.
Setting the weights in decision making trees and assigning techniques to every leaf is straightforward (for varying levels of straightforwardness). Finding out which path the algorithm took looking at the output is neither straight nor forward. When the output is an assembly source file the difficulty is tenfold.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Â Â Â Â Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
You need to write a CodeProject article for this!
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
obermd wrote:
As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly.
Yeah, it's a balance. I mean, to really learn what's going on underneath the surface, a lot has to be explained. And, since learning Assembly means you need to understand so many concepts (number bases, what hardware is actually doing, tools (compiler, linker, make, etc.)) there can be a lot to learn just to get to where you're learning the target thing. Petzold's books were long and in depth, but I really enjoyed his style and I felt like he was inviting me into a secret club to learn things that few others knew. :)
"I mean, to really learn what's going on underneath the surface, a lot has to be explained." This is not limited to assembly. My C++ book for beginners to programming, "C++: A Dialog", doesn't show the first line of C++ until about page 75 because I start by explaining hardware concepts like memory and registers, and there is a lot more such explanation before we get to anything complicated in C++. Of course a lot of C++ books don't go into this detail but I think it is necessary to be a good programmer. How can you write good code without understanding what is going on underneath the C++ syntax?
