Assembly Programming

Alright, I'm going to ask to spare me the lecture of "Assembly will make very little difference speed-wise, Assembly is very difficult, and etc." Yes I know, but the point is I want to learn it and I already have a general understanding of how it's supposed work. I know that all CPUs have registers, and the 8086 CPU is what all modern CPUs are based from today. I know that these registers are faster than RAM, and standard registers are ax, bx, si, and etc. That is under 16 bit of course. I also understand the basic commands such as mov ax, 31. I'm also aware of interrupts, these can be used for handling peripherals, video, and such. My problem is simply this, finding a decent (free) book utorial that goes over all of this without being bound to Windows, Linux, DOS, or even the C language itself. I want it to be completely unbound from the operating system that it runs on, or rather, have no OS at all and simply boot it from a CD\floppy. My main goal is to make my own OS, but that will come later, right now I simply want to learn how do Assembly programming without being bound to an OS.

With that out of the way, I'd like to learn 32 bit and 64 bit Assembly. If anyone knows of any decent (free) books utorials that I could use, that'd be great. Any help is greatly appreciated.

I highly recommend learning assembly I don't know why anyone would say such terrible things. Its extremely useful to know whats going on behind the scenes. That being said I recommend you learn 32 bit before tackling 64 bit. The primary reason? Theirs much more information about it online.

These links should prove useful:
http://homepage.mac.....edu/index.html
http://win32assembly...r/download.html
http://www.amazon.co...e/dp/0763772232

You should probably learn assembly the usual way (with access to an OS of some type). If you don't use an OS it will be really hard to write and test simple programs.

You then need to learn how the boot process works, in whatever platform you are targeting. For instance in x86, the CPU boots into real mode and executes a program in the BIOS, which will typically do something like loading the boot sector from some disk into a fixed location in memory and executing it. Your job as an OS writer is to make a boot sector that will load in other sectors (because it's hard to do much in 512 bytes), switch to protected mode (which I didn't get to work when I tried as a teenager) and run some sort of kernel that keeps track of what processes are being run, organizes memory so each process sees the right segments... Plus you need to provide all sort of services (learning assembly with an OS first will give you a good feel for what those services are).

Then you have to convince hardware manufacturers to provide drivers for your OS or give you enough specs so you can write them yourself. This is when your dream of writing an OS will probably break down (sorry!).

This is an overwhelming project for anyone, and I think you should probably start by learning assembly for one platform and one OS and make a few tests with running a real-mode program from a boot sector. At that point you'll probably know about as much as I do about these things. Then you can reconsider what your goals are. Perhaps learning how the Linux kernel works would be a good thing to do from there. Then reconsider again. Etc.

My guess is that your goals will morph as you learn more, and that's not a bad thing. Perhaps you'll end up contributing something awesome to Linux, instead of writing your own OS. But there's nothing wrong with that.

Assembly will make very little difference speed-wise, Assembly is very difficult, and etc.[/quote]
Not if you know when to use it. Rewriting your GUI in assembler will probably end up being slower than a high level language being compiled into machine code, and will make the code maintainer (= you) weep. On the other hand, writing very specific and localized sections of code in assembler can offer ludicrous speed boosts, because you know exactly what you want and how to do it, unlike the compiler which has to guess to some extent. For the record, I had written a crypto algorithm in relatively optimized high level code. and the performance was pretty bad, around 80MB/s. I rewrote it in assembler: 350MB/s, and the code was actually more readable. And it wasn't even difficult assembler.

Those who say assembler is useless clearly have not been around much (not that there's anything wrong with not needing to mess with assembler, but forming an opinion on something you never used is probably not the best use of everyone's time).

It depends how far you want to go. Learning every tiny bit of modern assembler is probably interesting but I doubt you would find much use for it except in extremely specific sections (like, writing an operating system or a driver), however having a basic to moderate understanding of assembler is absolutely required in my opinion.

I want it to be completely unbound from the operating system that it runs on, or rather, have no OS at all and simply boot it from a CD\floppy.[/quote]
There are a few "my first OS" tutorials for NASM and other around the net, did you check these out? Then you can try and build on them to understand them better, for instance there's this or this or perhaps that or even this. But you are probably better off learning assembler from within a stable OS before wandering into these kinds of areas, because they are two different things.

And in case I missed your question, no, there is no reasonable way of "running arbitrary assembler code from no OS at all". And besides you probably wouldn't want to reboot every time you need to change something. And... assembler itself is completely distinct from the OS you use. The only difference would be the tools offered on each platform to facilitate assembler development - the assembler language itself remains the same (well, there's Intel and AT&T but that's different). Well, unless you call system API's from your assembler code, but then, you do need an OS. Your question is confusing.

I second DevLiquidKnight - learn 32-bit first. You'll be surprised how little documentation there is on 64-bit assembler compared to 32-bit even though 64-bit has been out for quite a while now.

The Intel Architecture developer manuals are a must. http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. They're free for PDF download.

XviD project contains a lot of of assembly code you can look into for reference. It's great because most functions have a C, an MMX, 3DNow! (warning: 3DNow is deprecated), and SSE counterpart; which is great as examples of how a problem can be approached with multiple solutions.

My 2 cents. Cheers
Dark Sylinc

I have looked around at the my first OS programs out there. I've even managed to get them to work messing around with VirtualBox, Virtual Floppy Disk, and RawWrite. As for the driver portion, yes I know this where I'll likely get stuck. Although, when I do have an understanding of how things work, I'll look over at MenuetOS an operating system made using only Assembly, it's open source in both 32 bit and 64 bit with some basic drivers. Funny how I can run it from a single floppy disk...

As for the portion where I said to spare me the lecture, I simply said that because I know that a lot of people think it's worthless, and I don't. Thanks for all of the links supplied, I've probably got a lot of work ahead .

If you're aiming at OS dev, here's a pretty good resource:

http://www.osdever.net/

This tutorial in particular:

http://www.osdever.n...opment-tutorial

There's a free book, "Art of Assembly Language Programming". I've never really looked at it but it seems quite comprehensive:

http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html

There are Intel system programmer manuals and things like that on the Intel website which is a good source once you get going with the x86.

As for the portion where I said to spare me the lecture, I simply said that because I know that a lot of people think it's worthless, and I don't. Thanks for all of the links supplied,

No.
No, not at all. I was frankly going to blast you for that segment of your post specifically because it was a bit insulting that you had just assumed no one here could imagine that you had an understandable reason for wanting to learn raw assembly.

Raw assembly is one of those thing people sometimes learn and there never needs to be justification for it. It has its place in modern programming just as much as in past programming. The raw roots of any hardware never did much harm. Only a handful of people died.

I refrained from my blasting because everyone else already presented the “helpful” portion that I would have presented, along with the blasting. So my reply would have been nothing but blasting.


Unfortunately I can’t top any of the posts before me. You got the main links around town and I can’t provide better ones. I just want to point out that I would have tried my best to provide you with some links over a day ago had I not felt a bit affronted by your initial post, which assumed I would do nothing but question your quest to learn ASM, which to me is a ridiculous concept (not learning something new is ridiculous).

People need a good reason to start making a new game engine, not to start learning ASM.


L. Spiro

I got on swimmingly with this, so much so, I paid for a hardcopy. FWIW, the hardcopy is poorly printed, so stick with the PDF

[quote name='Spirrwell' timestamp='1340640994' post='4952691']
As for the portion where I said to spare me the lecture, I simply said that because I know that a lot of people think it's worthless, and I don't. Thanks for all of the links supplied,

No.
No, not at all. I was frankly going to blast you for that segment of your post specifically because it was a bit insulting that you had just assumed no one here could imagine that you had an understandable reason for wanting to learn raw assembly.

Raw assembly is one of those thing people sometimes learn and there never needs to be justification for it. It has its place in modern programming just as much as in past programming. The raw roots of any hardware never did much harm. Only a handful of people died.

I refrained from my blasting because everyone else already presented the “helpful” portion that I would have presented, along with the blasting. So my reply would have been nothing but blasting.


Unfortunately I can’t top any of the posts before me. You got the main links around town and I can’t provide better ones. I just want to point out that I would have tried my best to provide you with some links over a day ago had I not felt a bit affronted by your initial post, which assumed I would do nothing but question your quest to learn ASM, which to me is a ridiculous concept (not learning something new is ridiculous).

People need a good reason to start making a new game engine, not to start learning ASM.


L. Spiro
[/quote]

Well it's just that in the past when I've asked about this sort of thing on other forums, that was the reaction I got, that Assembly isn't worth it or it's too hard to learn, and whatnot. I wasn't saying that's what everybody thought, and I wasn't making a simple assumption, I was just merely going on previous experiences that have had people saying that I'm out of my mind. Of course that was a few years ago, and I'm back to this. I suppose I might've come across as the rookie that has no idea what he's talking about when I first asked about it, especially being that I was roughly fourteen then, sixteen now.

Anyway, the Intel developer guides seem to have quite a bit of information which I'm sure I'll be referring to a lot, but it's definitely a complicated guide. I guess I'll see what I can make of it.

Another potential way you can teach yourself assembly which is kind of "backwards" is reverse engineering your own C++ programs, this is pretty helpful if you get strange errors, while doing C++ coding. http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/index.html is the free book that is usually recommended to start with. I think if you have the money you should buy a book on assembly and go through it, its way more structured, and should be more beneficial. I am also not sure what flavor of assembly you intend to start with? Nasm, fasm, masm32? I started with masm32.

I am also not sure what flavor of assembly you intend to start with? Nasm, fasm, masm32? I started with masm32.

I've mostly been using NASM, I used FASM once to assemble a pong game that someone made with FASM. Although I do have one question, I understand that masm32 is a Windows Asssembler, I wouldn't be able to use it if I wanted to create my own OS, would I?

Sure you can. You just have to target the bare CPU and not use any OS-provided facilities.

[quote name='Spirrwell' timestamp='1340640994' post='4952691']
As for the portion where I said to spare me the lecture, I simply said that because I know that a lot of people think it's worthless, and I don't. Thanks for all of the links supplied,

No.
No, not at all. I was frankly going to blast you for that segment of your post specifically because it was a bit insulting that you had just assumed no one here could imagine that you had an understandable reason for wanting to learn raw assembly.
[/quote]

At one time posting that you liked C++ or assembly on gamedev was blasphemous. I can assure you his experience is certainly not unique.

Sure you can. You just have to target the bare CPU and not use any OS-provided facilities.

It's a bit more complicated than that. If you boot in real mode, you can use the BIOS to access a few services (print text on the screen, read and write from disks...). From within Windows you won't be able to access those things directly, and you won't be able to practice switching to protected mode, or organizing virtual memory, or anything else that requires ring-0 access.

Right... I consider anything that happens after leaving real mode to be "OS-provided facilities."

Assuming the OP is doing the sensible thing and developing on a VM that boots his code, that shouldn't be a major concern.

Assuming the OP is doing the sensible thing and developing on a VM that boots his code, that shouldn't be a major concern.

One step ahead of you

I have looked around at the my first OS programs out there. I've even managed to get them to work messing around with VirtualBox, Virtual Floppy Disk, and RawWrite.

Although I think that at this point it'd be best for me to install Linux so that I could also use QEMU.

Again, thanks for all the input... No pun intended there...