[Deleted] Importance of interrupts(Generic question)

[pranavappu007]

This question no longer is relevant and as there is no delete option, I edited it to delete the content. Thankyou for all who helped.

[iansjack]

Not implementing interrupts is terrible.

Redesign your OS now before it gets too advanced. I'd strongly suggest avoiding the BIOS too. You don't need USB right now - run your OS in a VM until you are ready to write a USB driver.

[Octocontrabass]

Can I use interrupts with preserving the BIOS ones for using in real mode?

It's possible, but I think it would be easier to write a USB driver.

(Windows 95 did it. I suspect it's one of the reasons why Windows 95 had such a reputation for crashing all the time.)

[bzt]

Hi,

I agree with @iansjack 100%. You should definitely implement interrupts and more importantly, exceptions (they use the same IDT). The only difference is, exceptions are triggered by the CPU, not by the PIC, so you don't need to acknowledge them in PIC (simply speaking, implementation details are different of course).

Now my question is: Is not implementing interrupts bad?It works without the interrupts

Yeah, but instead of reporting an error in your interpreter it crashes your whole system. Also, how do you plan on implementing delays, preemption or wallclock without interrupts? Even in a monotasking system with busy loop delays you'll need a wallclock (a way to measure time regardless what code is running).

I don't know if I should care about efficiency as this is not a serious project at all

Probably not. However you should care about correctness and stability, even in a "not so serious" project.

Also, as I needed the BIOS routines, Can I use interrupts with preserving the BIOS ones for using in real mode?

Yes. Make sure you don't mess up the first physical page in RAM (0x0 - 0x1000 IVT and BDA), and the EBDA area (usually somewhere 0x9?000 - 0xA0000). Then set up your IDT whereever you like. Before you switch back to real mode to access BIOS, load an idt value of (offset 0, length 0x3ff), do the BIOS stuff, and when returning, restore IDT.

I can try setting up some interrupts to learn about the interrupts as another project, but should I redesign the kernel to work in the standard manner and implement interrupts in this one? This question may sound a bit odd, if so please forgive me.

If I were you, I would do some PoCs to get myself familiar with interrupts, and when it is working fine, only then would I add it to the current kernel. BTW this is a good approach for all features, not just for interrupts.

It's possible, but I think it would be easier to write a USB driver.

Not in a thousand years. Switching to real mode, do an int, return to prot/longmode is a LOT easier than parsing PCI bus (to find the root hub), and write native device drivers for hubs and storage as well. But it is unavoidable for a stable system, that's true, just not easier

Cheers,
bzt

[PeterX]

Hello, I am making a Boot loader and a kernel(sort of) using assembly and C. I used a tutorial for the basics like GDT, address bus, segmentation etc. but the rest of it(almost entirety of my kernel) was just my own random ideas glued together. As of now I can use keyboard, print a prompt that looks nice(for me ), a somewhat usable text editor, and some other lazy commands like list "files", CAT, show time,etc. and an 'interpreter' that will crash the entire system if I miss-typed one letter in my 'Programming language' .

Congratulations, I think you are already quite far in your OS development. (Well it dpeends with which OS you compare it )

Regarding interrupts and BIOS:
- interrupts yes. (Or else you would use polling for I/O and that's not cool. And how are you gonna build a complete OS with multitasking and timers and devices etc. without interrupts?)
- BIOS no. There is some nostalgia in using BIOS, but nontheless I don't know why people are so obsessed with BIOS. Be glad that you have alternative ways in pmode.
- USB iansjack gave a good advice. When I finally should manage to get to complex I/O I probably will probably buy Ben Lunt's book about USB. I haven't bought or read it yet. But I used his bootsector long ago to get started, so I have trust in his books. It's not neccessary but I think it helps.

Greetings
Peter

[iansjack]

+1

Ben's book is a good introduction to implementing USB. You also need to study the specification documents, but it's far easier to make sense of them with the aid of the book. But it's not for beginners.

[Octocontrabass]

Switching to real mode, do an int, return to prot/longmode is a LOT easier than parsing PCI bus (to find the root hub), and write native device drivers for hubs and storage as well.

It's easier until it isn't. The more hardware you touch, the more things you must reset to the BIOS default before you can call the BIOS. And this assumes you know what the BIOS default is: it will vary from one computer to the next, and if you make a mistake your BIOS call may crash or hang forever.

[pranavappu007]

Redesign your OS now before it gets too advanced. I'd strongly suggest avoiding the BIOS too. You don't need USB right now - run your OS in a VM until you are ready to write a USB driver.

I frankly don't think I'll ever write or be able to write a USB driver.

It's possible, but I think it would be easier to write a USB driver.

With my current stage or even with my end goal, This is faaar better than a USB(I don't even understand USB, I tried )

Yeah, but instead of reporting an error in your interpreter it crashes your whole system. Also, how do you plan on implementing delays, preemption or wallclock without interrupts? Even in a monotasking system with busy loop delays you'll need a wallclock

Actually, the interpreter crashes due to not implementing error-checking yet. My usual method is to check errors rather than catch errors. Not efficient maybe, but it'll do. Preemption is not possible in interrupting the kernel, but I think I can make the interpreter stop what it's doing, save variable spaces and set up a way to resume it later. Maybe not in the most efficient way, or maybe not even doable, but that's the current plan. As for delays, I can poll RTC for larger delays, and loops for smaller ones I think.

Yes. Make sure you don't mess up the first physical page in RAM (0x0 - 0x1000 IVT and BDA), and the EBDA area (usually somewhere 0x9?000 - 0xA0000). Then set up your IDT whereever you like. Before you switch back to real mode to access BIOS, load an idt value of (offset 0, length 0x3ff), do the BIOS stuff, and when returning, restore IDT.

Thanks! That was one of my major concern, not being able to use BIOS.

And how are you gonna build a complete OS with multitasking and timers and devices

I don't think I ever will

USB iansjack gave a good advice

I don't know, I find it hard. Or is it not as hard as I think? Can you give the details on that?

I see that interrupts are kind of important...

[PeterX]

You don't need USB right now - run your OS in a VM until you are ready to write a USB driver.

About virtual machines: On Linux you have Qemu (which I recommend), Bochs, VirtualBox. Search this site's wiki and/or the internet how to use the VM.

On which OS do you develop your OS? Windows? Linux? Which Linux distribution?

Greetings
Peter

[pranavappu007]

Is implementing features using interrupts harder than traditional way?

I don't know if I could've done this much because I didn't go too complicated and kept the general structure of kernel like that of a simple program. Also, if I'm going to use interrupts, should I consider switching to ACPI mode or something to get control of all threads in CPU? Is it even possible without going too complex?

Also,most guides regarding IDT and and PIC are done in C using inline assembly, but frankly at that level I prefer direct assembly(intel). Could anyone help for a simple guide to implement the subroutines and IDT structures in something like nasm?

[pranavappu007]

On which OS do you develop your OS? Windows? Linux? Which Linux distribution?

I use linux and have qemu installed. I first test on qemu, which is easy as it will tolerate simple errors. If it does, I will restart and test on my actual hardware, find any bugs. It was all going well until I tested it on an older hardware which lead to my other post here regarding BIOS freeze. Fixed it though, It's working now.

[PeterX]

Well, you can do whatever you want to do in your OS project. It doesn't matter what's normal. It's just the question what you want. If you want switching back and forth between the CPU modes, then do it!

But I personally think that would be unelegant (it would also be slow).

Happy hacking
Peter

[iansjack]

Undeniably, writing a USB driver is hard. But what's the point of doing all this if we don't have the ambition to do the hard stuff? And, like everything else, once you've done it it turns out to be much easier than you thought.

There's a lot of things I thought were almost too hard when I started. An ATA disk driver - unbelievably simple. A NIC driver - so much simpler than it seemed. A USB driver - difficult, but not impossible. My current project is a TCP/IP stack - difficult to believe I'll ever complete it, but give it a while and I'll wonder why I found it difficult. And it's so satisfying to learn how these things work.

Have some ambition, and push your limits. You'll be surprised what you can achieve. The worst design decision you can make is to say "that's the right way to do it, but I'll never be able to program it". Pick what is the best design and then do it.

[bzt]

Is implementing features using interrupts harder than traditional way?

What you mean by "traditional" way? Using interrupts are pretty traditional, even 8086 had them. They were in heavy use by TSRs under MSDOS too 40 years ago.

I don't know if I could've done this much because I didn't go too complicated and kept the general structure of kernel like that of a simple program. Also, if I'm going to use interrupts, should I consider switching to ACPI mode or something to get control of all threads in CPU? Is it even possible without going too complex?

Hah, let me see. You don't need ACPI for interrupts. You don't need ACPI for multicore SMP (but you'll need to parse some ACPI tables to get the address of the LAPIC/IOAPIC, but for a VM, you could hardwire those addesses, they won't change).

Also,most guides regarding IDT and and PIC are done in C using inline assembly, but frankly at that level I prefer direct assembly(intel). Could anyone help for a simple guide to implement the subroutines and IDT structures in something like nasm?

What simple guide do you mean? The wiki has all the information you need. Setting up IDT is simple as one instruction, lidt. That has one parameter, IDT_value, which contains another pointer and a size to describe an array. Filling up an array (just like with any other arrays) can be done statically or dynamically, your choice. For static, you'll need something like

Code: Select all

lidt [idt_point]
...
idt_point:
		dw idt_end - idt_start - 1
		dd idt_start
...
idt_start:
irq0:
		dw isr0
		dw 0x0008
		db 0x00
		db 10101110b
		dw 0x0000
irq1:
		dw isr1
		dw 0x0008
		db 0x00
		db 10101110b
		dw 0x0000
irq2:
		dw isr2
		dw 0x0008
		db 0x00
		db 10101110b
		dw 0x0000
...lot more of these records.

simple as that. But this is no IDT specific, same as you would do with any other array.
Note #1: I didn't wrote that code, I've copy'n'pasted from here which was literally the first result when I searched for "assembly idt nasm".

Note #2: I used to use nasm but I have abandoned it long time ago in favour of fasm.

Cheers,
bzt

[pranavappu007]

Thank you! When statically defining the IDT, should I write the descriptors for all interrupts from 0-256? Can I use 0 bytes to pad out the interrupt descriptors that I want to be ignored? What happens i an interrupt is raised that is not defined in IDT? Should I mask the interrupt in PIC or will the CPU ignore that automatically?