Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #4088 > unrolled thread

How to access stack-based data (strings) when SS <> DS ?

Back to article view | Back to comp.os.msdos.programmer

Contents

  How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 08:56 +0100
    Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 12:47 +0000
      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 15:57 +0100
        Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 16:13 +0000
          Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 18:41 +0100
            Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 20:28 +0000
              Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 08:56 +0100
                Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-05 10:32 +0000
                  Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 13:11 +0100
                    Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-05 12:21 +0000
                      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 14:59 +0100
          Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 19:00 +0100
    Re: How to access stack-based data (strings) when SS <>  DS ? JJ <jj4public@gmail.com> - 2021-12-05 14:27 +0700
      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 12:43 +0100
    Re: How to access stack-based data (strings) when SS <> DS ? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2021-12-05 22:25 -0800
      Re: How to access stack-based data (strings) when SS <> DS ? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-06 09:30 +0100
      Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-06 14:33 +0100
        Re: How to access stack-based data (strings) when SS <> DS ? Herbert Kleebauer <klee@unibwm.de> - 2021-12-06 19:01 +0100
          Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-06 21:16 +0100
            Re: How to access stack-based data (strings) when SS <> DS ? Herbert Kleebauer <klee@unibwm.de> - 2021-12-07 00:19 +0100
              Re: How to access stack-based data (strings) when SS <> DS ? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-07 09:31 +0100
              Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-07 09:37 +0100
              Re: How to access stack-based data (strings) when SS <> DS ?   Newbie language. "R.Wieser" <address@not.available> - 2021-12-08 10:16 +0100
                Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. Herbert Kleebauer <klee@unibwm.de> - 2021-12-08 17:39 +0100
                  Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-08 17:37 +0000
                    Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. Herbert Kleebauer <klee@unibwm.de> - 2021-12-08 22:31 +0100
                      Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-09 21:43 +0000
                  Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "R.Wieser" <address@not.available> - 2021-12-08 22:19 +0100
        Re: How to access stack-based data (strings) when SS <> DS ? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2021-12-06 22:40 -0800
          Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-07 10:17 +0100

Page 1 of 2  [1] 2  Next page →

#4088 — How to access stack-based data (strings) when SS <> DS ?

Hello all,

As an assembly programmer I never needed to write *big* programs, and 
therefore always used the "tiny" memory model where CS = DS = SS.

Though at some point I realized that not having SS equal to DS creates its 
own problems - when trying to access stack-based data (strings).

A "lea dx,[Stack-based item]" will work, but, for example, using it with 
"mov ah,09h", "int 21h" will ofcourse fail, as DX is not pointing into DS.

My question :
Does anyone know how this is solved ?   Other than (manually!) wrapping all 
such calls in a "push ds", "mov ax,ss", "mov ds,ax" .... "pop ds" sequences 
I mean.

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#4093

On Sat, 4 Dec 2021 08:56:24 +0100
"R.Wieser" <address@not.available> wrote:

> Hello all,
> 
> As an assembly programmer I never needed to write *big* programs, and 
> therefore always used the "tiny" memory model where CS = DS = SS.
> 
> Though at some point I realized that not having SS equal to DS
> creates its own problems - when trying to access stack-based data
> (strings).
> 
> A "lea dx,[Stack-based item]" will work, but, for example, using it
> with "mov ah,09h", "int 21h" will ofcourse fail, as DX is not
> pointing into DS.
> 
> My question :
> Does anyone know how this is solved ?   Other than (manually!)
> wrapping all such calls in a "push ds", "mov ax,ss", "mov ds,ax" ....
> "pop ds" sequences I mean.
> 
No, sorry. Why would I put strings in the stack space?


-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#4095

John,

> No, sorry. Why would I put strings in the stack space?

Lol !   Go troll someone else, will you.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4097

On Sat, 4 Dec 2021 15:57:16 +0100
"R.Wieser" <address@not.available> wrote:

> John,
> 
> > No, sorry. Why would I put strings in the stack space?
> 
> Lol !   Go troll someone else, will you.
> 
I'm sorry, it wasn't meant as a troll. I see now that I misread it.
[context reinserted]
> A "lea dx,[Stack-based item]" will work, but, for example, using it
> with "mov ah,09h", "int 21h" will ofcourse fail, as DX is not
> pointing into DS.

If ss<>ds then to load /dx/ with a saved string pointer (which I think
is what you want) I'd use the 'pop' instruction.

I'd keep the strings in /ds/.

I presume you're after something like /mov dx,[ss:stack+offset]/

-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#4099

John,

>> Lol !   Go troll someone else, will you.
>>
> I'm sorry, it wasn't meant as a troll.

Phew !  Thank {deity} for that.

> If ss<>ds then to load /dx/ with a saved string pointer

I'm sorry, are you /sure/ you aren't trolling ?   Since when does "lea" load 
something that was saved ?

> I'd use the 'pop' instruction.

No you wouldn't.

I can ofcourse explain to you how "lea" works, but I always got the idea you 
knew more about programming than I ever will.  IOW, whats going on here ?

> I presume you're after something like /mov dx,[ss:stack+offset]/

Definitily not.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4103

On Sat, 4 Dec 2021 18:41:26 +0100
"R.Wieser" <address@not.available> wrote:

> John,
> 
> >> Lol !   Go troll someone else, will you.
> >>
> > I'm sorry, it wasn't meant as a troll.
> 
> Phew !  Thank {deity} for that.
> 
> > If ss<>ds then to load /dx/ with a saved string pointer
> 
> I'm sorry, are you /sure/ you aren't trolling ?   Since when does
> "lea" load something that was saved ?
> 
> > I'd use the 'pop' instruction.
> 
> No you wouldn't.
> 
> I can ofcourse explain to you how "lea" works, but I always got the
> idea you knew more about programming than I ever will.  IOW, whats
> going on here ?
> 
You are very kind; no I think befuddlement is setting in here. OTOH I
rarely use /lea/.

> > I presume you're after something like /mov dx,[ss:stack+offset]/
> 
> Definitily not.
> 

OK I'll bow out, I'm clearly not understanding your requirement.

-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#4108

John,

> OTOH I rarely use /lea/.

In a nutshell : "lea" returns a pointer to somewhere.  "mov" copies to/from 
somewhere.

Although "lea ax,address" and "mov ax,offset address" return the same thing, 
"lea"s strength lies in that it can accept a relative part in the form of a 
register.

Like "lea ax, [si+4]".   Load ax with the address four bytes beyond what SI 
is pointing at.

> OK I'll bow out, I'm clearly not understanding your requirement.

I posted a small addendum. My mistake was that I assumed that "[stack 
based]" would be understood as referring to a procedure-local variable or 
buffer.   IOW, "[stack based]" translates, for my example, to "[bp-xxxx]"

To be honest, I have not ever heard someone storing / retrieving data using 
absolute adressing inside the SS segment.  Instead always relative to either 
BP or SP.

Code example :
- - - - - - - - - - - - - - - - - -

MyProc:
    push   bp
    mov    bp,sp
    sub    sp,0100h    ;<- create a local buffer.

    ...

    lea    dx,[bp-0100h]    ;<- Point to the buffer
    mov    ah,09h
    int    21h

- - - - - - - - - - - - - - - - - -

Now imagine that you're using a memory model where DS <> SS.  The problem 
than is that in the above code DX is relative to SS, but int 21, ah=09h 
expects it to be relative to DS.

What I was wondering is how this would be handled by/in professional 
software (compilers).


Than again, I think I painted myself in a corner.  :-|

Although I was thinking of some code which would allocate a stack segment 
and initialise SS:SP to it (causing SS to become different from DS), when I 
this morning looked at the different memory models Borlands Tasm offers I 
could only find one which /doesn't/ set up SS equal to DS.  and that one, 
"TPASCAL", isn't even a standard one.   I wonder why that is. :-)

Its like having 20/20 vision looking back.  If only I had something like 
that beforehand ...

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4109

On Sun, 5 Dec 2021 08:56:51 +0100
"R.Wieser" <address@not.available> wrote:

[Full explanation snipped for brevity]
> 
> 
> Than again, I think I painted myself in a corner.  :-|
> 
> Although I was thinking of some code which would allocate a stack segment 
> and initialise SS:SP to it (causing SS to become different from DS), when I 
> this morning looked at the different memory models Borlands Tasm offers I 
> could only find one which /doesn't/ set up SS equal to DS.  and that one, 
> "TPASCAL", isn't even a standard one.   I wonder why that is. :-)
> 
> Its like having 20/20 vision looking back.  If only I had something like 
> that beforehand ...
> 

I think that's it; the answer is "don't do that" (Sebastian!);

It still seems to me you were trying to use stack space to store strings. 


-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#4111

John,

> I think that's it; the answer is "don't do that" (Sebastian!);

:-)  Yep.  Not because it cannot work, but because it just costs too much 
work.

The thing is that I knew a way to deal with it (the wrapper code I mentioned 
in my first post), but wanted to know if there would be a simpler approach, 
making a SS <> DS setup feasable to use.

> It still seems to me you were trying to use stack space to store strings.

:-)  Not only trying, but have done so for quite a number of years now.

Are you trying to tell me that you have never used procedure-local variables 
?

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4112

On Sun, 5 Dec 2021 13:11:44 +0100
"R.Wieser" <address@not.available> wrote:

> John,
> 
> > I think that's it; the answer is "don't do that" (Sebastian!);
> 
> :-)  Yep.  Not because it cannot work, but because it just costs too much 
> work.
> 
> The thing is that I knew a way to deal with it (the wrapper code I mentioned 
> in my first post), but wanted to know if there would be a simpler approach, 
> making a SS <> DS setup feasable to use.
> 
> > It still seems to me you were trying to use stack space to store strings.
> 
> :-)  Not only trying, but have done so for quite a number of years now.
> 
> Are you trying to tell me that you have never used procedure-local variables 
> ?

Yes. I'm not the whizz programmer you thought I was!

-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#4113

John,

>> Are you trying to tell me that you have never used procedure-local
>> variables ?
>
> Yes. I'm not the whizz programmer you thought I was!

I think you are /at least/ knowledgable, but with a different interrest in 
programming than I have.

I've been programming Assembly for ... ages now, and have actually written 
code as I posted in the grandparent post (three-and-half hours ago).

That was before I found out that Borlands Tasm allowed some syntactic sugar 
to make usage of procedures and local variables (and stack-based, pushed 
arguments!) /much/ easier.

And as you might have noticed, I still do not know everything about it 
(might already have forgotten a thing or two too). And I hope it stays that 
way - otherwise I have to find myself another hobby... :-)

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4100

.... aaanndd I think I might be to blame for some of the confusion :

When I said "lea dx,[Stack-based item]" I ment a local buffer in a 
procedure.   So, it translates to "lea dx,[bp-xxxx]".    The usage of "bp" 
ofcourse causes the target to be in the SS segment.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4107

On Sat, 4 Dec 2021 08:56:24 +0100, R.Wieser wrote:
> Hello all,
> 
> As an assembly programmer I never needed to write *big* programs, and 
> therefore always used the "tiny" memory model where CS = DS = SS.
> 
> Though at some point I realized that not having SS equal to DS creates its 
> own problems - when trying to access stack-based data (strings).
> 
> A "lea dx,[Stack-based item]" will work, but, for example, using it with 
> "mov ah,09h", "int 21h" will ofcourse fail, as DX is not pointing into DS.
> 
> My question :
> Does anyone know how this is solved ?   Other than (manually!) wrapping all 
> such calls in a "push ds", "mov ax,ss", "mov ds,ax" .... "pop ds" sequences 
> I mean.
> 
> Regards,
> Rudy Wieser

Well, you'll have to change the segment register to the correct segment when 
using interrupts which only accept offset(s).

As for general use... Is segment override not applicable? e.g.

  mov  ax, ss:[bx]
  mov  dx, ds:[sp]

[toc] | [prev] | [next] | [standalone]

#4110

JJ,

> As for general use... Is segment override not applicable? e.g.

For "general use" as in what I write myself ?   Ofcourse.

The problem is that most system calls (like for example int 21h, AH=09h - 
display a string) are hard-tied to using the DS segment when they access the 
data that is pointed to.   No override possible.

But, it looks I painted myself in a corner here.

Although you certainly /can/ create a program where DS and SS are set to 
different segments, none of the memory models (tiny, small, etc.) you can 
chose do that.

Probably for a good reason.  The reason I bumped into.  Its simply /way/ to 
cumbersome to have to deal with a SS <> DS setup. :-)

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4116 — Re: How to access stack-based data (strings) when SS <> DS ?

On Saturday, December 4, 2021 at 12:18:18 AM UTC-8, R.Wieser wrote:
> Hello all, 
> 
> As an assembly programmer I never needed to write *big* programs, and 
> therefore always used the "tiny" memory model where CS = DS = SS. 
> 
> Though at some point I realized that not having SS equal to DS creates its 
> own problems - when trying to access stack-based data (strings). 
> 
> A "lea dx,[Stack-based item]" will work, but, for example, using it with 
> "mov ah,09h", "int 21h" will ofcourse fail, as DX is not pointing into DS. 
> 
> My question : 
> Does anyone know how this is solved ? Other than (manually!) wrapping all 
> such calls in a "push ds", "mov ax,ss", "mov ds,ax" .... "pop ds" sequences 
> I mean. 

I'd advise looking into some kind of macro assembly.
If your assembler can tell you where (in what segment) a variable is
allocated (assuming it can actually allocate a variable on the stack
just like in the data segment) and if the assembler can conditionally
assemble code based on that, then you can eliminate some unnecessary
segment manipulation.
Another option is, if your assembler can examine variable/label
names, you may encode the segment into the name, which is ugly,
but may work.
Lastly, perhaps you should be using segmented memory
or you could generate code by some means other than the assembler
and more higher level.

Alex

[toc] | [prev] | [next] | [standalone]

#4119 — Re: How to access stack-based data (strings) when SS <> DS ?

2021-12-05 at 22:25 -0800, Alexei A. Frounze wrote:
> Lastly, perhaps you should be using segmented memory or you could
> generate code by some means other than the assembler and more higher
> level.

That's an excellent advice. There's a very good instructional video
about exactly that on youtube: https://youtu.be/1S1fISh-pag

Mateusz

[toc] | [prev] | [next] | [standalone]

#4121 — Re: How to access stack-based data (strings) when SS <> DS ?

Alexei,

> I'd advise looking into some kind of macro assembly.

Borlands Tasm does support macros.  But alas, they do not measure up to the
inbuild method of calling procedures and its checking of the (ammount and
type of) provided arguments.

> If your assembler can tell you where (in what segment) a variable
> is allocated

Nope.  That "lea dx,[bp-xxxx]" implicitily uses SS as its base. There is no
way to tell by looking at DX itself.

> (assuming it can actually allocate a variable on the stack just like in
> the data segment)

<huh?> You're the second one who doubts that, even though procedure-local
variables are a thing in most any language ...

> and if the assembler can conditionally assemble code based on that,
> then you can eliminate some unnecessary segment manipulation.

I'm not at all sure I can override build-in menemonics to execute a macro
...   Otherwise I would need to add pseudo(?) code around pretty-much
everything.

> Lastly, perhaps you should be using segmented memory

Isn't that what is what started my problem ?  Putting DS into a different
segment than SS ?

> or you could generate code by some means other than the
> assembler and more higher level.

:-)   I like Assembly because it /doesn't/ hide all kinds of stuff from me.

Thanks for the suggestions.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4123 — Re: How to access stack-based data (strings) when SS <> DS ?

On 06.12.2021 14:33, R.Wieser wrote:

> :-)   I like Assembly because it /doesn't/ hide all kinds of stuff from me.

But nearly no PC can execute 16 bit code directly these days. That's like
writing a novel in ancient Greek. So what sense does it make to still write
16 bit code? And 32 bit code also has the advantage, that you don't have to
mess around with segments.

[toc] | [prev] | [next] | [standalone]

#4124 — Re: How to access stack-based data (strings) when SS <> DS ?

Herbert,

> But nearly no PC can execute 16 bit code directly these days.

For starters, why including a restriction like "directly" ?  How does that 
matter ?

And for seconds, how does "nearly no PC" matter as long as mine does ?

> So what sense does it make to still write 16 bit code?

What sense does it make for anyone to have a hobby ?   Its a waste of time, 
not bringing any money on the table.

> And 32 bit code also has the advantage, that you don't have to
> mess around with segments.

True.  But why "mess around" with it /at all/ ?  I'm sure there are lots of 
well-payed professional programmers which can deliver much better quality in 
a much shorter time.

But a question : why are you (still?) in this newsgroup, which is all about 
an OS that has been obsolete for over 20 years and, listening to you, likely 
won't even be able to run on any of your computers ...

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4125 — Re: How to access stack-based data (strings) when SS <> DS ?

On 06.12.2021 21:16, R.Wieser wrote:

>> But nearly no PC can execute 16 bit code directly these days.

> For starters, why including a restriction like "directly" ?  How does that
> matter ?

A program is written in order to be executed. To write a program
which can be executed on nearly none of the current computers
(without first installing additional software like DOSBox) doesn't
make much sense. And therefore it doesn't also make much sense for
a "starter" to start with 16 bit coding instead of the much easier
32 bit coding.


> And for seconds, how does "nearly no PC" matter as long as mine does ?

Because normally a program is not only executed once. And if the
code still can be useful in a few years, it shouldn't be written
for a system which is obsolete already now.


>> So what sense does it make to still write 16 bit code?
> 
> What sense does it make for anyone to have a hobby ?   Its a waste of time,
> not bringing any money on the table.

Even if done as a hobby, the result should be something useful. And
a program is only useful if it can be executed. Maybe somebody else
would like to use the functions provided by the code, but it is
useless because he can't execute it on current hardware. I don't
see any advantage in writing code for obsolete systems, but many
disadvantages.


>> And 32 bit code also has the advantage, that you don't have to
>> mess around with segments.
> 
> True.  But why "mess around" with it /at all/ ?  I'm sure there are lots of
> well-payed professional programmers which can deliver much better quality in
> a much shorter time.

Why mess around to make pictures with a camera. I'm sure there are lots of
well-payed professional photographer which can deliver much better quality in
a much shorter time. But if you take pictures, store them in a format which
can be displayed on current systems without the need of installing additional
software. And if you write software, use a format which can be executed
on current systems.


> But a question : why are you (still?) in this newsgroup, which is all about
> an OS that has been obsolete for over 20 years and, listening to you, likely
> won't even be able to run on any of your computers ...

The operating system MSDOS may be obsolete since 20 years, but many programs
written for MSDOS can still be executed in the current 32 bit Windows
version. The problem is, that AMD removed v86 mode in 64 bit mode and
Microsoft didn't add a software DOS emulator in 64 bit Windows. In Windows 11
you now can install and execute Android apps but no 16 bit DOS code. Well
done Microsoft! https://docs.microsoft.com/en-us/windows/android/wsa/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.msdos.programmer

csiph-web