Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Dex wrote: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 .
I think you're missing the point. Let's say you have a bug that requires you to fix 300 lines of code (maybe it's a bad one). If that bug is a logic bug and not architecture-specific, you'd have to fix it in all code lines for all architectures. If you use a portable language like C, you're going to be fixing about 300 lines of code. If you use asm for each code line, you'll have to fix about n times the amount of code, where n is the numbers of architectures you support.
Again, this is not a concern for hobbyists, but in commercial-grade software development you'd be hard pressed to find enough experts on your various architectures to keep all the code lines well-maintained. A lot more people know C, so it becomes a lot more cost-effective to maintain platform specific code written in C.
If you're saying that asm code tends to have fewer bugs than C code, that's another argument altogether (one I'm not even going to waste my time on...).
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
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!)
You could write a Lua interpreter that runs directly runs on the hardware, and use GRUB to pass it a startup script. Then have as much as your kernel as possible and all your device drivers big Lua scripts. An interpreted kernel would run awfully slow.
MessiahAndrw wrote:An interpreted kernel would run awfully slow.
LuaJIT solves that (even though the standard Lua VM is rather speedy anyway).
Ok. I am using that as my interpreter. Very cool
Edit: Looking at the lua code, it doesn't actually use much! It uses standard C headers, sure, but none that can't be relatively easily coded (apart from maybe malloc). LuaJIT shouldn't use much more, either. So, with a few patches to the source code, statically linking Lua into a basic kernel would be possible... and that's that.
Dex wrote: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 .
I think you're missing the point. Let's say you have a bug that requires you to fix 300 lines of code (maybe it's a bad one). If that bug is a logic bug and not architecture-specific, you'd have to fix it in all code lines for all architectures. If you use a portable language like C, you're going to be fixing about 300 lines of code. If you use asm for each code line, you'll have to fix about n times the amount of code, where n is the numbers of architectures you support.
What about starting only with one architecture and, when it's really bug-free (with fairly complete design) start to port to another architectures? That should help make for a more predictable situation.
ehird wrote:
Edit: Looking at the lua code, it doesn't actually use much! It uses standard C headers, sure, but none that can't be relatively easily coded (apart from maybe malloc). LuaJIT shouldn't use much more, either. So, with a few patches to the source code, statically linking Lua into a basic kernel would be possible... and that's that.
You could try writing a minimal program with embedded lua, linked in statically, then ask objdump to list symbols it imports from system libraries, to get an idea of what you need to implement.
IIRC you can leave most of the stuff like files and whatever out of the interpreter if you want, which should reduce the amount of code that you need to supply.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
~ wrote:What about starting only with one architecture and, when it's really bug-free (with fairly complete design) start to port to another architectures?
Heh... As a commercial software developer, I have to laugh pretty hard about something being "really bug-free". Especially when new features keep getting added over time (to which the same argument applies).
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
Combuster wrote:
I like assembly because you can easily see what something does. Since register calling conventions are far easier than passing on the stack i have been avoiding C, to the point that when it pays off, basic has become more suitable for the task.
Remember, u need to push & pop the registers u've used in your code, so it would end up with the same number of pushes & pops as the C would do.
Sorry, my reply comes too late, but i've to comment
Thanks
Systems and Computer Engineering Researcher
"Do you pine for the nice days of Minix-1.1, when men were men and wrote their own device drivers?" -- Linus Torvalds http://sce.carleton.ca/~maslan
Assembler wrote:
Remember, u need to push & pop the registers u've used in your code, so it would end up with the same number of pushes & pops as the C would do.
Except that if you check the output of a typical compiler, it doesn't necessary push/pop at all. Having tried writing a compiler, it's often easier to simply address from the stack pointer, generating loads/stores with offset, and then just adjust the stack pointer separately for function calls. On modern computers this is usually just as fast (if not faster) than using push/pop.
The advantage of the method is that you can allocate/deallocate space in the stack simply by adjusting a variable inside the compiler, without generating any code. You only need to touch the location when you want to load/store a value, and you can't cache it in a register, and you only need to touch the stack pointer when you need to adjust it for a call.
Ofcourse you can use the same method when writing in assembler, and on architectures that don't offer push/pop, you kinda have to. Not that it makes the spirit of your statement any less valid. Just thought I'd mention.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
MessiahAndrw wrote:An interpreted kernel would run awfully slow.
LuaJIT solves that (even though the standard Lua VM is rather speedy anyway).
*partially joking* who cares about performance, in another year, the new computers will be fast enough to run my software, *cough* vista *cough*
This mentality works to an extent, in that (some) speed needs to be sacrificed for convenience, but its not an excuse to be a lazy coder!
I agree..
If you must interpret your kernel in LUA and you see a use for it (or just to prove it can be done), then sure, sacrifice some performance and go ahead - amaze us all! But, if you're just just a lazy coder and think it's easier to write tens of thousands of lines of bloated LUA code than using C/ASM, you'll be popular for all the wrong reasons..
.
