Stack ptr problem 5.1 - > 6.1 
Author Message
 Stack ptr problem 5.1 - > 6.1

I recently upgraded from MASM 5.1 to MASM 6.1.  I am maintaining some MSDOS
code and am getting mysterious failures.

I finally figured out that SP is being initialized to a value like 0102
instead of 0100.  For example:

STACK    segment para stack 'STACK'
                 dw    128 dup('ST')
STACK    ends

_DATA    segment para public 'DATA'
value1      dw   27
_DATA    ends

In this example, SP is initialized to 0102 so the first push overwrites the
first word (value1) in my data segment.  I am using the command "ML /Zm
<filename.asm>.  What gives?




Sat, 04 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1


Quote:
>I recently upgraded from MASM 5.1 to MASM 6.1.  I am maintaining some MSDOS
>code and am getting mysterious failures.

>I finally figured out that SP is being initialized to a value like 0102
>instead of 0100.  For example:

This is just a guess, but did you change computers too? There was a
change in the behaviour of the stack between two processors (probably
between the 8086 and the 80186). I forget which way round the change
was, but it concerned whether the stack pointer was decremented before
or after the stack memory was written to. Presumably if one took an EXE
intended to run on an old processor that decremented SP first and then
wrote a word into memory, and then ran it on a new processor that wrote
the data into the stack first and then decremented SP, you would be
tricked into thinking that that the stack had got two bytes bigger while
you weren't looking!

Hope this helps

--



Sun, 05 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:

> STACK    segment para stack 'STACK'
>                  dw    128 dup('ST')
> STACK    ends

> _DATA    segment para public 'DATA'
> value1      dw   27
> _DATA    ends

> In this example, SP is initialized to 0102 so the first push overwrites the
> first word (value1) in my data segment.  I am using the command "ML /Zm
> <filename.asm>.  What gives?

Hard to say, since you didn't include the code where the stack pointer
is initialized.

        AriL
--
Humans may send email (if absolutely necessary) to the
obvious non-spam address.



Sun, 05 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:

>>I finally figured out that SP is being initialized to a value like 0102
>>instead of 0100.  For example:

>This is just a guess, but did you change computers too? There was a

Thanks for writing, but no, I've been using the same Pentium for a couple of
years now.

-bbb



Tue, 07 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:


>> In this example, SP is initialized to 0102 so the first push overwrites
the
>> first word (value1) in my data segment.  I am using the command "ML /Zm
>> <filename.asm>.  What gives?

>Hard to say, since you didn't include the code where the stack pointer
>is initialized.

Well, I'm sure SP is initialized by the assembler or the linker... there is
nothing in my code that *explicitly* initializes SP.  IOW, MASM sets SP
equal to the top of the stack frame.  IAC, here are the first few
instructions at the program entry point.  I have used this exact code
hundreds of times.

_TEXT           segment para public 'CODE'

                assume  cs:_TEXT,ds:_DATA,es:_DATA,ss:STACK

start           proc    far

                push    ds                       ; save pointer to PSP.
                mov     ax,_data                 ; DS, ES = _DATA.
                mov     ds,ax
                mov     es,ax
                pop     ax                       ; get psp pointer back and
                mov     psp,ax                   ; park it in memory.



Tue, 07 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:

> Well, I'm sure SP is initialized by the assembler or the linker... there is
> nothing in my code that *explicitly* initializes SP.  IOW, MASM sets SP
> equal to the top of the stack frame.  IAC, here are the first few
> instructions at the program entry point.  I have used this exact code
> hundreds of times.

Wonder that it has worked...

Assemble and link the following into a .com file, run it and see what
the printed value is. On my machine (masm 6.0, Windows NT DOS box), it
gave SP the value of FFFE hex, even if the stack line was uncommented.

        .model  tiny
        .dosseg

;       .stack  256

        .data
Banner  db      'SP = $'

        .code
        .startup
        mov     dx,offset Banner
        mov     ah,9
        int     21h
        mov     ax,sp   ; print the value of SP at program start
        call    PrWord
        .exit   0

PrWord:                 ; prints a word in AX
        push    ax
        mov     al,ah
        call    PrByte
        pop     ax
PrByte:                 ; prints a byte in AL
        push    ax
        mov     cl,4
        shr     al,cl
        call    PrNib
        pop     ax
PrNib:                  ; prints the bits 0-3 of AL
        and     al,0fh
        cmp     al,9


        mov     dl,al
        mov     ah,2
        int     21h
        ret

        end

So, in effect, MASM (nor LINK) does not set the SS:SP - you'll have to
write the code to do it yourself.

        AriL
--
Humans may send email (if absolutely necessary) to the
obvious non-spam address.



Tue, 07 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1
<snip>

Quote:
> So, in effect, MASM (nor LINK) does not set the SS:SP - you'll have to
> write the code to do it yourself.

Actually, the word at 10h of the EXE header contains the initial SP. (Got that
out of the old Help PC reference, andtested it with a small EXE)  The word at 0Eh
specifies the number of paragraphs that SS is indented from the original segment.

    Ben

Quote:
>         AriL
> --
> Humans may send email (if absolutely necessary) to the
> obvious non-spam address.



Tue, 07 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1


Quote:

}Assemble and link the following into a .com file, run it and see what
}the printed value is. On my machine (masm 6.0, Windows NT DOS box), it
}gave SP the value of FFFE hex, even if the stack line was uncommented.

.COMs do not have an explicit stack.  The stack pointer is set to the
end of the first 64K allocated to the program (or the end of allocated
memory if less than 64K), and then a word of 0000h is pushed onto the
stack.  Hence, .COMs usually start with SP=FFFEh these days; in the
days where total system RAM was 64K or 128K, you could get smaller
values of SP.  Incidentally, that zero word is for CP/M-80
compatibility -- CP/M programs can terminate by simply executing a
RETurn instruction.  MS-DOS places an INT 20h instruction at offset 0
to make this work.


Wed, 08 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:

>Wonder that it has worked...

>Assemble and link the following into a .com file, run it and see what
>the printed value is. On my machine (masm 6.0, Windows NT DOS box), it
>gave SP the value of FFFE hex, even if the stack line was uncommented.

Apples and oranges.  Your example is .COM program- of course SP = FFFE.  My
example is a multi-segmented .EXE model.

IAC, we're straying way off topic.  The question is, my example code used to
assemble correctly and now it doesn't.  The only change is moving from MASM
5.1 to 6.1.




Fri, 10 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1


Quote:

>Thanks for writing, but no, I've been using the same Pentium for a couple of
>years now.

>-bbb

I tried assembling and linking your code with MASM 5.1 and 6.1. I get
the same EXE in each case as long as I use the same linker. SS:SP always
points to the same address as DS:0. When the push instruction is
executed, SP is decremented and the word at SS:00FE is written to, which
is correct.

I get a slight discrepancy between linkers. One announces itself as:-

Microsoft (R) Segmented-Executable Linker  Version 5.10
Copyright (C) Microsoft Corp 1984-1990.  All rights reserved.

and the other says:-

Microsoft (R) Segmented Executable Linker  Version 5.60.339 Dec  5 1994
Copyright (C) Microsoft Corp 1984-1993.  All rights reserved.

Are you using one of these or something else? I have seen a puzzle like
this before but I can't remember what the answer was straight off. The
discrepancy I get is in the EXEs relocation table.

--



Sat, 11 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1

Quote:
>I tried assembling and linking your code with MASM 5.1 and 6.1. I get
>the same EXE in each case as long as I use the same linker. SS:SP always
>points to the same address as DS:0.

Same linker, eh?  I do have the MS C 6.00 compiler installed, so I renamed
that linker just to be sure.  My version of MASM is actually 6.11, not 6.1
(my mistake).  I use the command "ml /Zm <asmfile>" and when the linker
executes I get:

Microsoft (R) Segmented Executable Linker  Version 5.31.009 Jul 13 1992
Copyright (C) Microsoft Corp 1984-1992.  All rights reserved.

I have verified that this is the version that shipped with my copy of MASM.
I agree that it is OK and normal for SS:SP = DS:0 at startup, but in my case
it continues to be DS:2.  The first push overwrites the word at DS:0.

I have worked around this by leaving a dead word at DS:0, but obviously
something is wrong.




Sun, 12 Aug 2001 03:00:00 GMT  
 Stack ptr problem 5.1 - > 6.1


Quote:
>I have verified that this is the version that shipped with my copy of MASM.
>I agree that it is OK and normal for SS:SP = DS:0 at startup, but in my case
>it continues to be DS:2.  The first push overwrites the word at DS:0.

>I have worked around this by leaving a dead word at DS:0, but obviously
>something is wrong.

Aargh! Why am I completely besotted by this problem? Anyway, I tried a
number of different versions of the assembler and linker and I can't
duplicate the effect. Can you post a short but complete example of
source code please?
Does it still occur if you use the linker out of C6?

--



Mon, 13 Aug 2001 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. mac version 5.1 compatability problems with pc version 6.1

2. Upgrade LV 5.1 --- 6.1 problem

3. Will Labwiew 6.1 run-time for linux work with apps written in 5.1

4. convert's labview 6.1 vi's to labview 5.1 vi's

5. Version Compatibility 6.1 to 5.1?

6. do I have to uninstall Labview 5.1 to install 6.1

7. 5.1 to 6.1?

8. Exospace -> Blinker 5.1 problem

9. jmp word ptr and jmp dword ptr

10. Stack overflow problem but increasing stack size does not solve the problem

11. Internet Toolkit <--> Labview 6.1

12. upgrade from 6.1 -> 7_EVAL

 

 
Powered by phpBB® Forum Software