ASM
-
Curufir
Re:ASM
Well I haven't bothered to actually count them, but at a guess you can get from boot into your kernel knowing around 10 assembly commands, an extra 2 if you want to set up an IDT/GDT and enter Pmode first.
You have to remember that the whole assembly "language" represents approximately 120 commands (Discounting MMX and FPU instructions), of which maybe 30 are used on a regular basis. Learning how to use those instructions half-decently...well that's a different story
.
You have to remember that the whole assembly "language" represents approximately 120 commands (Discounting MMX and FPU instructions), of which maybe 30 are used on a regular basis. Learning how to use those instructions half-decently...well that's a different story
.-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:ASM
i suggest you get a local copy of "Easy Assembler Programming" at your local bookstore (avl. for about 3?) and get a look at what there is ... a good understanding on stuff like MOV, ADD, PUSH, POP, CALL, JMP and RET is certainly mandatory ...
The rest will mostly depend on what you need... and is more likely to be described in the Intel System Programming Manual than in an ASM book ...
The rest will mostly depend on what you need... and is more likely to be described in the Intel System Programming Manual than in an ASM book ...
-
Schol-R-LEA
Re:ASM
Quite frankly, understandng and using the individual instructions is a relatively minor part of assembly programming. More important factors include the relative speed of different instructions and combinations thereof, the interactions between instructions (e.g., which instructions affect or are affected by the flags, what registers a given instruction uses, etc.), how to sequence instructions in the most efficient manner, etc.
In systems programming, there are the added issues of working with interrupts, the memory manager, the system clock or timer, and the peripherals, among other things. Page tables need to be set up, interrupt vectors initialized, drivers installed in the right places, scheduling and memory mangement code started.
On the x86 there is another factor to consider, one which overshadows all others: working with the memory models. This is especially true in real mode programming, where the segmented architecture is inescapable. In protected mode, most memory models shield the application programs from these complexities; but this comes at the cost of more complex memory handling by the system software. A protected mode kernel has to be dutifully aware of how it is handling its own memory segments and those of the application programs, even in so-called flat mode. It is one of the chief stumbling blocks to OS design on the PC, as a quick scan of the archive could show you.
The good news is, there are some excellent books on assembly programming, several of which you should find if you check out the books thread. Also, there are some sharp assembly programmers around here who can help out with most questions (though a lot of general asm questions might be better discussed on the General Programming forum). If you search the foum archives, you should find plenty of useful information on assembly programming as well. HTH.
In systems programming, there are the added issues of working with interrupts, the memory manager, the system clock or timer, and the peripherals, among other things. Page tables need to be set up, interrupt vectors initialized, drivers installed in the right places, scheduling and memory mangement code started.
On the x86 there is another factor to consider, one which overshadows all others: working with the memory models. This is especially true in real mode programming, where the segmented architecture is inescapable. In protected mode, most memory models shield the application programs from these complexities; but this comes at the cost of more complex memory handling by the system software. A protected mode kernel has to be dutifully aware of how it is handling its own memory segments and those of the application programs, even in so-called flat mode. It is one of the chief stumbling blocks to OS design on the PC, as a quick scan of the archive could show you.
The good news is, there are some excellent books on assembly programming, several of which you should find if you check out the books thread. Also, there are some sharp assembly programmers around here who can help out with most questions (though a lot of general asm questions might be better discussed on the General Programming forum). If you search the foum archives, you should find plenty of useful information on assembly programming as well. HTH.