OSDev.org

Glad to read this. Apparently you understand that ASM is the best. And I understand that its use is a denormal porcent number. Sorry I enraged a bit becouse all the world are becoming lazy, I am trying to form a team of ASM coders for my hobby-OS, but nobody want even to code in JavaScript. This make me sad. In 2020 all will be ****** in this world.

How did you manage to glean this garbage from Solar's post?

Let's ignore him.

smoothCoder wrote:Apparently you understand that ASM is the best.

*sigh*



That is not at all what I said.

I do understand that there is a wide spread of languages, and that ASM is at the extreme end of it. And I came to understand that writing software is about compromises.

ASM is the best language for its specific problem domain: high-performance 3D engine cores, boot sectors, first-level interrupt handlers, system call stubs, CPU drivers. Here, ASM reigns supreme, because it provides those hundreds of specialiced primitives no higher-level language would ever bother with.

But ASM is an extreme, uncompromising language. Once you move outside this specific problem domain, other, more abstract languages provide better compromises: Expressiveness, prevalence, maintainability start to reign over raw potential power.

You don't code websites in Assembler. You don't code kernels in JavaScript.

Of course, I would give to the user and developer an easy API, to program in C++/C, but at least the kernel, what will be permanent in all distridutions of an OS I thing should be entirely optimized in hand-code ASM.

gerryg400 wrote:Let's ignore him.

You are too lazy to think about what I am saying. I have include file of my idea, I will give it and you will include it easily. Have tutorial too.

smoothCoder wrote:Of course, I would give to the user and developer an easy API, to program in C++/C, but at least the kernel, what will be permanent in all distridutions of an OS I thing should be entirely optimized in hand-code ASM.

gerryg400 wrote:Let's ignore him.

You are too lazy to think about what I am saying. I have include file of my idea, I will give it and you will include it easily. Have tutorial too.

Your idea is not original, nor is it new. It was done in the 1960's, and was called UNIX. Then UNIX was rewritten in C. Assembler is nonportable, not scalable, and difficult to optimise.

Why is it difficult to optimise? Well, you know an awful lot less about how a certain chipset works than the people at Intel do. And the people at Intel maintain the GCC backend (and ICC). The people at ARM (my team) maintain the GCC backend for ARM, and ARMCC.

Not only that, but optimised code is often unreadable. Decent instruction scheduling will reorder instructions to an illogical order to avoid pipeline stalls, hazards and dependencies. So most of the time, readable assembler code is not optimised, and optimised assembler code is not readable.

It is therefore illogical and impractical to write a large system in, and that is why it is not used (except in the embedded sector).

James

Ok, you have the right!

Cheers!

smoothCoder wrote:Of course, I would give to the user and developer an easy API, to program in C++/C, but at least the kernel, what will be permanent in all distridutions of an OS I thing should be entirely optimized in hand-code ASM.

gerryg400 wrote:Let's ignore him.

You are too lazy to think about what I am saying. I have include file of my idea, I will give it and you will include it easily. Have tutorial too.

Why are you making this a personal attack ? You don't know me and you don't know what experience or knowledge I have and you certainly don't know whether I am lazy or not. I suggested that we ignore you because you are being abusive. From now on I'll take my own advice and I will ignore you.

When I made this topic, I wasn't looking for arguments over the benefits of using assembly or C. This topic is about my thought for a new programming language which encompasses all assembly features in a high-level format. Perhaps such a language would need different libraries for different architectures to put each processor a developer wants to write their OS for to best use.

I think C is an outdated language. I think someone earlier in the topic said there is no need for any more programming languages. I disagree. There is need I think for a language which is compilable and versatile like C but has a much cleaner syntax like python (Python is brilliant in many ways but it has major drawbacks such as not being compilable for high-performance applications). A good new language could also benefit from mixed static and dynamic typing. I'm sure all of you hate dynamic typing but in some cases it makes things much easier to do. Having it built into a language is a good idea in my opinion as long as you can still use static data types.

Much innovation can be done with programming languages.

M$ has some stuff for C# that you can use to "make an OS", but it is not REALY making your own since they do a LOT of things for you. Also the OS can only be for x86 (I am sure they will add x64 if they keep the project alive).

Has anyone made a library for x86 for C which add assembly parts for you and you simply use C functions to interface with the processor? It makes sense because I think processors like the PIC chips can be programmed with special C libraries.

Is another option to strip a HAL from another kernel and make the parts of top. Isn't the most simple hardware abstraction layer essentially similar to what I described as a architecture library? You can still implement your own memory management, file systems, thread management on top right? Surely, at the simplest level there is only one most efficient way of making basic abstractions anyway so why would you need to keep rewriting the basic level of abstraction?

Has anyone made a library for x86 for C which add assembly parts for you and you simply use C functions to interface with the processor? It makes sense because I think processors like the PIC chips can be programmed with special C libraries.

I suspect that most OS designers who use c already do this. It's not difficult to write functions like cr*_read, cr*_write, inportb, outportb, apic_read, apic_write, lidt, lgdt, etc. using inline assembler or separate assembler files that export c like functions.

On top of these functions you can then write functions like ioapic_mask, ioapic_unmask, cmos_read, cmos_write, etc. I imagine most guys who have been doing this for a while have a lot of functions like this.

So the original ignorant question has produced a set of ignorant responses from some of the ignorant members of the board. I like that.

god0fgod wrote:I think C is an outdated language. I think someone earlier in the topic said there is no need for any more programming languages. I disagree. There is need I think for a language which is compilable and versatile like C but has a much cleaner syntax like python (Python is brilliant in many ways but it has major drawbacks such as not being compilable for high-performance applications). A good new language could also benefit from mixed static and dynamic typing. I'm sure all of you hate dynamic typing but in some cases it makes things much easier to do. Having it built into a language is a good idea in my opinion as long as you can still use static data types.

It's pretty hard to have dynamic typing without runtime type inference (i.e. without storing the type of every variable along with its value), which is, depending on who you ask, not great for kernel programming. The other thing is that static typing acts as a nice double-check on the meaning of functions, and in system programming, it's better to be sure of yourself than to write code quickly. That said, you might want to look at OCaml, which has type inference, giving to it much of the brevity of dynamic typing with the same rigor (and efficiency) as static typing; although, the language does rely on garbage collection, which is also not great for kernel programming.

Remember when u go more close to hardware at that time u will need Assembly or inline assembly to communicate with hardwares. Becz C doesnot provides such facilities to communicate directly when u change status register, control register...etc..

By the way Assembly isnot too bad at all. It is also so cool if u understand it very well