Mail Archives: djgpp/2000/03/15/11:27:47
Eli Zaretskii wrote:
>
> On Tue, 14 Mar 2000, Michael Tippach wrote:
>
> > > > A way that would also work under NT is to make the
> > > > IRQ 13 handler just set the EM bit in CR0 by trying both, DPMI function
> > > > 0xE01 and direct writes to CR0.
> > >
> > > I'm not sure I understand what problem does this solve. Currently,
> > > the EM bit is set by calling function 0E01h at startup.
> >
> > Setting the EM bit TEMPORARILY from within the IRQ 0x13 interrupt
> > handler to cause a single INT 0x7 upon the next FPU instruction.
>
> And what if the next FPU instruction never comes, or comes too late?
Then, under "normal" circumstances, there would have been no FPU
exception anyway. An FPU exception is not generated after the operation
that causes it but only at the beginning of the next following FPU
instruction. Using the method above, this next instruction will be
restarted with the EM bit set, making it cause an exception 7 that can
be handled accordingly. There is no additional delay introduced using
the EM bit method, whereas there could be a considerable delay using
DJGPPs method as is.
DJGPP run time (Segment limit):
fdiv st1 -> causes /0
fmul st2 -> IRQ 13 happens here
DS limit is altered and
instruction restarted
fadd st3
fstp [foo] -> signal here (to late)
WDOSX Win32 subsystem (EM bit):
fdiv st1 -> causes /0
fmul st2 -> IRQ 13 happens here
EM bit is set,
instruction restarted,
EXC 7 happens here = signal here
fadd st3 -> never executed (rightly so)
fstp [foo] -> ditto
Think about it!
>
> > Once you are in the context of a DPMI exception handler, you can
> > continue execution wherever you desire. IOW: as opposed to a hardware
> > interrupt handler where that isn't possible, one can do a complete
> > context switch from within an exception handler.
>
> Exceptions are easier than interrupts, but it is still not trivial to
> run arbitrary code from them.
Depending on the definition of "trivial", that is.
For me, if there is a way that is fully within the spec and not known to
have significant issues on any major platform, that way is trivial.
>
> > That is, BTW what DJGPP
> > does when it receives the GPF or stack fault or whatever would be the
> > outcome of the segment limit alteration thing.
>
> Not before it does quite a bit of trickery to get things to their
> normal state again.
Cleaning up the artificial condition created to trigger the exception is
not what I call trickery but a necessary step.
>
> > As soon as an IRQ is
> > converted into a DPMI exception, the problem is essentially solved.
>
> The problem is not solved until you eliminate the reason for the
> exception; if you don't, you will get the same exception again when
> the faulting instruction is restarted.
This is obvious, obviously... I did, however, never make any adverse
statement.
> For fake exceptions triggered
> by deliberately lowering the DS limit, this is easily done, since we
> lowered the limit ourselves. For real exceptions, it's not so easy.
That is true. Though I fail to see the relevance for this as we were
always talking about deliberately causing exceptions in either case.
>
> > > CPL 3 environment for writing ``normal'' application programs.
> > > Writing low-level stuff like OS kernels is not something DJGPP is
> > > meant to be well suited for.
> >
> > I meant a DPMI host that runs the client at ring 0 for convenience
> > reasons. In a non- multitasking, non- VM- environment there is very
> > little reason left to maintain all that ring switching overhead.
>
> Why ``non-VM''? DJGPP (and DPMI in general) does support VM. (I'm
> assuming that VM means Virtual Memory.)
DJGPP itself does not support VM. It does also not not support VM. The
DPMI host may support VM or it may not.
>
> > > > One possibility would be to conditionally alter the CS limit instead,
> > > > _IF_ the DPMI host is CPL0 OR NTVDM (should work with both).
> > >
> > > Not good. CPL 0 and NT are among the least interesting DJGPP targets.
> >
> > This discussion started with someone complaining about NTVDM screwing up
> > DJGPP signal handling.
>
> The point is that it hardly makes sense to futz with CS just to fix
> NT, which has a few other serious DJGPP- and DPMI-related bugs anyway.
> You can see them listed in section 3.3 of the DJGPP FAQ list.
I should probably have a look at these. Still, it's up to <whomever> to
either fix it or leave as is. I merely was about to point out that this
is fixable. Personally, I don't use DJGPP for I find the non- flat
memory model a bit offensive.
>
> > it takes 3 more lines of assembly code to detect NT.
>
> That's not really true, especially now that you need to distinguish
> between NT and W2K.
So does W2K return a different value than 0x3205 from function 0x3306?
Well, make it 5 lines of code instead of 3, in that case.
>
> > > > OR,
> > > > one somewhat more memory intense, albeit pretty generic approach would
> > > > be to let the interrupt handler make a copy of the code section
> > >
> > > ALL of the code section? That might be megabytes to move inside an
> > > interrupt handler, right?
> >
> > Very few applications contain megabytes of code. Initialized data is
> > what makes applications fat.
>
> The DJGPP setup makes CS and DS reference the same memory. So you
> don't always know where you code ends and the data begins (a program
> could put code in some data variable in malloc'ed storage).
If one allows for that one might also allow for a program setting its DS
selector to something different. Signals wouldn't work at all anymore.
Anyway, scratch that code section moving'- idea. It was just an idea.
Regards,
Michael Tippach
- Raw text -