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

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.

John,

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

Lol ! Go troll someone else, will you.

Regards,
Rudy Wieser

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.

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

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

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.

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]

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

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.

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

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

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.

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

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

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

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

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.

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

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/

On Monday, December 6, 2021 at 5:33:38 AM UTC-8, R.Wieser wrote:
> 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.

I'm not suggesting to magically deduce something from a register.
I'm thinking more of declaring a symbol for each string and deducing
the segment from that symbol (or it maybe a pair of symbols, one
for the offset, the other for the segment).

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

I don't remember the details and they are important.

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

I'm afraid that's unavoidable.

> > 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 ?

Sorry, it should've been "should NOT be using segmented memory".

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

Then embrace it. Write all of the plumbing by hand. :)

Alex

2021-12-07 at 00:19 +0100, Herbert Kleebauer wrote:
> 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.

In this line of thoughts, writing Java doesn't make sense, because it
requires installing a JRE first. Writing JavaScript doesn't make sense
because it requires a browser, even PHP is stupid because it is not
stand-alone executable code...

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

16-bit code has bigger chances of being useful in a few years than a
"modern" code has, given that libraries change, operating systems
change, etc. DOS is one of the very few "APIs" that are stable, while
the rest of the IT ecosystem is a moving target. Nowadays it is easy to
run a 16-bit program in a browser. Try doing the same with any other
executable program.

> Even if done as a hobby, the result should be something useful.

Ah, I only noticed the name now... A German. Should've guessed earlier.

Mateusz

Herbert,

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

Fail. No such destinction was made by you. And you are talking to someone
who (obviously?) has been doing 16-bit programming for a while now. IOW, it
looks like you are shifting goalposts.

> Because normally a program is not only executed once.

Fail again, as you making an assumption towards what *I* do with the result.
I could ofcourse tell you I've written 16-bit programs years ago that I
still use, but somehow I think you will just discard that as an "exception
to the rule".

> Even if done as a hobby, the result should be something useful.

And thats the actual point, isn't it ? You do not see the usefullness of
what I'm doing.

But instead of asking you just come out challenging me, suggesting that I
should stop doing it, even though I enjoy doing it.

And for the record, enjoying doing something is all thats needed for a
hobby - even if the result is of no use to anyone, including the one
practicing it. I'm sure you can think of a few hobbies like that.. I'll
give you the first one : collecting sugar sachets..

> Why mess around to make pictures with a camera.

You hit the nail on the head, but do not seem to be aware of it ....

Why /would/ you take pictures ? You would just waste *heaps* of time
making them, on possibly /very/ expensive equipment. And than spend even
more time on tagging them, possibly color-correcting, cropping and than
sorting/putting them into easy-findable-and-viewable groups. All so they
can be shown off to people who, more often than not, do not really care.

And by the way, I've got a friend which does all of the above, and is
mulling to go professional. He's simply that good. Something he would not
have known if he hadn't picked up photographing as a hobby ...

> but many programs written for MSDOS can still be executed in the current
> 32 bit Windows version.

Funny, the thing you started with was claiming that they wouldn't - and that
I, for that reason, should not be doing any 16-bit programming (anymore) ...

> The problem is, that AMD removed v86 mode in 64 bit mode

So they should have to support a 16 /as well as/ a 32 bit mode next to the
native, 64-bit one ? 'Cause that is what they did : just like a 32-bit
processor supported a 16-bit mode (one step down), a 64-bit processor now
supports a 32-bit mode.

> Microsoft didn't add a software DOS emulator in 64 bit Windows.

Than look around a bit. Don't expect MS to just drop everything into your
lap. Google for "DOSBox 64-bit".

Regards,
Rudy Wieser

Alexei,

> I'm thinking more of declaring a symbol for each string and deducing
> the segment from that symbol (or it maybe a pair of symbols, one
> for the offset, the other for the segment).

To be honest, I didn't think of that.

It would possibly be workable for simple situations, like the
single-argument int 21h, AH=09h. It wouldn't for anything that used more
than one pointer argument (into different segments) though.

IOW, it would need constant scrutiny by me, the programmer, to make sure
that all (applied by macros ?) "fixes" would actually work. :-( Ehh...
no. Although possible not really a solution.

> I don't remember the details and they are important.

I did not provide any other than "[stack based item]", which I thought would
be picked up by anyone here as either "[bp-xxxx]" or "[sp+xxxx]". I was
mistaken. :-|

> I'm afraid that's unavoidable.

That is what I thought, but wanted to make sure I did not overlook anything
/ something simpler.

>> > 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 ?
>
> Sorry, it should've been "should NOT be using segmented memory".

:-) In that case, I'm not (yet). I've been using the "tiny" memory model
where CS = DS = SS , as that one is easiest to work with and I simply have
never had the need for more memory (in relation to those three segments).

Its just that I saw a possible situation (I was thinking about recursion and
how it gobbles stack memory), and wondered how that would work. As it turns
out, not even Borland actually wished to burn their fingers on it - all its
memory models set SS to the same as DS.

> Then embrace it. Write all of the plumbing by hand. :)

As programmers we're supposed to be "lazy". If something repeats than we
rather spend an hour to solve a 10 minute problem than to write it twice,
let alone more than that. :-)

The bottom line is that a memory model with SS <> DS is simply no fun to
deal with. As I could have guessed if I would have looked at the offered
memory models earlier. Hmmm... Probably would not have stopped me from
asking though. <whistle>

Regards,
Rudy Wieser

Herbert,

A reply to your "no good for starters" claim :

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

1) In relation to "without first installing additional software ". Most
programming languages need you to install software and configure it. Heaps
of it. To create 16-bit programs al you need are three executables (an
editor, the assembler and the linker) and *perhaps* (something like) DOSBox.

2) Its "much easier 32 bit coding" was, IIRC related to having all segments
ontop of each other. Funny thing that, as that is exactly what the "tiny"
memory model does for a 16-bit program. Yes, because it makes things
simple (my question was just about me thinking "outside the box").

As for using 32-bit (or 64-bit) coding instead of 16-bit ? I don't think
it matters much - though I think that the best way to learn actual
programming is /not/ to have too much support from libraries and the like.

When you have it becomes too easy to create monstrocities instead of the way
more apropriate (smaller, faster) processor commands. One example I still
remember is how someone using a higher language isolated a bit in a value :
(SomeValue & 2^SomeBit) <> 0. Yuck.

Bottom line : When learning to really program* I think that using a "dumb"
target is best. 16-bit DOS programming would be a good choice, both because
it offers only basic I/O support as well as most people nowerdays have
computers and thus can do it anywhere (school as well as at home).

*as opposed to slap-dashing some scripting / high-level language together.

Though I think that programming machine code on a micro controller, possibly
mounted on a model car or a robotic something, would be even better : most
people need, especially when starting, to see a direct result of what they
have put their energy into.

In other words : Its not about which language or platform you use, as long
as it teaches you what makes the bottom layer (the processor and I/O) tick,
as well as makes you aware that everything comes with a cost (execution time
and/or resource wise). Those are lessons that should be learned early on.

I hope that answers your (second, new) question.

Regards,
Rudy Wieser