disabling compiler optimisation

[Wajideu]

@Brendan While those are some very good solutions, in my honest opinion, it's better to use extensive error checking than to use tricks when writing a kernel. The use of tricks is the entire reason we have to deal with crap like the A20 gate. I may be alone in having this mindset, but stability is far more important than speed and code size in a kernel.

[Gigasoft]

While this setup will sort of work, I prefer letting applications use registers as they please and not change things behind someone's back, even if I have to spend a couple of nanoseconds saving those registers. However, what Brendan wrote could perhaps be made to work in V86 mode too, as DS, ES, FS and GS are zeroed when exiting V86 mode. Page 0 must be present, though, because the IVT is there.

[Brendan]

Hi,

While this setup will sort of work, I prefer letting applications use registers as they please and not change things behind someone's back, even if I have to spend a couple of nanoseconds saving those registers.

That depends which registers. Some registers are considered "system use only" (e.g. CR0) while some aren't (e.g. EAX). If processes use a flat memory model I see no reason to include segment registers in the latter group.

Also note that reloading segment registers can cost several hundred nanoseconds; and (especially for multi-CPU where each CPU broadcasts IPIs to all other CPUs) a few hundred thousand interrupts per second may not be unusual under load; and this translates into processes running several percent slower than they could have.

However, what Brendan wrote could perhaps be made to work in V86 mode too, as DS, ES, FS and GS are zeroed when exiting V86 mode. Page 0 must be present, though, because the IVT is there.

Yes, there are work-arounds. The simplest may be to switch to a different (protected mode) IDT when entering V86 mode, so that you can have a different set of assembly stubs that do reload segment registers (and possibly a different GPF handler). That way none of the overhead of supporting V86 would effect normal processes.

Of course the only "slightly sane" reason to use V86 at all is for video mode switching after boot when there's no native video driver; and this only makes sense if the graphics API is very bad (e.g. no resolution independence, where poor design forces software to care about video modes); and the firmware isn't UEFI and the OS isn't using long mode (e.g. > 10 year-old hardware). Basically, it just isn't worth the hassle anyway, and it'd be much better to spend your time on something that's actually useful instead (e.g. native video drivers and/or a graphics API that doesn't suck).


Cheers,

Brendan

[Wajideu]

My viewpoint is to write your kernel as if someone is desperately trying to exploit or break it in any way possible. I'm no hacker, but I can see potential problems with ignoring register changes like someone flooding IRQ's to bypass the exception handling or using it as a wormhole after doing a ring-level jump.

I repeat though, I'm no hacker, so what I just said may sound unfeasible or stupid. These are just things I would be concerned about.