111–120 of 238 posts
Also Matt Godbolt's gcc explorer is the the bee's knees for understanding assembly https://godbolt.org/ I think that playing around with it for 2 hours will teach you more than most classes on the topic. It really drives home why interactivity is such a bit deal in education. You should also try writing a script for counting instructions in binaries. It's pretty illuminating. Here are some sample statistics https://w…
"To write code that runs directly on your microprocessor you need to know how memory segmentation works"
Although you can't completely ignore segments, in practice at least on Linux the only segments in use are user code/data and kernel code/data segments.
Does anyone know why the author might suggest that understanding segmentation is necessary to write Assembly code?
Earlier quoted context omitted.
Here are the opcodes for the x86 ADD assembler instruction: http://www.mathemainzel.info/files/x86asmref.html#add The link shows nine ways to use the ADD instruction with each method resulting in a different opcode.
There's a bit of a miscommunication going on. What I meant was, when you write an assembly instruction, that maps to one machine instruction. I.e., because of things like addressing modes, different invocations of an ADD instruction can map to different machine instructions. But one ADD invocation will always map to one machine instruction. The parent comment sounded to me like one assembly instruction could map to s…
Earlier quoted context omitted.
Two ways. The first is IO mapped IO, which is what the x86 supports with the IN and OUT instructions. All this really is is a MOV to a different "address" space (16 bits of addressing). The second is memory mapped IO, in which hardware is mapped to the addressing space of the CPU (Motorola 68K uses this format). A CPU that allows IO mapped IO can also do memory mapped IO (it's not precluded).
Question I've been wondering about for a while: where does PCI fall into this? Do modern x86 PC systems still use in & out at all?
Earlier quoted context omitted.
> x86 is the worst ISA. I can only assume you've never had to program a Burroughs B90 in assembly language.
I haven't. It's probably not fun.
After programming in it, I can assure you that programming in other assembly languages (including x86) is a breeze.
I should put my cheat-sheet on the web, if I can still find it.
What a train wreck! It’s hard to imagine a more confusing state of affairs. I'd say that's more attributed to someone many many years ago deciding they would not follow the official Intel syntax (for what reason I do not know), and somehow convincing the rest of the community to follow them. That's actually one of the things that could make for a very interesting article: how one processor family got two different an…
Earlier quoted context omitted.
Suppose you're right and the registers are arbitrary. Then how would foreign function calls work? If you're compiling Rust code that calls into a C library, how does it know what registers to use? So the choice of registers cannot be arbitrary, unless the compiler knows the function is only used within an object file. The registers are predetermined by a convention unless you use the 'static' keyword to signal that t…
> If you're compiling Rust code that calls into a C library, how does it know what registers to use? Ah, interesting, I figured that the generated object files would just store some metadata on that basically.
Also Matt Godbolt's gcc explorer is the the bee's knees for understanding assembly https://godbolt.org/ I think that playing around with it for 2 hours will teach you more than most classes on the topic. It really drives home why interactivity is such a bit deal in education. You should also try writing a script for counting instructions in binaries. It's pretty illuminating. Here are some sample statistics https://w…
You'll see the various ways the compiler avoids emitting an actual multiplication instruction. The smallest multiplier I found that actually produced an imul: 46.
What a train wreck! It’s hard to imagine a more confusing state of affairs. I'd say that's more attributed to someone many many years ago deciding they would not follow the official Intel syntax (for what reason I do not know), and somehow convincing the rest of the community to follow them. That's actually one of the things that could make for a very interesting article: how one processor family got two different an…
> how one processor family got two different and incompatible Asm syntaxes Do you know the reason for this?