OSDev.org

Posted: **Mon Jul 15, 2013 7:54 pm**

In what ways Assembly Language can specially help us to make an operating system ,when comparing to other programming languages like c,c++..?

For example: Controlling fan speed,data handling...

Posted: **Mon Jul 15, 2013 9:29 pm**

IdiotOS wrote:In what ways Assembly Language can specially help us to make an operating system ,when comparing to other programming languages like c,c++..?

For example: Controlling fan speed,data handling...

Here's a comprehensive list:

Other than that, most things done in assembly are done for a specific opcode not achievable in c/c++. (lgdt, lidt, ...)

Posted: **Mon Jul 15, 2013 9:47 pm**

There are also critical sections of an operating system that have to be written in assembly, since they can't be made to conform to C's stack requirements (i.e. that there is a stack, and that it follows the standard calling convention.) These include interrupt handlers and system call handlers, and sometimes certain paging or task switching routines, depending on the techniques used.

In addition, sometimes a skilled programmer can produce code that outperforms compiled C code for performance-critical pieces of the kernel. In general, system overhead is dominated by context switches and various mandatory cache flushes (and cache misses due to kernel memory footprint), so this is typically overkill.

Posted: **Tue Jul 16, 2013 1:54 am**

Assembly is a great choice whenever you feel development is becoming boring because you have too few bugs.

Posted: **Tue Jul 16, 2013 1:36 pm**

IdiotOS wrote:In what ways Assembly Language can specially help us to make an operating system ,when comparing to other programming languages like c,c++..?

For example: Controlling fan speed,data handling...

The operating system is supposed to control the hardware, and that involves things like interrupt handlers and access to i/o ports, which things can't be done in a high level language - at least not without some help from assembly language. There are also specialised instructions, like bts, which allows a lock to be set atomically, and that is a thing very hard to do without hardware support from the processor.

If you have a multi processor/multi core system, the processors will need to communicate with one another, and that is something else which can only be done in assembly language.

Most of an operating system can be written in C, but there is no way you will avoid getting your hands dirty with assembly language.

Posted: **Tue Jul 16, 2013 7:40 pm**

Casm wrote:
IdiotOS wrote:In what ways Assembly Language can specially help us to make an operating system ,when comparing to other programming languages like c,c++..?

For example: Controlling fan speed,data handling...
The operating system is supposed to control the hardware, and that involves things like interrupt handlers and access to i/o ports, which things can't be done in a high level language - at least not without some help from assembly language. There are also specialised instructions, like bts, which allows a lock to be set atomically, and that is a thing very hard to do without hardware support from the processor.

If you have a multi processor/multi core system, the processors will need to communicate with one another, and that is something else which can only be done in assembly language.

Most of an operating system can be written in C, but there is no way you will avoid getting your hands dirty with assembly language.

That's correct!

Posted: **Tue Jul 16, 2013 7:44 pm**

Casm wrote:
IdiotOS wrote:In what ways Assembly Language can specially help us to make an operating system ,when comparing to other programming languages like c,c++..?

For example: Controlling fan speed,data handling...
The operating system is supposed to control the hardware, and that involves things like interrupt handlers and access to i/o ports, which things can't be done in a high level language - at least not without some help from assembly language. There are also specialised instructions, like bts, which allows a lock to be set atomically, and that is a thing very hard to do without hardware support from the processor.

If you have a multi processor/multi core system, the processors will need to communicate with one another, and that is something else which can only be done in assembly language.

Most of an operating system can be written in C, but there is no way you will avoid getting your hands dirty with assembly language.

Is there is any programming language better than Assembly Language that can control all the computer hardware etc.(except : Machine Language)?

If it is many, list out that.

Posted: **Tue Jul 16, 2013 8:43 pm**

ultimately everything becomes assembly, no matter what you write it in (assembly is basically just human-readable machine code) so assembly becomes the ultimate control of the system, since what you write becomes exactly the result, and there is nothing that can be done that can't be done using it

on the other hand, assembly is very hard to write and maintain, generally results in hard-to-find bugs, can be difficult to port between different architectures, and anything non-trivial quickly becomes impractical due to difficulty and time necessary to write it in ASM

in other languages, you are not directly controlling the CPU, you are controlling the logic, therefore there can be nothing inherently in the language that can directly control the CPU... so basically any time you need to directly manipulate the hardware (rather than producing a result) then you need to use ASM, however its rarely used for more than a dozen lines (at a time), with the remainder written in another language (some people do write the whole thing in ASM, but that is the exception) -- note here for simplicity (and lack of personal knowledge/experience) i am ignoring HL-ASM languages which attempt to bridge the gap between these two

as for OS development, you generally combine a small amount of ASM with another language -- most people use either C or C++, but most languages can be used, as long as you can compile them natively, and avoid using libraries (in order to use the language library, you must first write the library... so languages which rely extensively on a complex library, or are designed for bytecode rather than native code, are poor choices) -- in general, the best choice is to use what you are most familiar with, since that language will be easiest for you to understand, however, if you do not have very extensive experience with any particular language, the recommendation is to use C/C++ because that is what is most commonly used, and is therefore used in most examples, tutorials and documentation, and will be familiar to almost everyone who may be able to give assistance if you need it

Posted: **Wed Jul 17, 2013 11:48 am**

IdiotOS wrote:Is there is any programming language better than Assembly Language that can control all the computer hardware etc.(except : Machine Language)?

If it is many, list out that.

No, there is no way of avoiding assembly language. When you are writing an operating system, a lot of things, such as the paging mechanism and page tables, which are architecture specific, and there is no way a general purpose programming language can implement features peculiar to a particular piece of hardware. Even if it could, it might not bother, because relatively few people would find themselves (for example) needing to switch the processor into protected mode.

You sometimes hear assembly language being loosely referred to as machine code. Insofar as there is a more or less a one to one correspondence between assembly language instructions and machine code instructions, that misnomer is excusable. A high level language simply cannot give you that amount of control over the hardware.

Posted: **Wed Jul 17, 2013 12:14 pm**

Actually, Oberon System is written using only Oberon, as the language has some facilities to address CPU registers directly.

Posted: **Wed Jul 17, 2013 12:46 pm**

dozniak wrote:Actually, Oberon System is written using only Oberon, as the language has some facilities to address CPU registers directly.

C compilers frequently have an extension which lets you embed assembly language into a C source code file, but it is still assembly language. Thare can, for example, be no instruction in a high level language equivalent to lgdt, or ltr, because they are very hardware specific.

Posted: **Wed Jul 17, 2013 12:47 pm**

Oberon System is written using only Oberon

I believe that is incorrect. The Oberon System is written mostly in Oberon (just as Linux is written mostly in C) but the Oberon language includes an in-line assembler for those obvious instances where assembly instructions are required.

Posted: **Wed Jul 17, 2013 2:09 pm**

Hi,

Casm wrote:
IdiotOS wrote:Is there is any programming language better than Assembly Language that can control all the computer hardware etc.(except : Machine Language)?
No, there is no way of avoiding assembly language. When you are writing an operating system, a lot of things, such as the paging mechanism and page tables, which are architecture specific, and there is no way a general purpose programming language can implement features peculiar to a particular piece of hardware. Even if it could, it might not bother, because relatively few people would find themselves (for example) needing to switch the processor into protected mode.

In theory it'd be possible to design a language such that it includes support for things that you'd otherwise need assembly for. For a simple example; you could design a special "80x86 only" language that includes built-in variables for control registers (CR0, CR2, CR3, CR4); built-in support for GDT, IDT and LDT; built-on support for atomic operations (including "atomically test and set a bit"); etc. Basically, instead of using inline assembly you'd add features to the language and compiler. The problem is that the source code won't/can't be portable; and there's no easy way to determine what everyone might want in advance (so you'd need to develop the language and its compiler while writing a kernel, and you'd end up with extensions to the language that are only useful for that specific kernel).

In practice; it's better and easier to allow the language to be extended in other ways (e.g. libraries and inline assembly; and things like macros and templates); so that different people can extend the same language in many different ways.

For example, someone could implement a library for C (that uses inline assembly) that's designed to make 80x86 kernel development easy. It could include things like GDT/IDT/LDT management, atomic operations, spinlocks, CPU state loading/saving (for task switching), IRQ hander stubs, CPUID support, IO port support, MSR support, functions for configuring things like PIC and PIT chips, functions for accessing CMOS, etc. Of course you could also include things like physical and virtual memory management in the library, and a scheduler, and some device drivers, etc. It'd be hard to know when to stop; and eventually people would be doing "#include <kernel.h>" and won't have any control over how "their" kernel works because they didn't write anything themselves.

IdiotOS wrote:In what ways Assembly Language can specially help us to make an operating system, when comparing to other programming languages like c,c++..?

I'd say that one of the most important ways that assembly language can help is that learning assembly teaches you a lot about the how the CPU actually works, and knowing how a CPU actually works helps you write better code in language like C or C++.

For a simple example, consider this:

Code: Select all

int convertToCelsius(int fahrenheit) {
    return (fahrenheit + 32) / 1.8;
}

If you don't know assembly and don't know much about how a CPU works this function looks fine. However; if you do know more you'd be tempted to write this instead:

Code: Select all

int convertToCelsius(int fahrenheit) {
    return (fahrenheit * 5 + 160) / 9;
}

..because you know it avoids conversions to/from floating point, and possibly because you've realised that the multiplication and addition can be done with a single fast instruction (e.g. "lea eax,[ebx+ebx*4+160]").

Note: For large values of "fahrenheit + 32" the conversion to floating point can cause a loss of precision; therefore the optimised code is not functionally equivalent to the original version. For this reason, a C compiler can not perform this optimisation itself. I would expect a C compiler to optimise the code into "(int)(((double)(fahrenheit + 32)) * 0.55555555555555)" though.

Cheers,

Brendan

Posted: **Wed Jul 17, 2013 2:37 pm**

Casm wrote:Thare can, for example, be no instruction in a high level language equivalent to lgdt, or ltr, because they are very hardware specific.

Why can't there be? Take a look at GCC's function attributes, for instance: http://gcc.gnu.org/onlinedocs/gcc/Funct ... butes.html – some of those are very hardware-specific (interrupt, for instance). I can very well imagine either a variable attribute “register” or even builtin variables which map to (obviously hardware-specific) registers:

Code: Select all

register uintptr_t cr3 __attribute__((register("cr3")));

or directly a variable called “__cr3” which maps to the corresponding control register.

The same could obviously be used for the GDT:

Code: Select all

register struct { uintptr_t base; uint16_t limit; } __attribute__((packed)) gdtr __attribute__((register("gdtr")));

I don't see the point why access to CPU control registers, I/O ports* or the creation of interrupt handlers should actually be impossible in all high level languages. Of course it would possible, if they'd be designed with that usage in mind (and as you see in the GCC function attribute list, there actually is already a way to create an interrupt handler in GCC-specific C (for certain architectures, at least – excluding x86)).

Especially when doing OS development, many of us feel already that standard C/C++ is often not sufficient. Take __attribute__((packed)), for instance – standard C makes no guarantee about the placement of fields in a structure, though sometimes, you need to know (for instance for network packet headers). This is already ignoring the fact that most of us (if not all) are horribly abusing C/C++ already by doing basically completely undefined pointer operations (ever casted an integer to a pointer that wasn't created by casting a pointer to an integer?).

So we're already using an extended version of C/C++ in an undefined way (most of us, at the very least). I see only one reason why we shouldn't just add more extensions to C/C++ which would make assembly optional: Because writing that bit of assembly is actually much easier. However, theoretically, we could do it. So there is no reason to say “we use assembly, because we must”, but rather, “because it is in some special cases easier than extending high level languages to do the same” (and “but GCC does not support the extensions you proposed” is not an excuse: GCC is free software, “just” patch it, if you really want to).

JAAman wrote:ultimately everything becomes assembly

That's the point. Since everything becomes assembly, your compiler is theoretically capable of emitting every assembly code you could also write yourself.

JAAman wrote:in other languages, you are not directly controlling the CPU, you are controlling the logic, therefore there can be nothing inherently in the language that can directly control the CPU...

And this, on the other hand, is wrong. Of course there can. There is no fundamental reason to restrict a compiler to emit only arithmetic-logical and branching instructions.

To conclude my opinion: We use assembly, “because it is in some special cases easier than extending high level languages to do the same”.

Also:

Kevin wrote:Assembly is a great choice whenever you feel development is becoming boring because you have too few bugs.

.
Yeaaaaaah, assembly can be a hell lot of fun!

*Especially accesses to I/O ports – inb and outb could well be just builtins directly provided by GCC.

Oh, fun fact, look, what I just found: http://gcc.gnu.org/onlinedocs/gcc/Expli ... -Vars.html

Posted: **Wed Jul 17, 2013 7:05 pm**

I don't see the point why access to CPU control registers, I/O ports* or the creation of interrupt handlers should actually be impossible in all high level languages.

Because that is not what high level languages do. The whole point of them is to use high level instructions which hide (and are not tied to) the underlying hardware.

JAAman wrote:ultimately everything becomes assembly
That's the point. Since everything becomes assembly, your compiler is theoretically capable of emitting every assembly code you could also write yourself.

The compiler emits whatever the compiler writer decided it should emit. Unless you are the person who wrote the code generator, you have no control over that.

JAAman wrote:in other languages, you are not directly controlling the CPU, you are controlling the logic, therefore there can be nothing inherently in the language that can directly control the CPU...
And this, on the other hand, is wrong. Of course there can. There is no fundamental reason to restrict a compiler to emit only arithmetic-logical and branching instructions.

A "high level" language which could do every thing you can do in assembly language would almost by definition not be a high level language. It would at least have to be some kind of strange hybrid.

OSDev.org

In what ways the assembly language can help us?

In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?

Re: In what ways the assembly language can help us?