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


Groups > comp.os.msdos.programmer > #4120

Re: initial memory - SS:SP

From "R.Wieser" <address@not.available>
Newsgroups comp.os.msdos.programmer
Subject Re: initial memory - SS:SP
Date 2021-12-06 14:32 +0100
Organization Aioe.org NNTP Server
Message-ID <sol3fe$1g7s$1@gioia.aioe.org> (permalink)
References (1 earlier) <socrrm$1tl0$1@gioia.aioe.org> <0e2bde4b-b93c-481c-9525-cdb03d863b1dn@googlegroups.com> <sod5i3$j44$1@gioia.aioe.org> <6600e32b-5168-459a-ab8d-93eeeca412b8n@googlegroups.com> <soe3dh$uvq$1@gioia.aioe.org>

Show all headers | View raw


Muta (paul),

> But I owe you an apology : I remember updating SS/SP after setting 
> MaxAlloc to MinAlloc, but a peek into my program (still have it!) showed I 
> made it optional.  In case I did not define a stack segment at all (but 
> just kept some BSS space free for it), causing SS:SP to be Zero in the EXE 
> header. And that ofcourse doesn't really work.  So, I than can force it to 
> be set to the end of the BSS segment itself.

I took another look at the EXE header and how it sets up SS:SP. I had to 
notice that regardless of the memory model I chose (tiny, small, etc.) it 
was either 0:0, or SS being an offset to the defined ".stack ..." area and 
SP its size.  IOW, it /never/ pointed at what DS should be(come).

As I always use the "tiny" memory model (again, my programs never get /that/ 
big), a (p)recalculation of SS:SP is rather simple : add (SS - CS) * 10h to 
SP and set SS to Zero.   In the program itself than only CS needs to be 
copied to DS (and possibly ES).

In all other memory models this is not possible as there DS is never equal 
CS, and DS is not mentioned in the executables header (meaning you can't 
recalculate SS in reference to it)

... having said that, if you want to use memory models other than "tiny" you 
could try to see if you could find the start of the _DATA segment from the 
generated .LST file :

-- "Tiny" memory model

DGROUP      Group
..STACK      16  0100 Para   Stack   STACK
.._BSS      16  000E Word   Public  BSS
.._DATA      16  0017 Word   Public  DATA
.._TEXT      16  0958 Word   Public  CODE

(".." indicates indentation)

The above looks to be indicating that all groups are inside DGROUP.

-- "Small" memory model

DGROUP      Group
..STACK      16  0100 Para   Stack   STACK
.._BSS      16  0800 Word   Public  BSS
.._DATA      16  0043 Word   Public  DATA
_TEXT      16  0288 Word   Public  CODE

Here the "_TEXT" group is outside the DGROUP.  The start of the "_DATA" 
segment /should/ therefore be the size of the "_TEXT" segment, rounded-up to 
the next segment ofcourse -> 0290.  And a quick check in the executable 
shows that is indeed the case.

A double check using "mov ax,_DATA" shows the same (subtract CS and multiply 
by 10h)

Caveat : I've only looked at the TINY and SMALL models, in Tasms default 
configuration (its possible to have the segments in a different order).

Hope that helps.

Regards,
Rudy Wieser

Back to comp.os.msdos.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-02 14:07 -0800
  Re: initial memory JJ <jj4public@gmail.com> - 2021-12-03 15:05 +0700
    Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 00:38 -0800
      Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-03 09:45 +0100
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 01:22 -0800
        Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:00 +0700
          Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 08:39 +0100
          Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 09:35 +0100
            Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 13:00 +0100
              Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 13:12 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 15:55 +0100
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 16:30 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 18:11 +0100
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 19:04 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 21:02 +0100
                Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:01 -0800
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-06 09:27 +0100
            Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:03 +0700
      Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:01 +0700
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-04 02:00 -0800
          Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:12 +0700
            Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:02 -0800
              Re: initial memory JJ <jj4public@gmail.com> - 2021-12-06 13:28 +0700
  Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 11:25 +0100
    Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 03:18 -0800
      Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 14:19 +0100
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 11:35 -0800
          Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 22:30 +0100
            Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:32 +0100
              Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:51 +0100

csiph-web