linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rick A. Hohensee" <rickh@capaccess.org>
To: linux-kernel@vger.kernel.org, linux-assembly@vger.kernel.org
Subject: Forreal Mode update
Date: Sun, 20 Jul 2003 04:05:19 -0400	[thread overview]
Message-ID: <fc.0010c7b2009ad0a90010c7b2009ad0a9.9ad0aa@capaccess.org> (raw)

I don't have interrupts working in Forreal Mode yet, but I think I've
figured out what the two likely scenarios are. (Forreal Mode is
unprotected USE32. PE=0, Dbit in CS descriptor =1.)

PE=0 clearly means intvecs are 4-byte 8086-emulation-style, regardless of
Dbit. The exact description of INT says so, and it would be a very big
deal for it to be otherwise, like a special class of GDTless interrupt
gate for a mode INTeL doesn't support, or who knows what. The issue a
4-byte intvec creates in a USE32 world is what happens to a USE32 EIP
when the intvec offset is assigned to IP. Just IP, not EIP. Is the high
side of EIP persistant, like the high side of EAX when you clobber AX, or
does it get zeroed? Those appear to be the two possibilities. Getting
zeroed, UNLIKE EAX, would be better. Then your Forreal Mode event handler
code needs to be in the low meg. Just the handlers, and just thier
entry-points. No-Sweat Item. IF, HOWEVER, the high side of EIP is simply
left there, all is not lost. Then there are schemes to replicate faux IDTs
every 64k, and you can still have more than a meg of code in 32 bit
unprotected Forreal Mode. And with an extra jump to get to the actual
handler code Forreal Mode may still be faster to handle interrupts than
Pmode, thanks in part to the 4-byte intvecs.

Things that aren't issues are the Dbit of the handler code, which can be
USE32 also, and if fact must be, and thus the interrupt and the IRET stack
frames balance. The rmode CS values in the intvecs probably should all be
0, keeping them in the non-issue category. The real sticky bit is the
undefined behavior of the high side of EIP.

Even if you have to do something like keep all code in the low meg, data
beyond the low meg is already a non-issue in Forreal Mode.

Rick Hohensee



                 reply	other threads:[~2003-07-20  7:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc.0010c7b2009ad0a90010c7b2009ad0a9.9ad0aa@capaccess.org \
    --to=rickh@capaccess.org \
    --cc=linux-assembly@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Forreal Mode update' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).