1. Home
  2. Embedded Programming
  3. Very Strange Behavior (iret on x86)

Very Strange Behavior (iret on x86)

hello all:

i have encounter some very strange behavior that i haven't been able to diagnos. i'm attempting to do a software task switch on the x86 in pmode. what i'm doing basically is this:

current state: eflag=0x2 (w/ IF=0 IOPL=0) cs = 0x8 (DPL=0 0x00000000-0x000fffff) ds and ss = 0x10 (DPL=0 0x00000000-0x000fffff)

operation: ... push 0x202 (new eflags w/ IF=1 IOPL=0) push 0x8 (new cs but unchanged) push "proc" (new eip) iret

now once inside "proc" all the registers are as they should be: eflag=0x202 cs = 0x8 ds and ss = 0x10

the only problem is that all hardware interrupts are still disabled. and it's not my interrupt controller configuration. i only have the problem when i run this code.

i've ran it through the bochs debugger several times with no clue as to what's going on. i get the same behavior when in run the code in the emulator and on the hardware. additionally, when i do a "hlt" in "proc" even the bochs debugger says "WARNING: HLT instruction with IF=0!".

i'm very boggled by this. any help is appreciated.

thanks, bryan

Reply to
Bryan Bullard
Loading thread data ...

also,

when i enter the new "task", sti does not seem to work. i still get "WARNING: HLT instruction with IF=0!" at hlt when i single step with the boch debugger.

-bryan

basically

Reply to
Bryan Bullard

Pretty strange.

I tried this on one of our embedded controllers running dos and debug:

a100 mov ax,202 push ax mov ax,cs push ax mov ax,200 push ax iret

a200 int 3

g=100

The program broke at 200. The register dump showed interrupts enabled and a look at 40:6C showed the timer tick incrementing. Note that the bios console routines will reenable interrupts as soon as they are called so I can't fully reproduce your problem.

Running the test with the flags set to 2 instead of 202 gives a register dump of interrupt disabled, yet they do get reenabled by the console I/O.

I'd be curious as to what you find.

Reply to
Jim Stewart

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.