Full ASM OS?

inflater · Post by **inflater** » Fri Mar 30, 2007 8:38 am

My OS is:

Boot sector - 100% ASM (could anyone do it in other language?)
Bootloader (IRQs, INTs,etc) - 100% ASM
Drivers - 100% ASM - under development

Kernel - 60% Borland Pascal, 40% ASM

inflater

ehird · Post by **ehird** » Fri Mar 30, 2007 8:46 am

niteice wrote:
Alboin wrote:An internal scripting language for use in the OS sounds pretty cool....
My plan was to embed Lua in the kernel. One would be able to modify the entire kernel on-the-fly, uploading new code at any point. Insecure? Quite. It would be awesome to actually pull off though

I could start porting emacs to use lua if you wanted

(Actually, after finishing a basic "learning OS" I'm going to try something like that... kernel upgrades without rebooting!)

anon19287473 · Post by **anon19287473** » Fri Mar 30, 2007 1:45 pm

ehird wrote:
niteice wrote:
Alboin wrote:An internal scripting language for use in the OS sounds pretty cool....
My plan was to embed Lua in the kernel. One would be able to modify the entire kernel on-the-fly, uploading new code at any point. Insecure? Quite. It would be awesome to actually pull off though
I could start porting emacs to use lua if you wanted

(Actually, after finishing a basic "learning OS" I'm going to try something like that... kernel upgrades without rebooting!)

Like patches? What if two programs try modify the same stuff.

Insecure? Quite.

It's a hobby OS, and unless you plan for it to become more, it doesnt matter how secure it is. It's likely nobody but you will have any idea how exactly it works.

carbonBased · Post by **carbonBased** » Fri Mar 30, 2007 8:30 pm

I'll soon be porting to MIPS and Sparc... writting each port in pure asm would have me dead by 30...

--Jeff

Dex · Post by **Dex** » Sat Mar 31, 2007 10:26 am

I am working on a ARM port of my ASM OS, and i must say, that to port something in ASM, is not that hard. The hard part is doing anything the first time.
To get to the stage that taken me 1 year the first time (x86), took me about 1 month to port it to Arm. This is on top of leaning ARM way of doing things.

I remember the days i spend trying to compile simple C code, written for a differant C compiler, the error messages it did not seem too portable between differant C compilers, never mind prosesors

Alboin · Post by **Alboin** » Sat Mar 31, 2007 11:18 am

Dex wrote:I am working on a ARM port of my ASM OS, and i must say, that to port something in ASM, is not that hard. The hard part is doing anything the first time.
To get to the stage that taken me 1 year the first time (x86), took me about 1 month to port it to Arm. This is on top of leaning ARM way of doing things.

How is this? Doesn't the ARM architecture have different instructions, and all? Wouldn't you have to rewrite every instruction to fit the ARM set? Hm...

Brendan · Post by **Brendan** » Sat Mar 31, 2007 11:50 am

Hi,

~ wrote:How many people are developing their OSes fully in assembly (or at least the main kernel/drivers), and why?

My (long term) plan is to write the kernels, some device drivers and a few other pieces in 100% assembly until I've got an OS that can handle a development environment on a few of my computer/s (rough GUI, file systems, etc).

When I get to this point I'll want to write a interpretted "intermediate language" - a portable low level language that looks a bit like assembly. Then I'll write a NASM/YASM assembler in this language, followed by a compiler for the language (and then compile the assembler and compiler).

Once I've done this I'll extend the interpretter and compiler to handle a "BASIC like" language. Lastly, I'll write an IDE in this "BASIC like" language (possibly followed by support for other languages - PASCAL, C, etc).

This mostly makes me "100% assembly" for the next 5 years at least...

Cheers,

Brendan

Dex · Post by **Dex** » Sat Mar 31, 2007 12:13 pm

Alboin wrote:
Dex wrote:I am working on a ARM port of my ASM OS, and i must say, that to port something in ASM, is not that hard. The hard part is doing anything the first time.
To get to the stage that taken me 1 year the first time (x86), took me about 1 month to port it to Arm. This is on top of leaning ARM way of doing things.
How is this? Doesn't the ARM architecture have different instructions, and all? Wouldn't you have to rewrite every instruction to fit the ARM set? Hm...

Sure, but when you come down to coding your OS, most of the time is spent finding how something works and how you do certain parts of your code, once you have a road map (the OS your porting) and know what parts you need to port your OS, its much easier, has you know how it basically works and the writting the coding bit is only about 5% of the work.
Here is a very easy example, anyone who know x86 asm OS Dev, will see the basic of porting there OS to say ARM

Code: Select all

:****************************************;
; ARM BootLoader.                        ;
;----------------------------------------;
; Prog by Dex.                           ;
; Coded with FasmARM.                    ;
; Part of the the x86 to ARM Dex4u port. ;
; C:\fasmarm ArmBoot.asm ArmBoot.bin     ;
;                                        ;
;  C  Bamford.2006(c)                 ;
;****************************************;
format binary
org	0			      ; code starts at offset 0.
use32				      ; use 32-bit code.

        b     reset                   ; This in x86 is the same as "jmp label"
        b     undefined_instruction  ; jump label.
        b     software_interrupt  ; jump label.
        b     prefetch_abort  ; jump label.
        b     data_abort ; jump label.
        b     not_used ; jump label.
        b     irq ; jump label.
        b     fiq ; jump label.

align 4

;********************************;
; just Loop For Now ;)          ;
;********************************;
reset:  ;label

LetsLoop:  
	b LetsLoop  ;just loop forever

;********************************;
; just Loop For Now ;)           ;
;********************************;
undefined_instruction:  ;label
software_interrupt:  ;label
prefetch_abort:  ;label
data_abort:  ;label
not_used:  ;label
irq:  ;label
fiq:  ;label
LetsLoopForNow:
	b     LetsLoopForNow ;just loop forever

times 20000- ($-0)  db 0 ; just pack the file out with 0

This would work in all arm chips, all a Arm does on booting is load 4k from nand to beginning of ram and jumps to the "b reset ", now you know how long it took you to setup yout IDT in pmode gess were you end up if you do a software interrupt with a ARM chip, that right at the software_interrupt address, same with IRQ etc.
Now with a little work leaning differant instructions, you should be able to set your int up no problem, this is just a example it the same for all the building blocks of the OS.
NOTE: You would put code to deal with int etc at the right label.

DexOS running on GBA/DS http://www.dex4u.com/images/gbademo.jpg

This is cool debugging your ported OS, with your own OS

http://www.dex4u.com/images/gp2x.jpg

anon19287473 · Post by **anon19287473** » Sat Mar 31, 2007 12:26 pm

Ask the lead dev, personally I don't know the specifics; and even putting aside the (arguable) speed gains, it's a modern, real time, self hosting, GUI operating system (w/ IP stack and all the features you'd expect) written completely in ASM (with the exception of a few ports, namely SDL and Doom, which were compiled with the sphinx compilier, it has REALLY bad optimization). It definitely demonstrates it's possible to write such a big project in ASM, and well.

Colonel Kernel · Post by **Colonel Kernel** » Sat Mar 31, 2007 12:40 pm

Dex wrote:I am working on a ARM port of my ASM OS, and i must say, that to port something in ASM, is not that hard. The hard part is doing anything the first time.

What about ongoing maintenance? What you say may be true for the first time you re-write your OS for another architecture (it's rewriting, not porting, if you literally have to rewrite every line of code). But what happens if you've got 8 different versions of your OS for 8 different architectures, and have to deal with fixing bugs across all of them?

This may not matter to you as a hobbyist, but if your OS is ever to gain wide-spread acceptance, you should expect to spend a lot of time maintaining and enhancing it. What happens when you want to add a new feature to the OS on all of the architectures you support? It would be a pain in the butt, IMO.

Dex · Post by **Dex** » Sat Mar 31, 2007 4:19 pm

Colonel Kernel wrote: This may not matter to you as a hobbyist, but if your OS is ever to gain wide-spread acceptance, you should expect to spend a lot of time maintaining and enhancing it. What happens when you want to add a new feature to the OS on all of the architectures you support? It would be a pain in the butt, IMO.

But that would be the same for say linux, you need to adapted your OS for differant architecture, so you are always going to need, differant team to bug fix and maintain the differant prosesor ver's

ehird · Post by **ehird** » Sat Mar 31, 2007 4:23 pm

No, because C is more portable. You only have to maintain some parts.

Brynet-Inc · Post by **Brynet-Inc** » Sat Mar 31, 2007 4:34 pm

ehird wrote:No, because C is more portable. You only have to maintain some parts.

Exactly, You can keep a lot of code easily maintained that'll compile on a wide range of CPU's.. C is very portable..

Crazed123 · Post by **Crazed123** » Sat Mar 31, 2007 4:44 pm

At least as portable as any other VAXocentric language, certainly.

Dex · Post by **Dex** » Sat Mar 31, 2007 6:06 pm

So what this for http://www.dslinux.org/bugs/
Do not get me wrong, i am not saying C is not portable, it's very portable, just like a tent is very portable, but tents make s**t home's

.

OSDev.org

Full ASM OS?

Is your OS fully programmed in Assembly?

Re: Full ASM OS?