In short I'm tired of assembly tutorials written in some weird Turbo CPheascva#++.net. I'm still in the leaning phase and i simply can handle all thouse different languages, it only confuses me further.
The same goes for writing assembly for Linux, windows, OS, etc. I'm just not interested, if i were, assembly wouldn't be the programming language of my choice. Further more, different assemblers work in different ways, some with various macros and stuff, and some writes everything backworths, some are made of cheese, etc.

Well that wasn't really short at all, but to get to the point:

MOV AX,BX ; I understand

.Weirdstuff{Bill, }~"don't ask me" ; I don't understand



Well maybe its not that bad, but in generel you find a great tutorial that is written in a way that you can actually understand, you scroll a bit down the page to see some actual code, only to find that it is written in QBasic.

So if anyone know of anything that just remotely lives up to my demands, I'm very interested, and yes i have started reading the 3000 pages Intel manual, but it is somewhat... tough. I will get through it eventually though.

Anyway, thanks in advance, and thanks for a great forum.
Posted on 2007-01-14 15:06:34 by Zacariaz
Intel Manuals are not very good to start with >_> Have you read the Iczelion's tutorials?
Posted on 2007-01-14 15:28:44 by ti_mo_n
Yes and no, i briefed it.
It uses win32API, and various other stuff that i am not interested in learning about.
I will of course take another look now that you have recomended it, but i suspect that the few bit that i actually can use for what im doing, i have allready learned.

Thanks for the answer though.

Though maybe a little excample were in place:

.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
.data
MsgBoxCaption db "Iczelion Tutorial No.2",0
MsgBoxText      db "Win32 Assembly is Great!",0
.code
start:
invoke MessageBox,NULL, addr MsgBoxText, addr MsgBoxCaption, MB_OK
invoke ExitProcess,NULL
end start


This is a piece of code taken from the tutorial you recomended, and my question, just to point out what i am looking for, is:
"how many basic IA-32/x86 Mnemonics do this piece og code contain?"
Posted on 2007-01-14 15:36:08 by Zacariaz
Learning how to program requires that you learn specific language and os. You can't program without OS-related stuff. Even if you write your own OS, you still have to you BIOS and/or specific messages defined by specific protocols. These 'specific protocols' (like PCI, ACPI, etc.) act as a (very simple) OS, so it's really required to learn one ^^ In other words: if you want your program to do something productive under certain OS, you have to know how to communicate with this OS (at least at some very basic level). If we take windows: you don't have to know how to make l33t activeX controls, but knowledge about messagebox is really mandatory xD
Every program requires some data, to process. The data is either being input by the user or it is being stored inside the executable.
If we have some data and some code, we have to tell the compiler 'what is what' so that it doesn't try to execute the data (at binary level everything looks identical - both the code and the data are just streams of bits).
Finally, if we use some external libraries, which we use if we call messagebox (this function resides inside one of the OS's DLL), we have to tell the compiler to 'do some required stuff' so that your app can call messagebox which is inside another executable (a DLL, to be exact).

What you see in the example you pasted is exactly what I have described above. Even if you're interested in writing 'plain algorithms' without the applications to run them, you have to know how to make correct executables for _ANY_ OS. Or in other words: if you want to see your application alive, you have to compile to for specific OS and that requires you to know how to do that. The mini-application from the example above is the absolute minimum you have to understand to make executables.

Put your own code before 'ExitProcess', your own data in the data section, compile and be happy :P

The above code produces following mnemonics in the code section:
push MB_OK
push addr MshBoxCaption
push MshBoxText
push NULL
call MessageBoxA
push NULL
call ExitProcess

As you can see it is longer to write and contains more line so it's also somewhat more difficult to comprehend. That exactly what macros are for.
Posted on 2007-01-14 16:02:21 by ti_mo_n
Well thats a problem I am always having. I bought two books and already read many e-books and manuals on assembly. But the sad reality is that schoolars or professors, doctors and experienced programmers who CARES to write something for us, less experienced coders, usually write on their own sometimes and with doubtful methodology. I dont blame them tho.

I bang my head on the keyboard all the time because of that sad truth but few things you must keep in mind:

  • People write if they want to. Someway if someone writes something we should be already thankful. Its weird to say that but someway, every bit of knowledge matters in that field.

  • I hate the fact that different assemblers behave differently. I cant do much about it so... I setup a goal. Since I mostly use Windows on a 32bit pc, I choose MASM because well... Microsoft should know well how its own OS works. If I want to work on something else one day I will just throw MASM away and try to learn a new syntax. Sad but I think its better than banging the head.

  • You should know why you choose asm afterall. Thats the main thing. I think doesnt matters for me if I am using .if and .elseif or if I am making all of those handcrafting just to make it. I dont know for the others but I see asm as a tool. I believe thats the way it should be seen like.

  • I run all across the cyberspace trying to find someone to teach me how each instruction and interrupts works. That is a childish aproach nowadays I think. Because well... I believe even the experienced coders have a "functional" knowledge about asm and neither them know it. Its hard even to find Cpp gurus, the day you find one for asm dont expect him to teach you everything for free. But you can try.



Well I am not telling you to read what I said above. But when I am in a problem like the one you are having, I ask myself the things above.

Anyway, I've been taking a closer look here and there and believe me, I really like to read anything that I can see and as such I found a little thing that may be of your interest. I uploaded a pdf file with a few things about asm. Maybe you may know everything there is there and maybe the writer is not really the kind of you want but anyway, this pdf helped me to start. I hope helps you too.

P.S.: For got to say, this doc maybe is a bit outdated. But still the concepts works.
Posted on 2007-01-14 16:07:38 by codename
I hate the fact that different assemblers behave differently. I cant do much about it so... I setup a goal. Since I mostly use Windows on a 32bit pc, I choose MASM because well... Microsoft should know well how its own OS works. If I want to work on something else one day I will just throw MASM away and try to learn a new syntax. Sad but I think its better than than banging the head.

Asseblers dont 'behave' differently - they just have a SLIGHTLY different syntax. And there are actualy 3-4 commonly used syntaxes (which are very similiar), so it's not _THAT_ hard to learn them all when you learn one of them.
MASM is good, but it's not because 'ms knows its system'. If you want to make a compiler/linker, you have to know the executable format you wish to create. Knowledge about system is helpful (to make some optimizations, for example), but not very required (of course some minimum is _always_ required).

I run all across the cyberspace trying to find someone to teach me how each instruction and interrupts works. That is a childish aproach nowadays I think. Because well... I believe even the experienced coders have a "functional" knowledge about asm and neither them know it. Its hard even to find Cpp gurus, the day you find one for asm dont expect him to teach you everything for free. But you can try.

Yes, there are many 'pseudo coders' that claim to know everything, yet their (limited) knowledge comes from someone other's (limited) knowledge, instead of books like Intel Manuals. But that's why we're here for: to help each other ^^ We ask and we learn :)

ASM is quite difficult when you start, because you have to learn not anly ASM, but also your compiler's syntax, you OS's API calling convention etc. These things are hidden in hihg level languages and reveal themselves in asm.

Anyway it's fun to know asm, so good luck and don't hesitate to ask people on this forum ^^
Posted on 2007-01-14 16:19:42 by ti_mo_n

Learning how to program requires that you learn specific language and os. You can't program without OS-related stuff. Even if you write your own OS, you still have to you BIOS and/or specific messages defined by specific protocols. These 'specific protocols' (like PCI, ACPI, etc.) act as a (very simple) OS, so it's really required to learn one ^^ In other words: if you want your program to do something productive under certain OS, you have to know how to communicate with this OS (at least at some very basic level). If we take windows: you don't have to know how to make l33t activeX controls, but knowledge about messagebox is really mandatory xD
Every program requires some data, to process. The data is either being input by the user or it is being stored inside the executable.
If we have some data and some code, we have to tell the compiler 'what is what' so that it doesn't try to execute the data (at binary level everything looks identical - both the code and the data are just streams of bits).
Finally, if we use some external libraries, which we use if we call messagebox (this function resides inside one of the OS's DLL), we have to tell the compiler to 'do some required stuff' so that your app can call messagebox which is inside another executable (a DLL, to be exact).

What you see in the example you pasted is exactly what I have described above. Even if you're interested in writing 'plain algorithms' without the applications to run them, you have to know how to make correct executables for _ANY_ OS. Or in other words: if you want to see your application alive, you have to compile to for specific OS and that requires you to know how to do that. The mini-application from the example above is the absolute minimum you have to understand to make executables.

Put your own code before 'ExitProcess', your own data in the data section, compile and be happy :P

The above code produces following mnemonics in the code section:
push MB_OK
push addr MshBoxCaption
push MshBoxText
push NULL
call MessageBoxA
push NULL
call ExitProcess

As you can see it is longer to write and contains more line so it's also somewhat more difficult to comprehend. That exactly what macros are for.


It might be longer, but i can see what is actually happening, more or less, when all is said it is really not that informative.
I see no Registers being modified in anyway, and there is alot more i dont see that i want to see.

Regarding programming for a specific OS, to quote my self:

I'm just not interested, if i were, assembly wouldn't be the programming language of my choice.


I ment it when i wrote that.
If i were to write for windows as an example, but i certainly wouldnt use assembly for that. The reason? It would be far way easyer to use c++ as i allready know (more or less) and the result would probably not be that different.


Well thats a problem I am always having. I bought two books and already read many e-books and manuals on assembly. But the sad reality is that schoolars or professors, doctors and experienced programmers who CARES to write something for us, less experienced coders, usually write on their own sometimes and with doubtful methodology. I dont blame them tho.

I bang my head on the keyboard all the time because of that sad truth but few things you must keep in mind:

  • People write if they want to. Someway if someone writes something we should be already thankful. Its weird to say that but someway, every bit of knowledge matters in that field.

  • I hate the fact that different assemblers behave differently. I cant do much about it so... I setup a goal. Since I mostly use Windows on a 32bit pc, I choose MASM because well... Microsoft should know well how its own OS works. If I want to work on something else one day I will just throw MASM away and try to learn a new syntax. Sad but I think its better than banging the head.

  • You should know why you choose asm afterall. Thats the main thing. I think doesnt matters for me if I am using .if and .elseif or if I am making all of those handcrafting just to make it. I dont know for the others but I see asm as a tool. I believe thats the way it should be seen like.

  • I run all across the cyberspace trying to find someone to teach me how each instruction and interrupts works. That is a childish aproach nowadays I think. Because well... I believe even the experienced coders have a "functional" knowledge about asm and neither them know it. Its hard even to find Cpp gurus, the day you find one for asm dont expect him to teach you everything for free. But you can try.



Well I am not telling you to read what I said above. But when I am in a problem like the one you are having, I ask myself the things above.

Anyway, I've been taking a closer look here and there and believe me, I really like to read anything that I can see and as such I found a little thing that may be of your interest. I uploaded a pdf file with a few things about asm. Maybe you may know everything there is there and maybe the writer is not really the kind of you want but anyway, this pdf helped me to start. I hope helps you too.

P.S.: For got to say, this doc maybe is a bit outdated. But still the concepts works.



I think we understand each other.

I started learning assembly for severel reasons.
1. I want to know how it all really works.
2. I thought it could be fun and potential useful, to squeze every little bit power out my computer.
3. I want to do things my own way, i want to be in complete control of what im doing.
4. I have allready written my own Bootloader, and i dont intent to stop there ;-)

Thanks for all the answer by the way, hope to see more.
Posted on 2007-01-14 16:34:01 by Zacariaz

Asseblers dont 'behave' differently - they just have a SLIGHTLY different syntax. And there are actualy 3-4 commonly used syntaxes (which are very similiar), so it's not _THAT_ hard to learn them all when you learn one of them.
MASM is good, but it's not because 'ms knows its system'. If you want to make a compiler/linker, you have to know the executable format you wish to create.


Assemblers behave differently, if only the syntax changed people wouldnt asm at all and if they did everybody would just choose a free standard just like many scripting languages. What makes tools have different names are different functions. Not different ways of using it. A hammer with plastic head is still a hammer. And actually doesnt matters if you are using MASM, NASM, TASM, BLASM, etc. MASM is not good because it can magically be making an .exe file, link some libs and throw a pe header. All assemblers do it in windows.


4. I have allready written my own Bootloader, and i dont intent to stop there ;-)


Oh thats cool. I hope you are really successfull.
Posted on 2007-01-14 16:39:01 by codename
If we are just looking at layout id say one assembler is the same as another, though i prefer:
MOV AX,37

instead of
MOV $37,%AX

I don't see any reason to make it more complicated than it allready is.

Not that i know anything about it i suspect, as you say, that assemblers is very different when it comes to assembling the actual code and that is a problem, cause you really need to look at the opcode to know whats going on, and that is difficult to say the least.
To be honest, i think i would prefer to program in opcode, but eh, i may be intelligent, but I'm not a genius ;)

Thank you for the remark about the bootloader, it really nothing to brag about, its basically copy and paste from the net, but i understand fully whats going on, thats what important. I have still to understand and implement 32 bit PMode, so if anyone know a guide/toturial they think ill understand, ill be ore than happy to recieve a link ;-)


Before i go to bed i would like to give yet another reminder as to why it is important for me to be in control. An example might be in order:

MOV AX,0
XOR AX,AX

The two give exactly the same result, only MOV uses 6 cycles (i think) and XOR only 3 (i think)
Which basically means that one is twice as fast as the other.
Thats why i wont use macros and other stuff i haven't made myself.

I bid you all goodnight
Posted on 2007-01-14 18:11:39 by Zacariaz
ok, i just thought i d share my thoughts on the topic, in no particular order.

on the subject of what things to learn first , or at all, etc, ... to me its dependent on the reason why you are learning asm. as zacariaz said, if you re writing a bootloader you might aswell ignore winAPI. BUT it depends also on what you already know that usually "goes along with asm" but is not really related, like binary/hex/ systems or logical ops or numbers representation (ok, i wont do no sign-magnitude talk here :D) . this may be not required at all for "dull" asm coding.

looking back, and thinking that i actually begin to have a good understanding of how this stuff works, its is relevant to ask myself how i, too, learnt.

well i wouldnt say its been the easiest possible way (as i explain later in my views of ideal learning tool) but i dont regret it at all, since i therefore know the historical background that existed in the old era of MSDOS 16 bits PC programs and i (somehow wrongly^^) still value this. i also would like to state, that i needed quite some perseverance and motivation in learning this l33t language.. even if i consider it not very hard now, its been hard at times... coz no teacher maybe... i feel i could explain it to anyone now (ok ok get back, hord of l4me n3wBs, i take that back :D) ...  i find scary the statement of codename that noone would share knowledge bout this, without getting paid... man, maybe not many ppl are interested into this, and thats all!(i hope so anyway)... here should be a good place to start...?

i began to learn in a very old e-zine talking of embedding 16bits asm in turbo pascal, so thats where my first steps took place. it was not such a bad idea since the newbie has already working program and one func is asm and one can try simple things... but its just for discovering "harmless" instr. set. still, i really had a hard time sometimes at that time :) . then in the same mag i read (vastly) more thorough articles explaining Prot mode, 32b, unreal, etc. woo... in fact, then succeeded a long period of time when i  almost didnt code anything (mainly due to school and laziness) , but during this time i read a lot, most in the intel manuals and nasm doc. i believe this prevented me to get frustrated in writing things too complicated too early, that wouldnt work... when i sat down and coded in a few days a full-asm DOS unrealmode VESA2 system, with keyb and timer correctly hooked, it worked! :)

for some reason i like nasm (and fasm) syntax.

what i would say: there are tons of docs today on the net. when learning complicated things, understanding well before experimenting might be a good idea.

to my eyes theres still no good environment for teaching/learning asm.

i mean, ideal stuff would be:
DOS .COM-like model, which is, three sections of (.code), (.data), (.bss) one after the other; a .ORG of zero would be perfect. all this thing in 32b protected mode, (ring0 single task if you want to teach people not to make endless loops :) ); this gets loaded (no addr resolution) into its custom segment anywhere (logical addr) the OS wants, cause OS creates a seg whose base addr is where the program gets loaded (in fact this is just like it works in 16b DOS .COM); there are OS calls like printstring printval readkb setpixel (optionnally readfile and malloc), accessed just by doing a far call into to the OS's (fixed) segment selector and fixed ofset per call.

crystal-clear!

no exec format.
no linking.
no addr resolution at load.
no dlls to import.

this would be a dream for a beginner. (actually, some things under dev are already far better than that..) one include containing OS's selector and OS functions offsets. that ALL. you can give a try at the whole instruction set from ADD to LGDT.

BUT, this would just be very much "cleaner" and minimalistic than win32asm...not fundamentally different to code...
in fact includes, macros, etc... are just things used by ppl who ALREADY understand very well how to do things without them, and that have come to the conclusion that it eased things a lot... but of course its important to do things without before, otherwise you keep disliking them as "too highlevel" and obfuscating things. it took me some time to understand this.(ofcourse even best way is to write your own, then you feel its YOU whos smart :D) ... its like when in a C program you find strange coding habits that seem to obfuscate things and you dislike them as a beginner, but A LONG TIME LATER with experience of coding without them you realize its in fact useful when you know what youre doing and you're seasoned to that type of thinking, cause it makes things more compacts/etc... but these are things youve GOT to discover yourself :) (and you end up one day and you find OOP "interesting" aswell, then "brilliant" (hmm... i NEVER wrote that ok? :D) and would like to brag everyone about it but you realize you'd look like all the fanboys you were despising before... man thats hard :D )

good luck to you zacariaz and codename on your path towards understanding things!

bootloader? great! i remember my joy when watching the pixel i drew at 0xA000 in mode 0x13, proof that the boot sector of my floppy was a success!


Posted on 2007-01-14 21:37:00 by HeLLoWorld
http://www.jegerlehner.ch/intel/

"Download as a PDF file".

print both faces.

PIN IT IN YOUR BEDROOM!











i did. :)

Posted on 2007-01-14 21:56:44 by HeLLoWorld

To be honest, i think i would prefer to program in opcode, but eh, i may be intelligent, but I'm not a genius ;)

It doesn't take a genius to program in opcodes, it just takes a lot of memorizing and stupid grunt work. Actually it'd take more or less an idiot to program in opcodes these days, you don't gain anything from it compared to writing your code in assembly. (Of course familiarizing yourself with the instruction set and doing a little of this can be beneficial if you're to write an assembler or disassembler, but it's plain silly as a general programming method).

Anyway:
Unless you're going to program your own OS, you need to interface with an existing OS. I suggest you just accept this, use a skeleton and don't worry about the "red tape", but instead focus on adding some meat to the skeleton. You can then use a debugger to check out what's going on, reducing the need for more OS calls, if you feel those are so horrible.
Posted on 2007-01-15 03:57:56 by f0dder

i find scary the statement of codename that noone would share knowledge bout this, without getting paid... man, maybe not many ppl are interested into this, and thats all!(i hope so anyway)... here should be a good place to start...?


Dont be scared. You just got me wrong. I did not say that noone would share asm knowledge without getting paid. What I did say is that you probably wont find many asm gurus out there and if you do probably you wont get premium support from him/her for free. But you can try.

Basically what I am saying is that assembly is kind of an art. I believe many just do it for a hobby because usually you would go some other language for the big stuff. In other words, the life of an assembly programmer is hard because you will probably be reading useless stuff or fragmented knowledge everywhere and it is up to you to defragment all of this and use for your own fun.
Maybe with the asm community initiative and the always growing asm wiki this knowledge will finally be centralized for the enjoyment of all. But doing this in large scale and in a friendly way will still take some time. For a while we can read manuals and burn some processors.
Posted on 2007-01-15 06:32:21 by codename