×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Stack Bizarre

Stack Bizarre

Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

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."

RE: Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

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."

RE: Stack Bizarre

(OP)
Yes, I was thinking about the groggyness of a stale floater. Is there some way (that I dont know of) to flush the toilet!

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

RE: Stack Bizarre

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."

RE: Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

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."

RE: Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

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."

RE: Stack Bizarre

(OP)
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!"

RE: Stack Bizarre

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."

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close