I could start porting emacs to use lua if you wantedniteice wrote: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 thoughAlboin wrote:An internal scripting language for use in the OS sounds pretty cool....
Like patches? What if two programs try modify the same stuff.ehird wrote:I could start porting emacs to use lua if you wantedniteice wrote: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 thoughAlboin wrote:An internal scripting language for use in the OS sounds pretty cool....
(Actually, after finishing a basic "learning OS" I'm going to try something like that... kernel upgrades without rebooting!)
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.Insecure? Quite.
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...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.
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).~ wrote:How many people are developing their OSes fully in assembly (or at least the main kernel/drivers), and why?
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.Alboin wrote: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...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.
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
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?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.
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'sColonel 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.
Exactly, You can keep a lot of code easily maintained that'll compile on a wide range of CPU's.. C is very portable..ehird wrote:No, because C is more portable. You only have to maintain some parts.
.
