Stack Bizarre

[straiph]

I had a questionable idea of converting one of my modules from a 16bit code (task 32bit) to a 32bit code.

Due to the nature of the specification I have to drop to real mode. The only difference in code is that I have to make a far jump to a 16bit code segment to drop to real mode before doing the far jump to a real mode code segment.
This is all successful. The data segment selector (ds) works fine.

The problem is with the stack segment and pointer. They only appear to work properly when they are both page aligned and I want them to be paragraph aligned.

When they are paragraph aligned and I execute a push ax operation the stack point decrements by 32.

How strange is that!

Anyway, has anyone experienced simular? If so, how did you overcome this problem?

If all else fails I will give up and stick to the 16bit code (32bit task)

Thanks
"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

Might have something to do with the granularity of your ss selector... is it possible for you to check the granularity? Who's handling the PM, you or the OS/DOS Extender?
"Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

before the switch to real mode
the code segment is 16bit base=0 limit=1mb
the stack is 16bit, normal expanding
data 16bit base=0 limit=1mb
switch to real mode
all segments set to zero
far jmp to real code segment
set stack segment to 07C0h (07C00h)
xor esp,esp
set sp=0100h

if I set the stack pointer to anything other that page aligned is causes unpredictable results.

It is really strange, i havent done anything i didnt do in the 16bit module other than perform a far jmp to a 16bit code segment before dropping to real mode.

I am really puzzled.

One question, before switching to real mode the segments have granularity off therefore limiting to 1Mb. Maybe I should make all segments have base=0 limit=0FFFFFh gran=1.
This would ensure any affective address is valid within the segment - but i thought all this was irrelevant while in real mode?


"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

The lowest bit of the MSW/cr0 was the PM bit. On the 286 you could set this but you couldn't turn it back off (requiring an internal processor-only reset built into 286 systems). On the 386 you could turn it off programmatically. BUT even if you turned it off, the segment regs maintain there old (PM) values/scopes. That's how the 'Flat Real Mode' was done: you set up PM, created a 32-bit codeseg, dataseg, and stackseg taking the entire address space, load them, then turn off the PM flag... as long as you left the segregs alone, you were in real mode but had a PM-type addressing system. The segregs aren't cleared by the 'return to RM' instruction.

'Course come to think of it you did change the value of the stacksegreg...


Been a long time since I did direct PM anyway... he he he maybe I'm a wee bit rusty now... dang it's a puzzle... maybe the processor's still groggy from the mode switch...

"Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

Yes, I was thinking about the groggyness of a stale floater. Is there some way (that I dont know of) to flush the toilet! LOL
"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

Dunno, maybe execute a couple NOP's?

Say... you said you did a far jump.... maybe it was through a call/task gate?

Really weird... "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

the far jumps are immediates using self modifying code to make adjustments.

I have a plan...

I am going to test the stack in the 32bit task and hopfully that will be working correctly. I will determin where the stack bizarre occurs at each point in the code so i can find the offending culprit.

I was wondering if real mode isnt actually real mode and the exceptions are used to asimulate it. I installed a little routine capturing all real mode exceptions but it is not being called.

Other than an exception handler I do know anything that can affect the stack in this way during a 'push ax'.

There must be a port setting of sorts that is used to alter the processor. I will have to speak to Intel.

"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

Hrm... what's your system? Does it have any EMM drivers? HIMEM.SYS? Plain Vanilla? "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

Well... I'm using a PC to perform critical tasks and windows was too unreliable (basically I couldnt get the performance I wanted). So I wrote my own boot loader and now I have total control over the processor. It is great. However, I decided to extend it and make it more useful, hence the protected PIC handler which I developed in 16bit and works great. When I introduced task switching I converted everything to 32bit code except the protected PIC handler because of all the mode switching.

I just thought that if the bulk of it was 32bit it would be more efficient because 32bit is its native mode. As I havent been able to get it working I havent been able to clock it so I may just leave it as it is.

"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[straiph]

One small 16bit code task amongst many 32bit tasks wont really matter will it?
"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

If it's not running in parallel, no. If it is, it'll be a bit of a headache 'cause you need to handle two code segments, a USE16 segment and a USER32 segment at the same time, and they are defined in the GDT differently.

Hey if you have complete control of the processor go full 32-bit! Converting 16-bit code to 32-bit code shouldn't be too hard....


"Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[straiph]

As you say, the way the descriptors work the code size is completely transparent when task switching. Even call gates iliminate having to match the 'call' operation to the size of the called code.

Everything is in 32bit except the protected PIC handler due to this nasty little stack bizarre.
"People who have nothing to say, say it too loud and have little knowledge. It's the quiet ones you need to worry about!"

 

[AmkG]

Ha ha ha!

Call gates take a wee bit more time to operate... triple indirection after all...

'Course the point is moot I guess with the speed of todays uprocs. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."