OSDev.org

bluemoon wrote:

SparrowOS wrote:However, my compiler is very fast and it needs to be for JIT operation.

Great, but is that somehow related to this topic which I couldn't figure out?

Optimizations add to compile time. When you compile as an app is launched, you need a fast compiler. The C language offers very exact hints to the compiler so it doesn't need to waste time. The C language is one-to-one almost on asm instructions, unless you code sloppy and let the compiler optimizations fix it.

Griwes wrote:The closeness of mapping between the language and machine code makes sense only in few parts of kernel, and of course, in those parts, you write mainly C, even when writing C++ - PODs, raw and literal pointers etc. - but in some parts it doesn't matter what the machine code is; with proper abstraction, your scheduler shouldn't care about the machine in question - only the lower level constructs, like arch-specific context switcher etc. - so in those parts, you don't need mapping to machine code, but abstractions that are easy to work with.

It seems you're arguing just for the sake of arguing.

I did not argue whether "the closeness of mapping between the language and machine code makes sense" in every or any part of the kernel. I did not argue whether it matters what the machine code is in every or any part of the kernel. I did not suggest C because of its convenient level of abstraction.

I merely suggested that C is a good choice of language in direct response to the OP's expressed wish to keep the kernel lightweight. If you want to reduce the weight of your kernel by choice of language - you pick a lightweight language to write it in, and I was talking about C only in regard to it being lightweight.

Griwes wrote:don't discriminate C++

Did I?

I see that you're using C++ in your project. By now, I also assume that because of my encouragement to use C you think I'm in some sort of a C camp. Currently I don't use, surprise, C.

If C was out of the question, and I had to suggest another lightweight language for kernel development, surprise, it would be C++.

Griwes wrote:Not to mention that it's prettier and superior </flameish mode>, but let's not turn this into yet another language flame war.

It seems you're the one eager to start "yet another language flame war" here.

Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Did I?

You did, by putting only C there, again, as opposed to "system programming language".

It seems you're the one eager to start "yet another language flame war" here.

Oh, c'mon, I thought that you can into sarcasm.

Let's not have a "holy war" here; ultimately, the design is much more important than the language in which it's implemented.

On an unrelated note, QEMU doesn't seem to support the Raspberry Pi's graphics chip. What's the best way to get graphics while I'm testing in QEMU?

blm768 wrote:On an unrelated note, QEMU doesn't seem to support the Raspberry Pi's graphics chip. What's the best way to get graphics while I'm testing in QEMU?

BGA?

dozniak wrote:

blm768 wrote:On an unrelated note, QEMU doesn't seem to support the Raspberry Pi's graphics chip. What's the best way to get graphics while I'm testing in QEMU?

BGA?

Possibly, but I'm not sure if it supports it in ARM mode. After some Googling, I think I've found a potential solution.

As another possibility, I might just run it on the Pi and forget about emulation. That way, I don't have to write two drivers at once.

Griwes wrote:

Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Did I?

You did, by putting only C there, again, as opposed to "system programming language".

"White people have lighter skin than any other race."

"White people are better than any other race."

Which is discrimination?

blm768 wrote:As another possibility, I might just run it on the Pi and forget about emulation. That way, I don't have to write two drivers at once.

You know that Pi graphics card is proprietary proprietary?

dozniak wrote:You know that Pi graphics card is proprietary?

Yes, but there's a publicly available datasheet with the information I need to at least get a basic framebuffer. For the 3D acceleration, I might be able to port the Linux drivers; they're implemented as an open-source wrapper around a binary blob.

I've been looking at the specifications for the interrupt system on the Pi's SoC, and it looks like it's surprisingly limited. Apparently, it doesn't support an interrupt vector, so I have to manually query bits in a memory-mapped register. That's not too bad, and I've dealt with a similar system when writing code for the GBA. What worries me is that the text mentions the need to be prepared for nested interrupts without stating that such preparation is only needed when the ISR has re-enabled interrupts in the CPSR. It seems to be implying that nested interrupts are the default on this chip, which feels extremely strange for an ARM system. Could it actually be this way, or am I just misreading the documentation?

I guess this makes a triple post, but I think there's enough delay to justify it...

Anyway, I've finally gotten interrupts working. I guess that my next step is setting up paging, which shouldn't be too tough... I think. I'll probably just use a linked-list allocator for the physical pages; allocating virtual pages is obviously a bit hairier, so I'll have to look at some algorithms on the wiki.

Before I can do any of that, though, I need to parse the ATAGS so I can get a memory map. Is there a good reference on the format somewhere, or will I have to just poke through the rather thick-looking stuff I can find on Google?

I switched to ARM several years ago as a development platform. Working with ARM boards has gone very well and they are usually easy to find information about the ARM boards, both from ARM themselves and the board manufacturer. Also ARM in my opinion a much nicer processor to work with than x86.

I previously worked with x86 PCs but I found that ARM boards was much easier to work with as they don't have the legacy baggage as well as complex configuration with ACPI and EFI. There is just simply a lot of technologies I have to support. There is nothing wrong with ACPI and such but they might slow down the actual OS development as you must focus on these technologies. ARM boards are more "naked" and there is a smaller threshold to get started and focus on the actual OS design.