#BOCHS CLOSING AFTER START CODE#
Intel machine code is so kludgy: variable-length codes, subtle differences in prefixes in different modes, exceptions in register handling all over the place, plenty of addressing modes for memory access, special machine codes for a qualified register (`mov %ax` code differs from `mov %cx/%dx/%bx/.`), more lengthy encoding for more often uses (like `mov (%esp)` requires SIB byte whereas it's not true for all other registers) and so on.įrom OS perspective, it's also overcomplicated: switching from real to protected mode is an exercise in doing every action in a long chain properly and in the right order or the whole undertaking fails. That's very true from both compiler and OS point of view. Complex enough to host its own development environment and tools, but simple enough that you can keep it all in your head at the same time. My target is a self hosted 'DOS' style Monitor/OS for the Cortex M4 series. I realized when I started finding ways to teach my kids about computation that I was very lucky to have things like PDP-11's, VAXen, 68000's, and DEC-10s to play with which did not present this huge wall of complexity that needed to be scaled to get to the fundamentals.
#BOCHS CLOSING AFTER START 64 BIT#
That is one of the reasons I've been building a medium complexity standalone system (ARM Cortex M based) to give folks something that is somewhere between 8 bit Arduino type experiences and 64 bit IA-64 or even ARM Cortex A9 level complexity. The truth is, computers have become exceptionally complex. I will however point out the meta fallacy of even thinking about these things in terms of 'not hard.' I'm not going to argue on 'harder' or 'not as hard' as such things are often personal measures that are difficult to quantify. I'm sorry to spoil your "fun" debugging it.ĭealing with any of this is a fun exercise in being close to the metal but unfortunately has no application in modern computers because these days the built-in IO-APIC/LAPIC has replaced the legacy PIC chip.
Here's the relevant part from my project: I faintly recall having this same issue in my ordeals with the PIC chip, if you don't signal EOI, the PIC won't fire the next keyboard interrupt.Īlthough I think I was working with 8253/8254 PIT (Programmable Interval Timer) chip at the time but I think the same applies to the keyboard interrupt too, it's being handled by the PIC too. Another good read and really gives the insight on how much time and effort it takes to make anything happen on bare SPOILERS AHEAD, DO NOT READ FURTHER IF YOU WANT TO GET TO THE HEART OF THIS PROBLEM YOURSELFĪs for your problem with the keyboard interrupt firing only once, I think (after a quick glance over the code) that you do not signal "end of interrupt" (EOI) message to the 8259 PIC chip after you have received an interrupt.
0 kommentar(er)
