Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After 5 days, my OS doesn't crash when I press a key

jvns.ca

Post reply on HN
Print view View original

71–80 of 90 posts

Re: After 5 days, my OS doesn't crash when I press a key

#71

Post by Locke1689 »

raverbashing wrote: post #48

For some reason HN ate my previous comment Doing OS things is hard. In x86 it's extra hard x86 is one kludge on top of another. Like interrupt chaining These issues remind me of making a Sound Blaster card work on DOS (I was making a program to play a simple file in Pascal/C) It's very complicated, and several trials to make it work (and no Stackoverflow, Wikis, etc)

Doing OS things is hard. In x86 it's extra hard

Agreed, 1000 times over. To the author: WELL DONE.

The jumps between real mode, v8086/protected mode, and long mode are absolutely mind boggling.

Here's the best part that I remember from implementing Intel VMX support in a VMM: once you've booted the VMM and are ready to do a VMXON to load a guest, you will realize you have a problem. Specifically, Intel realized a while ago that "real mode" sucks and is obviously not the "real mode" that actual applications expect to run in, so they introduced v8086 mode in addition to real mode.

The problem, of course, is that booting an OS still requires real mode, but you can't run a guest in VMX in real mode, only v8086 mode. But all those things that Intel "fixed" in v8086 mode? Yeah they will totally keep you from booting.

So you're chugging along in v8086 and your guest does something that it should absolutely be able to do and BOOM -- you've faulted. So what's the solution? Write your own emulator for a Real Real Mode(tm) in your host, capture the faults, and re-enter after rewriting the guest's state.

Abso-frickin-lutely insane.

Re: After 5 days, my OS doesn't crash when I press a key

#72

Post by zwieback »

Cool, sounds like so much fun. I remember writing OS/2 drivers and getting interrupt handling wrong would cause strange ways of destabilizing the system. Once you get it sort of going you're afraid every time you press a key or do anything with the system because you know your brand new code is down there in the bowels waiting to cause a triple fault.

Re: After 5 days, my OS doesn't crash when I press a key

#73

Post by chinpokomon »

Toenex wrote: post #35

Working at the layer below is a very useful exercise. As part of my undergrad course in EE in the late 1980's we had to design and simulate a 4 bit micro-processor using logic components (essentially NAND gates). I got completely immersed in that project. Not only did it force me to understand a complete, albeit simple processor but actually building it gave me a lot more confidence in writing code. Things have moved…

I built a 4 bit microcontroller the same way around 2000. We flashed the gates to an Altera EPROM and other than external memory chips, the state machine, ALU, and other sub systems were assembled using logic gates we burned. We supported 16 instructions and could access 16 words of memory. That was enough to code a "password" based security system that would either grant access by raising an external line or it would output an alarm state if the code was invalid. As I recall it could only handle about 25Hz max. Still one of the most influential projects I worked on in college.

Re: After 5 days, my OS doesn't crash when I press a key

#74

Post by pwg »

Locke1689 wrote: post #71
raverbashing wrote: post #48

For some reason HN ate my previous comment Doing OS things is hard. In x86 it's extra hard x86 is one kludge on top of another. Like interrupt chaining These issues remind me of making a Sound Blaster card work on DOS (I was making a program to play a simple file in Pascal/C) It's very complicated, and several trials to make it work (and no Stackoverflow, Wikis, etc)

Doing OS things is hard. In x86 it's extra hard Agreed, 1000 times over. To the author: WELL DONE. The jumps between real mode, v8086/protected mode, and long mode are absolutely mind boggling. Here's the best part that I remember from implementing Intel VMX support in a VMM: once you've booted the VMM and are ready to do a VMXON to load a guest, you will realize you have a problem. Specifically, Intel realized a whi…

> Specifically, Intel realized a while ago that "real mode" sucks and is obviously not the "real mode" that actual applications expect to run in, so they introduced v8086 mode in addition to real mode.

Actually, no.

Real mode is your shiny new i7 quad+ core CPU pretending to be nothing more than an 8086 from 1978. It does that because upon initial power up, none of the data tables required for protected mode operation are setup. So there's a chicken and egg problem at power-up. You need the protected mode data structures setup, but they are not present yet, so you have to start somewhere. Real mode on anything 80286+ is intended as a way to provide a CPU that can run a program that can setup the protected mode data structures so that protected mode can actually be entered.

v8086 mode was introduced in the 80386 chip as a way to provide hardware support for visualizing multiple real mode processes/applications while remaining in 80386 protected mode. I.e., it was some amount of hardware support for what VMWare or VirtualBox provides today. The faulting into protected mode on illegal access is/was intentional. To remain "protected" the code running in v8086 mode can't be allowed to do things that might bring the system down. So v8086 faults those accesses over to protected mode, and the assumption is that there is a protected mode handler that performs the operation (or denies it) on behalf, safely, so the system can continue to chug along. The capture/rewrite state is the intended design consequence.

An extremely good book on the 80386/v8086 design and how to make use of it is: "Advanced 80386 Programming Techniques" by James L Turley, Osborne Publishing, 1988. A very easy read, and extremely well written (assuming you can find a copy).

Re: After 5 days, my OS doesn't crash when I press a key

#75

Post by ChuckMcM »

Locke1689 wrote: post #68
ChuckMcM wrote: post #13

I enjoyed this. It brought back memories of bringing up BSD2.9 on the PDP 11/55t we had in the lab. That particular PDP 11 was pretty rare (it had some memory split features to improve performance for computational tasks) and poking around in the kernel to get to the point where init was started. Nothing quite like that thrill, a mixture of power, and 'oh crap this is going to be a lot of work'.

What she's doing is surprisingly a lot harder. Getting a modern IA-32(e) architecture into the 64 bit mode we all know and love is INSANE.

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 will however point out the meta fallacy of even thinking about these things in terms of 'not hard.'

The truth is, computers have become exceptionally complex. 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. 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. My target is a self hosted 'DOS' style Monitor/OS for the Cortex M4 series. 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.

Re: After 5 days, my OS doesn't crash when I press a key

#76

Post by chinpokomon »

pbsd wrote: post #14
stephen_g wrote: post #7

Earlier quoted context omitted.

Text mode is super easy - you just set bytes in the correct memory location (0xb8000000 if I remember correctly). Writing an actual graphics driver is tricky - although there are some ways to get decent frame buffer modes (like VESA Bios Extentions), to do things really well requires thousands of lines of code before you can even get a pixel on the screen, and is different for every card. It may be a bit easier now -…

0xB8000, to be precise. This is 16-bit 8086 legacy, where addresses were 20-bit and segmented. The most fun mode was mode 0x13 from INT 0x10, with its fantastic 320x200 resolution and 256 colors. That one had the buffer at 0xA0000.

I preferred "Mode X" for its 320x240 resolution with square pixels and additional pages that could be used for animations. I still have my EGA/VGA Programmer's Guide "Bible" sitting on my bookshelf. I haven't needed it for many years now, but somehow it is a comfort keeping it around.

Re: After 5 days, my OS doesn't crash when I press a key

#77

Post by darkarmani »

revasm wrote: post #22
wikwocket wrote: post #16

Earlier quoted context omitted.

The blog author is not a 'he' but a 'she.' Her name is mentioned through the article. And I'm guessing that the difficulty comes from the fact that she's building a freaking operating system from scratch... ;)

Is the gender of said author supposed to be curious or worthy of attention? I'm not intending to be impolite, but this is the third time in several days that HN posters have brusquely corrected a gender pronoun in relation to a submission of nondescript importance.

> HN posters have brusquely corrected a gender pronoun

I'm confused by your characterization. Why do you think it is brusque?

Re: After 5 days, my OS doesn't crash when I press a key

#78

Post by marvin »

hansjorg wrote: post #70
dmytrish wrote: post #51

Earlier quoted context omitted.

That's very true from both compiler and OS point of view. 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 (%es…

Going from Motorola 68k to x86 with few preconceptions in the nineties was quite a shock after slowly having been convinced that the grass actually was greener. On the x86 side I was surprised to find an unnecessarily cryptic assembly language, little-endian words and a byzantine memory model for starters. Hacks upon layers of hacks and not the intuitive and aesthetically pleasing solutions seems to win out in most c…

It's a wonder any of this stuff works at all. I find myself saying this almost every time I learn something new about how computer systems are designed, built and used.

Re: After 5 days, my OS doesn't crash when I press a key

#79

Post by raverbashing »

pwg wrote: post #74
Locke1689 wrote: post #71

Earlier quoted context omitted.

Doing OS things is hard. In x86 it's extra hard Agreed, 1000 times over. To the author: WELL DONE. The jumps between real mode, v8086/protected mode, and long mode are absolutely mind boggling. Here's the best part that I remember from implementing Intel VMX support in a VMM: once you've booted the VMM and are ready to do a VMXON to load a guest, you will realize you have a problem. Specifically, Intel realized a whi…

> Specifically, Intel realized a while ago that "real mode" sucks and is obviously not the "real mode" that actual applications expect to run in, so they introduced v8086 mode in addition to real mode. Actually, no. Real mode is your shiny new i7 quad+ core CPU pretending to be nothing more than an 8086 from 1978. It does that because upon initial power up, none of the data tables required for protected mode operatio…

Yes, these traps were used for this: http://en.wikipedia.org/wiki/Virtual_DOS_machine

Re: After 5 days, my OS doesn't crash when I press a key

#80

Post by pwg »

dmytrish wrote: post #51
raverbashing wrote: post #48

For some reason HN ate my previous comment Doing OS things is hard. In x86 it's extra hard x86 is one kludge on top of another. Like interrupt chaining These issues remind me of making a Sound Blaster card work on DOS (I was making a program to play a simple file in Pascal/C) It's very complicated, and several trials to make it work (and no Stackoverflow, Wikis, etc)

That's very true from both compiler and OS point of view. 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 (%es…

> 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

Very true, and while the X86 is patch upon patch upon patch, in the designers defense, the intent on any 286+ Intel CPU was simply to was to use "real mode" to provide a bootstrap CPU to use to setup enough of the protected mode data tables to be able to actually enter protected mode. The intent was that entering protected mode was a one way, boot time only, street. Could they have made it simpler, maybe, but they were also viewing it as a one time effort that once you got the switch implemented, you didn't need to touch that code again.

[edit for clarification]

Post reply on HN