I was thinking of learning assembly language (it would be neat to be able to make really tiny executables, and plus which it's really lightning fast), and I was wondering if I should be worried about anything really going wrong during the course of my education (everyone makes mistakes ). Is there any risk of hardware damage? I wouldn't imagine there is, but I just want to be sure. Also, can some really simple and/or stupid mistake cause the whole machine to reboot? I only wonder this because I know how low-level ASM is (right next to the hardware), and it can be used for just about anything (provided that you have the skills/knowledge/time; in fact I think some viruses are written using it to minimize filesize and memory footprint).

I apologize if this seems like a really stupid question. And before you LMGTFY me, I looked up both "is assembly dangerous" and "is assembly language dangerous", both of which found nothing useful.

No, you shouldn't be worried.

You can do pretty much anything in a language like C that you can in assembler, so assembler isn't any more "dangerous".

It is a bit easier to have a crash in assembler language programs. There are classes of errors that you wouldn't have in a higher level language, such as stack errors. But on a modern operating system, a failure in a user space program does not cause the system (or other programs) to crash.

Hardware damage caused by software is rare. It is usually obscure things like setting the wrong parameters on devices (such as video or hard disk or flash ram) that lead to failures. It is not an assembly language issue. You could have a randomly generated sequence of assembler instructions, and not have any problems.

if you dont touch the harddisk or video you will be fine.

you can use system calls (int 80 ) to write to the hard drive as long as you do not touch things like format track or sector or write directly to the hard drive but write to an open file
these system calls are also available in C as well

Thanks for the reply. I guess this means I'm in the all-clear to search up a (hopefully) decent x86 ASM tutorial

Assembler language is no more dangerous than it is useful, in the context of userspace Linux applications. If the whole point of the exercise is for academic purposes, then go for it. If your intention is to write code that is for some OS-less target, then even better. If you think you will write something that anyone else will be interested in using in an existing major OS such as Linux, Windows, MACwhatever, etc, then you are probably wasting your time.
Perhaps you can contribute something useful to the OS that smeezekitty has been talking about.
One thing that is very useful about assembler language is understanding what is really going on when a compiler generates code. Understanding how memory is accessed and addressed is a very useful piece of knowledge, especially in the context of a language like C, where the concept of pointers comes directly from the use of pointers in assembler and the CPU instruction set.
--- rod.

Strictly speaking, you are wrong. Due to a coding error control may pass to data area, and in that area there can be data whose values represent instruction codes of HW access and/or system calls.

So, the really safe way of coding in assembly is either on a scratch machine or in a virtual machine.

To be exact, even in C/C++ the above dangerous scenario is possible - with, say, wrongly calculated function pointers.

If you think more about it, this is what system program loader is doing intentionally - it first loads program from an executable file - this putting data into (meanwhile) data area, and then passes control to that (previously data, now code) area.

one thing that is very important in ASM is alignment.
and you could crash your code very easy for example you can write over code by loading labels (do no attempt ):

the descriptor tables that handle the virtual memory prevent the CPU
from fetching instructions from data segments there simply is no way to execute data that's what protected mode means

that code would throw a segmentation fault the code segment is NOT writable
even IF it could run it would over write the push instruction and part
of the mov word cs:LABEL,ax instruction
witch may or may not cause a problem depending on wither or not that code was executed again

have you ever looked at the linux kernel sources
assembly is still alive and well there are more programs with assembly
mixed in to them than you think anything with a deep need for speed
or anything that needs to be ultra small
some things are easy in assembly that are next to imposable in HLLs
the one and only downside to assembly is that it is not portable
learning assembly is the best thing to learn for a deep understanding
of how computers work right down to the logic gate level and on up to
algorithms

Even in 'gcc' "C", as regular user, I can execute code from data.

well you found a bug in gcc or the kernel
please report your bug to both the kernel and gcc maintainers
the data is being put in to the code segment or the local descriptor
tables are being written wrong

Try dr paul carter's tut or programming from the ground up

Links:

http://www.drpaulcarter.com/

http://programminggroundup.blogspot.com/

I believe he's referring to thunks, JIT and such.. Without the NX bit set on a page, you can execute whatever you like on the stack or heap - the processor doesn't really care inherently, it's just memory.