Learn Assembly language before other high level languages?

[ponnan]

Sorry if I sounds mad...I have a some knowledge in c++ programing language. But I have been wondering if I can learn assembly language so that I can play with my pc as I like by programing it, creating DOS like programs and so on...but in my research I came to know assembly language differs from system to system . If it is so how can i learn assembly language . And plz tell me if I am on the right path in programing . Plz help

[rubberman]

Assembly programming is rarely needed these days. My last assembler coding was over 20 years ago, to write a device driver for a real-time operating system. These days, you don't often need assembler to do that, with a few exceptions. 98% or more of the Linux kernel is in C, with some assembler for very low-level necessities, such as in the C functions to control DMA, etc. Consider the C language instead to start. It is often considered a "high-level" assembly language.

[ponnan]

but I have another confusion ..when booting an operating system from cd , at time of installation there is no os that controls the installation..the installation window is created on the screen directly......... how is this done? plz help

[Ancient Dragon]

It's called a bootloader (see this link). I never wrote one, so I can't really help you out with that.

[mike_2000_17]

I agree with rubberman that you don't really need to know assembly these days for most tasks. There are still some dark corners in which you will find assembly code, which mostly include very low-level pieces of things like operating systems or compilers, very critical functions that need nano-optimization (i.e., simple functions that are called so often that every clock cycle counts), and very tiny hardware platforms that don't support anything else (e.g., programmable integrated circuits (PICs), which typically just run a simple input-output mapping via a few lines of assembly code). The point is, today, if you are writing assembly, you are probably writing a very short piece of code for a very specific purpose. People simply don't write anything "big" in assembly, and frankly, I doubt anyone ever did, even back in the day (it's just that small systems were the norm back then).

However, it is very common in the programming field that people know how to read assembly, more or less. As a programmer, especially in some performance-critical areas, you occasionally encounter assembly code, but as a product of compilation. For example, you write a program and you want to know what assembly code the compiler produces when compiling it (which you can get with the -S compiler option). This can be useful to see how the code is optimized, if you need to change anything to get it to be more efficient once compiled, etc.. Then, there is also the occasional debugging tasks that involve some disassembly of code (and stack frames). But in general, this skill is acquired with time. If you do the kinds of things that exposes you to assembly code, you'll pick it up as you go along. For instance, I would not be able to write anything in assembly (well, maybe a small function), as of right now, but I can mostly read assembly when I see it, and I sometimes look at assembly listings of some code I wrote to verify how it's optimized at the end, and that's all I ever needed to be able to do.

assembly language differs from system to system.

That's true. Assembly is not portable between different processor architectures. And also, assembly listings (the assembly "source code", i.e., what the assembler turns into machine code, and what a disassembler produces from machine code) also comes in different syntax, like Intel or AT&T syntax. The syntax is just the rules (and order) of the things you can write (operations, operators, etc.), which is, obviously, very simple because there isn't much that is needed for assembly. So, yeah, you cannot write portable assembly code, and that's one of the reasons it is so rarely used, because you have to write a version of it (e.g., the function) for every target platform and assembler/compiler combination.

at time of installation there is no os that controls the installation.. how is this done?

I think you are mistaken about the role of the operating system. Code written in "native" languages like C / C++ / Fortran / D / ..., are all compiled into native machine code for the target platform. When you have that compiled code (a binary executable file), then you don't actually need an operating system to run it. You only need an operating system when you want to have access to certain functions that can useful, such as opening a file, or scheduling different threads of execution. The point is, you can write C code that does not use the operating system for anything, and run it without an operating system. Doing this requires a bit of configuration of the compiler (via options) to remove any system dependency, or removing the linking with the C run-time library, and stuff like that. But once you compiled this code, you can just run it.

As far as the "bootloader" goes, well, the bootloader is nothing more than an executable program that sits at the very start of the hard-drive (called the "master boot record"). When the computer starts up, the BIOS (a firmware tiny operating system) initializes a few things (basic graphics, detecting the CPU, the RAM, and the hard-drives), and then, it just finds the first bootable media (HDD, USB stick, CD/DVD, etc.) that has "something" (non-zero) in its master boot record (MBR), and then, it just starts executing whatever binary machine code is sitting there. That program is called the bootloader, and it's usually programmed in C (AFAIK).

Obviously, when you write a program, in C, that doesn't have access to an operating system, and doesn't have access to the standard C libraries (like "printf", or whatever), it makes things a lot more complicated because all these things have to be done manually, at a very low-level. This is why boot loaders are usually very simple, i.e., they contain a pointer to a position in the hard-drive where there's a starting image for the operating system, and it simply copies that raw image into RAM, and starts executing it, and because a lot of the OS libraries are now in RAM, they can actually be used, and things get a lot easier. But obviously, writing OS loading code is very tricky.

[rubberman]

@AD
25+ years ago I had to write an x86 boot loader for an OEM'd version of the QNX real-time operating system. I for one don't want to do that again! :-)

Unfortunately, these days I still have to delve into such crud - usually related to Grub, Grub2, UEFI, etc. How do you at a very early part of the boot process access the flash memory and firmware that controls the UEFI BIOS? Assembler of course. So, hit me with a brick, and I'll stop doing that! :-)

[rubberman]

@ponnan
If you want to learn about this stuff, get the source code for grub, grub2, lilo, and other Linux boot loaders (there are versions for x86, ARM, Power-PC, Sparc, and other processor families). Study that, experiment, and learn what is going on. At this point, we really can't help you much more as the only way to learn this stuff is get the source, get the documentation for your processor assembler/machine code, and then roll up your sleeves - you will have many sleepless nights ahead of you while you become an expert in the domain... :-)