Hi,
davidv1992 wrote:
Brendan wrote:
Given the choice between "write a large project to get experience writing large projects (but make it an OS so that you also get other relevant experience/knowledge)" and "write a large project to get experience writing large projects (but make it something where you won't get much other relevant experience/knowledge)"; why would anyone advocate an incredibly idiotic choice?
The main reason why I would advocate going for a compiler first (or possibly some other reasonably largish project) is because it takes quite a bit less time than an OS to develop (3 months vs 1-2 years). You get all the experience of working on a larger project without at the same time having to ditch a lot of the comforts that come from programming purely in userspace.
One of the reasons I'd advocate going for an OS first is that it gives you experience working on a larger project that you won't get from a smaller/faster project (like a simple compiler). Another reason is that you'll be able to recycle parts of the older code when you want to write a better OS (which you won't be able to do if the older code was for a compiler).
davidv1992 wrote:
It is a lot easier to first deal with complexity in an environment where you have the full power of something like gdb or the visual studio debugger available, with things like reverse debugging.
Yes; it is a lot easier to first deal with complexity in an environment like "Qemu + GDB" where you have the full power of something like GDB for debugging your OS. There's even tools (e.g.
VisualKernel?) that integrate "Qemu + GDB" into VisualStudio if that's what you want.
davidv1992 wrote:
Furthermore, the reduced time to get stuff that actually does interesting things significantly reduces the cycle time when developing, leading to more opportunities for learning.
Yes; the reduced time to get to stuff that actually does interesting things (scheduling, memory management, PCI enumeration, etc) reduces the time when developing, leading to more opportunities for learning boring stuff that doesn't help much with an OS project ( lexing, spending a month trawling through Intel manuals entering opcodes into a big table buried in a compiler's back-end, spending another 2 months tweaking "peep-hole optimiser" patterns, etc).
davidv1992 wrote:
Brendan wrote:
To write an OS; the amount of knowledge/experience you need with assembly language programming is mostly limited to the ability to cut&paste a handful of inline assembly macros from the wiki or anywhere else (unless you're hoping to write an OS in 100% assembly language, but in that case you can completely forget about C).
I personally found it rather useful when debugging to be competent reading assembly language instructions, and being able to trace (at least at a somewhat global level) what parts of my kernel functions they came from and what they do. This might be partly due to the fact that I primarily use my exception handlers and the bochs debugger to debug my code, but I find those a lot more useful for debugging some of the really low level stuff.
I personally found it rather useful to have an early background in digital electronics, because this helped me understand what a (6502) CPU was actually doing, which helped me learn (6502) machine code, which helped me learn 6502 assembly language, which help me learn 16-bit 80x86 assembly, which helped me learn 32-bit and 64-bit assembly, which helped me write OSs in 100% assembly and helped me understand what Boch's debugger is telling me.
Of course the only important part of my paragraph is "I personally". Most people here write code in C or some other higher level language, and use tools like GDB, and would therefore gain very little from spending a huge amount of time trying to follow the path I did. That is why I don't suggest "learn digital electronics" when people say they want to write an OS in C.
davidv1992 wrote:
Also, copy-pasting even simple assembly might not be the best idea for those chunks of assembly code one cannot avoid, as anything going wrong there can already be very tricky to debug, and not understanding what those pieces do precisely can make that bad situation even worse.
Sure; but spending a few years writing a compiler without knowing if you'll ever need that information is a whole lot less efficient than spending 10 minutes to ask someone if you ever actually need to.
davidv1992 wrote:
Also, I find that I do more than just little snippets in assembly, particularly in the very early boot code (I'm currently at ~300 lines of assembly across various files), even though i'm using grub as the bootloader, but again that might just be the way I decided to implement things.
For their first OS; about 90% of people will use something like GRUB and won't write any of their early boot code. I'd like to think that eventually most people will write their own boot code (e.g. for their second or third OS); but even then it's more likely that they'll write a UEFI boot loader in C.
Cheers,
Brendan