Quote:Original post by Crypter

Quote:
How can I call a kernel from the bootloader, the strange thing is, theres plenty of tutorials on how to make a boot loader, and how to make kernels but none show how to actually load one from another, any extra tutorial sources are welcome, (I get most of the info from osdever.net). Thanks.

Just jump to the address you load the kernel at. If you are in pmode,
you need to add the seg selector as well (Useually 08h). ie:

[BITS 32]; set up stack...; pmode jump to kerneljmp 08h:01000h

If the kernel (or second stage loader) was loaded at 0x1000:0,
execution will continue from there.

thanks, I actulally found a pretty good source written by xsism that shows how to dovelop a bootloader along with a C kernel.

Just one more question, a bit off topic but - what does it mean when a register is used for this or that, for example eax is an accumulation, ebx as a base pointer, ecx as counter - is that just a convention that was decided upon or are they really suited better to the tasks that they are labeled with, aren't registers just small fast rams next to the processor, so whats the difference which one you use for something?

Quote:Original post by Figgles

Quote:Just one more question, a bit off topic but - what does it mean when a register is used for this or that, for example eax is an accumulation, ebx as a base pointer, ecx as counter - is that just a convention that was decided upon or are they really suited better to the tasks that they are labeled with, aren't registers just small fast rams next to the processor, so whats the difference which one you use for something?

To say that programming an OS is "ambitious" is quite the understatement. Anyone who doesn't automatically that a Celeron processor sold in commidity PCs is an x86 processor doesn't deserve to either a) live or b) program. Go back to Java where they "create" RAM and have infinite processing power, where there are no such things as registers and "hardware". It just a magical box of Sun bytecode!

Or, before you post again, please, READ. Intel will SHIP you free books on the hows and whys of the x86 architecture FOR FREE. F*ck it, I will ORDER THEM FOR YOU if you give me your address.

You obviously aren't in any place even conceive of starting an OS. Hell, even if you understood x86 assembly language, you still aren't even close to being qualified at writing an OS. If you are lucky, it will boot. Maybe.

Any statement that naive makes me wonder whether you bend over with your pants down if I asked you to. OSes and MMORPGs... everyone just *has* to make one. From the ground up. With absolutely no clue.

Thanks for the feedback :), I appreciate any criticism, anyways I'm trying to make an OS not because I wanna show off my programming skills, but on the contrary, to gain them, in order to cover the gaps that you clearly listed.

Quote:OSes and MMORPGs... everyone just *has* to make one. From the ground up. With absolutely no clue.

lol, yea I don't like MMORPG posts either, but for me making an OS is an inspiring task that as you rightfully mentioned I know nothing about, and the Intel architecture books are way over my head both in terms of asm syntax they use as well as in theory. Thanks.

PS. If some is willing to answer my earlier question about regsiter naming, I'd appreciate it, Tim.

Meh. I love making a post on OS dev threads cauze everyone forgets that there are learning OS kits out there.
Like OS161 (used in my OS class) and Nachos. Both provide all the working knowlege of a kernel, devided
into convient assignments where you get to build up the OS.
I will say Nachos kinda sucks, but OS161 is a great learning tool. And since it runs on a fake MIPS machine
you even get to deal with some real assembly, and can see all the code for the drivers and hardware.
That and a book like Operating System Concepts(6th ed) ISBN: 0-471-25060-0 will get you headed in the right direction
without having to learn too much "real world" OS programming issues from the getgo.


----
Your other question on registers:

When you look at something like x86, the registers are used for things because the hardware assumes they are used for that.
(this relates to x86 having lots of specific use instructions that assume registers like the loop counter
are all set up to loop on)
When you look at something like MIPS or SPARC, the registers are used for things because of a convention
you can use them outside that convention if you are careful and/or you are not writing ASM that will ever interface
with other ASM code.
(since the processor has no register specific instructions)

This is the difference between CISC and RISC systems. Being that the CISC systems provide lots of
instructions that do many different things that you may or may not ever use.
The RISC provide a much smaller set of instructions that provide only basic functionality.
As such, on a RISC machine (MIPS/SPARC) you may end up writing 2+ instructions to take the place of 1 CISC
instruction.
(never done x86, but i hear there is a "loop" instuction, on SPARC/MIPS you need to do a SUB, COMP, JUMP to
preform the same functionality)
Each system has benifits and drawbacks, so dont assume more instructions is bad, a RISC machine may appear
to have less diection functionality, but the simplisity means the chip can process each instruction
quicker.

[Edited by - KulSeran on May 8, 2007 9:03:32 PM]

Quote:Like OS161 (used in my OS class) and Nachos. Both provide all the working knowlege of a kernel, devided into convient assignments where you get to build up the OS.

I looked it up but it seems to be more suited for a class environment, I think I'll just stick with online tutorials for now just to get some ground in OS dev.

Quote:When you look at something like x86, the registers are used for things because the hardware assumes they are used for that.
(this relates to x86 having lots of specific use instructions that assume registers like the loop counter
are all set up to loop on)

I see what you mean, so you can't put ADD resultant into ESP because that would not be just a number anymore but a memory address where the stack pointer will point to. Thanks =)

Quote:Original post by Figgles
To say that programming an OS is "ambitious" is quite the understatement. Anyone who doesn't automatically that a Celeron processor sold in commidity PCs is an x86 processor doesn't deserve to either a) live or b) program. Go back to Java where they "create" RAM and have infinite processing power, where there are no such things as registers and "hardware". It just a magical box of Sun bytecode!

[Some vitriol here...]

In fairness, there are two ways of approaching programming -- one from the viewpoint that it's a branch of maths, and you're dealing with a perfect, pure abstract machine; the other from the viewpoint that it's almost an electrical engineering task, that you're dealing with billions of little switches which have messy bits and undefined behaviour. At one end of the spectrum -- Lisp languages, Haskell; at the other -- C, assembly language.

Each have their benefits and it is worth learning as much as possible about each and knowing when to treat the computer as if it were a Turing machine and when to treat it as if it is were a Porsche. You'll become a better programmer for it -- learning that there are unsolvable problems, learning about different models of computation, etc.

Quote:Go ahead and do it. You'll learn something. I did the same thing. I wrote a little "OS," if you could call it that, which had a bootloader and a simple console driver. I called it "DumbOS." It was completely impractical and totally worthless, but I learned a lot about GCC, make, nasm, AT&T assembly syntax, x86 assembly, BIOS, virtual memory, process priority levels, etc., etc., etc. It was fun.

Seconded. It's not like you intend to release this to the general public, or use it to run a life support system -- it's a piece of fun, intended to teach you stuff. I also wrote a little 'O.S.' of sorts. Whilst it was crude, it taught me a great deal about the toolchain, C, and all sorts of operating system design considerations. It helped me improve my skills; but now I'm looking at the more abstract end of that spectrum I mentioned.