OSDev.org

It would still work, and you might not notice anything is wrong. Processor topology is only a performance hint. You can still use all available hardware threads regardless of where they physically exist.

You're right, though, detecting processor topology is manufacturer-specific, so you would need to know the manufacturer. However, a "hyperthreading" flag is not useful. You need to know the physical location of each hardware thread to perform any optimizations.


I did not say "halt loop", I said "HLT loop", as in a loop that runs the HLT instruction. Like this one you were using earlier:

Also, it's a bad idea to enable interrupts with STI before you've configured the IDT. Move that somewhere after the IDT configuration.

Hmm I didn't know that. I thought the feature would cause issues. And hyperthreading was an example

And that's what I had originally and the pit timer wasn't running. "HLT"-ing of any kind seems to prevent the timer from running if not triple faulting when I throw it in there now. Perhaps I'm missing something?

And good point, for all intents and purposes it works right now, but in practice you're right. The IDT tells the system how to handle the interrupts so it makes sense that it should go after.

Edit:
Ohhh! I think I get it. You mentioned somewhere that "CLI" interferes with the pit timer or hlt instruction, I just realized that in my old bootloader I had "CLI" before my HLT loop. I'm about to test the old one without "CLI".

Edit2:
Bingo! How did I miss that? I tyend to overthink the problem way too much. With just that one instruction removed, the system works. Very nice! Off topic, but I'm now working on the keyboard driver (which I've pretty much written myself) and I need to handle multiple keys at once. Ex: <SHIFT> + <A> = "A". How would I go about that?
My current keyboard handler function (processed through IRQ1) looks something like this:


I tried:


Edit3:
If you don't want to answer about the keyboard I get it (off topic), but I just realized something: When I press shift, it only fires once rather that treating it like I'm holding the key. That might be one place to start.

On the note of the CPU flags, how would I retrieve them? In cpuid.asm I have the following:


I call it like this:


Then I used it like this:


Is this correct, or is there a better way to do it?

Each time a key is pressed or released, the keyboard sends a scan code. You receive an interrupt for each byte of the scan code (scan codes may be more than a single byte). To combine the shift key with other keys, you need to keep track of whether shift has been pressed or released. There are a lot of existing threads on the topic, so I suggest searching.


I think you should start by accepting the "key release" scan codes you're currently ignoring. Things should make a bit more sense once you can see those.


Check that the CPU supports the basic or extended leaf containing the flag you want to retrieve, then retrieve that leaf and extract the flag of interest from the correct register. (Then optimize by retrieving all of the flags in that leaf at the same time.)

Some ancient CPUs don't support CPUID, but you probably aren't worried about those.


That's not correct, and I'd recommend using either __cpuid() from cpuid.h or inline assembly since it's difficult to return four registers worth of data from one function. You already have code to retrieve the brand string, how does that work?

You might also want to read more about the CPUID instruction in Intel's or AMD's manuals.

Luckily I already have macros in place for key down/key up. I was reading on the wiki about those buffers you mentioned, just trying to see how I can implement them at the moment. Any ideas? As for the CPU, I am not using existing libraries. As such, cpuid.h will not work for me (plus I have my own cpuid.h in place), I will read up on that. To put it simply, I want to start finishing one module at a time, so I'll be back here once I've finished the keyboard driver and possible a shell for interacting with the file system I haven't yet implemented, lol.

That's a header, not a library. It's fair if you want to avoid using it; I don't use cpuid.h either. However, don't try to write your own versions of the C freestanding headers. They're part of your cross-compiler, so they contain bits of "compiler magic" that you won't be able to replicate.