Making OSes without assembly.

[god0fgod]

To make an OS with languages like C you still need assembly in there but I've ben wondering why I know of no languages which can be used to write operating systems with no need of assembly. Has there been any languages like that? Would a language like that be a good idea? I think so.

[xvedejas]

Trust me. You *want* to be able to use at least some assembly, at least on x86.

[god0fgod]

Why do you want to? If there was a language which allowed you to do everything assembly does but adds high level features such as expressions, wouldn't that be a good idea?

I know almost nothing about almost all assembly languages, I should say. I've only used PIC assembly before. I'm just curious.

[NickJohnson]

There are many instructions that are unique to the architecture of the processor (for example, the x86's "lgdt" doesn't even exist as a concept on the PowerPC), which would be therefore out of place to implement in a high level language. Even if such a language existed, a kernel written in it couldn't possibly be perfectly portable anyway. It's much easier to add just a bit of assembly to a high level language either as a separate file or with inline assembly.

[god0fgod]

I thought there would be some sort of abstract view which encompasses various architectures and allows for everything required in making an operating system. Different processors may use registers and instructions which do completely different things but ultimately don't they do the same thing? Some processors do more than others but couldn't you just implement an advanced feature of one processor in another by compiling more machine code for it?

[NickJohnson]

Sort of - there are some holes, but usually you can get a homogeneous interface. However that is what an OS is - a layer that lets you create programs without caring about how the hardware works. If you encapsulate the assembly, you will simply have written an OS containing assembly, thereby defeating your original purpose.

[god0fgod]

What I meant was the compiler could add the extra machine code required for some processors for you.

The reason I was thinking about this in the first place is because it must take lots of people, hours to write OSes, hence why most OSes today base their kernels from OSes decades ago. I thought those that work on such low level programming would love to be able to do it easier and quicker.

And I was especially thinking of the issues when trying to make portable operating systems across different architectures. From the little I know even making OSes for 32-bit and 64-bit versions of architectures is a pain, right?

Maybe such a programming language wouldn't be used for practical OSes because it may not give the level of detail and performance required but for research, wouldn't quick testing of different ideas be ideal?

Thank you for the answers.

[smoothCoder]

godofgod:

Please dont try to make an OS if you hate/don't know/try to avoid ASM, becouse this will be a crappy OS.
If you wan't to learn ASM, and you want to make fastly some OS, you can make one that run on top of another OS just like ordinary .exe. I remember seeing OS like this but don't remember names. You can jump over the part of hardware support of an OS and go to the other parts of an OS, like task management, process priority etc. To you to understand what I'm trying to say, just imagine you program your own invented processor, then write an emulator in even scripting language for it and then write an OS in even JavaScript that emulate on all this futurama-environment.

PD: A personal counse: if you don't want to touch ASM, go and programm web pages!

Cheers!

[god0fgod]

Write an emulator for a made up machine? That seriously would be more efficient than if there was a programming language for operating systems?

All I am is curious. I'm not going to make my own OS, today at least. I'd probably use an open-source kernel anyway and make my own GUI (The GUI is the fun bit right?) unless other kernels are too hard to understand it's better making one from scratch.

I don't need to use assembly language for anything I'm doing right now. I like to program applications in high level languages.

I was also thinking about when I was discussing programming languages with someone else the other day who thought making a new language would be a good idea.

[smoothCoder]

There is too much languages in the world, no need for another.
You have to keep researching with patience and some day you will have your hobby-OS, but keep in mind that if you want to make your OWN operating system, no matter the language you use, it will take much time. Be prepared for this!

Cheers!

[Owen]

The thing is, that from the point of view of the kernel and device drivers (And even much of the low level userspace), things can be vastly different. For example:

• Segmentation (x86), or lack thereof on modern architectures (m68k, RISC)/vestigial forms of it in revisions of older architectures (x86_64)
• Interrupt delivery - All through one address? (most RISC), through table (most CISC)? Multipl IRQ levels (NMI? FIQ?)
• Paging - page size, table structure, configuration, address space identifiers, domains
• Caches - virtually tagged (ARMv5) or physically tagged (ARMv6, x86)? Have to flush during context switch? Cannot have same physical address mapped to multiple virtual addresses? Coherent with DMA? Incoherent with DMA? Multiple independent levels of cache coherency (e.g. ARM coherency domains)?
• Access to kernel resources during context switches (e.g. kernel stack)
• Entering userspace
• System calls - from the simple (ARM, just SWI) to the complex (x86: software interrupt (INT x), call gate (CALL FAR gateSel:ignoredOffset), SYSCALL, SYSENTER, INT), to the common but complex (Known illegal opcode trap - UD/UD2 (x86), A traps (m68k))
• Saving program state (registers!)

To put it simply - if such a programming language existed, it would be most of the work of implementing an OS, and interfere rather heavily with how you implemented your design.

[god0fgod]

Wikipedia said "almost entirely".

[gerryg400]

In my opinion c does almost everything required to write an O/S. I have less than 200 lines of assembler in my O/S. I think by the time it is working my OS will be around 10 klines. The only assembler you really need on x86 is for reading and writing registers (control registers, segment registers) and IO space, and for manipulating the stack on kernel entry and exit. Much of this can be done with inline assembler functions that become part of your c library.

[Brynet-Inc]

OS development is a low level task AND a high level task, someone who only enjoys the comforts of high level programming should not considering writing an OS.

BSD, as an example, abstracts away as much of the MD (..machine dependent) from the MI (..machine independent) portions of the kernel so that userland is comparatively similar between many different platforms.. the task of providing this illusion is the burden of an OS developer so that high level programmers can remain blissfully ignorant of these things.

If you're interested in writing an OS, you need to come to terms with the fact that it's going to be running on real machines.. with real hardware that must be configured and managed.

Some design concepts can be shared between systems, but the actual implementations will differ, and you need to deal with it.

[rdos]

I don't think that C/C++ belongs in a OS kernel. If you can write code in C with no assembly, chances are the code does not belong in the kernel.

I have no C-code in my kernel. I have some plans for a C/C++ interface using Open Watcom for writing some complex filesystem drivers, but other than that, the need does not seem to exist. At least not for an experienced assembly-programmer.