Mail Archives: djgpp/2000/04/10/18:42:32
Ah.... wait now I get it....
Unfortunately, that doesn't work with protected mode (dpmi pm I mean),
'cause the DPMI host screws your stack registers into his own, calls your handler,
your handler returns to the DPMI's handler, the DPMI handler resets the stack registers
and returns to your cs:eip.
So when your handler changes the stack, the iret would return to another task IN STEAD
OF returning to the dpmi host, resulting in a serious lame crash, 'cause that stupid dpmi-host
won't allow threadswitching, so we programmers have to find a neat trick to get around it,
which we eventually will, and so that lame protection hasn't had to be implemented in the
dpmi host in the first place. Why is it called Dos Protected Mode Interface anyway?
Dos always was in real mode, so the 'inventors' of 32-bit compilers had to come up with
extenders and the like to make it all work under dos. And why today bother to run it under
dos? Because the most of use still use windows (but more and more people are switching
to Linux, which is a great thing, I might add), and windows is based on dos. Why base
an inferior OS (Windows) on an even more inferior OS (dos) you might ask? Well, that's
something you have to ask Bill Gates... Guess it all needs to be compatible... It's so good
to be compatible, everything has to be compatible, just like intel which based the 80386
on the 8086. How stupid can you be?
"Objection, your honor. That's a little bit off-topic don't you think"
"Sustained"
Sorry 'bout that, think I'm getting a little tired here...
anyway, you can't just switch cs:eip or the stack in an interrupt handler in protected mode.
DJGPP gets around this by setting the limit of the data selector to zero (actually 0x00000fff),
which will generate an exception, in which you CAN change the cs:eip and the stack and
the flags and so on... But when I'm trying it, it just doesn't work!!!
BTW, if you're interrested in looking into my code, mail me, and I'll comment it and send
it to ya...
Well, that's it for tonight, goin' to bed, gotta go to school tomorrow
c y'all
OiSyN
oisyn AT afmp DOT nl
Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> schreef in berichtnieuws 38F22AC6 DOT ECCC858D AT mtu-net DOT ru...
> Let me explain...
>
> 1. You prepare N separate tasks/threads by allocating separate stack for each
> task/thread.
>
> 2. You push initial values of (E)FLAGS, CS:(E)IP and other registers to their
> stacks.
>
> 3. You load SS:(E)SP with one of those stacks. Pop registers back and perform an
> IRET(D). Hence you do 1st task/thread switching.
>
> 4. When becoms time of another task switch (timer IRQ is generated), you push
> the rest of the registers (except of (E)FLAGS and CS:(E)IP, since they are
> already on stack). Then you load another SS:(E)SP pair, pop regs and perform
> IRET(D) once more. Thus you get 2nd,3rd,... Nth task switch.
>
> I hope you understand the basic idea.
>
> The example program I mentioned also gives diffeernt periods of time. I.e. some
> kind of advanced multitasking/multithreading.
>
> Good Luck
> Alexei A. Frounze
> -----------------------------------------
> Homepage: http://alexfru.chat.ru
> Mirror: http://members.xoom.com/alexfru
>
> Eli Zaretskii wrote:
> >
> > On Mon, 10 Apr 2000, Alexei A. Frounze wrote:
> >
> > > Why not to use the stack switch trick for the multithreading instead of real
> > > exceptions?
> >
> > Sorry, I don't understand: what ``stack switch trick''?
>
>
- Raw text -