Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #4120
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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