Board index » delphi » Switching stack-segment.

Switching stack-segment.

Hi!

I'm working on a BPW 7 program and need to get rid of the stack in the
data-segment. At the moment I'm down to 1k local heap and 16k stack,
and that is not enough.
Long time ago in DOS I had a piece of code that could create a
separate stack segment.
Do anone have such a code-snippet for Win311. I simply need to
allocate a 64k memoryblock, and switch the stack segment to that
memory-block.

Any tips?

TIA

--
Venlig hilsen / Best regards
        Henning

  _H_P_C_o_n_s_u_l_t_     E-mail:  mailto:henning.peter...@hpc.dk
  Skoletoften 9, Blans    Work:    http://www.hpc.dk
  DK - 6400 Soenderborg   Private: http://home1.inet.tele.dk/oz1lln

 

Re:Switching stack-segment.


In article <3578114d.19099...@news.inet.tele.dk>

Quote
henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:
> Hi!

> I'm working on a BPW 7 program and need to get rid of the stack in the
> data-segment. At the moment I'm down to 1k local heap and 16k stack,
> and that is not enough.
> Long time ago in DOS I had a piece of code that could create a
> separate stack segment.
> Do anone have such a code-snippet for Win311. I simply need to
> allocate a 64k memoryblock, and switch the stack segment to that
> memory-block.

> Any tips?

I can't help you with separate stacks, but I can give a few
hints.

1. Increase the stack with "{$M}"
2. Use "Const" (or "Var" if appropriate) parameters for big
data structures, including strings.
3. Avoid unnecessary recursion
4. Use dynamic variables in procedures and functions
(these get allocated on the heap). You can do this even
with strings.

Best regards, The Chief
--------
Dr. A{*word*73}la A. Olowofoyeku (The African Chief)
Email: la...@keele.ac.uk
Homepage: http://ourworld.compuserve.com/homepages/African_Chief/
Author of: Chief's Installer Pro v4.25 for Win16 and Win32:
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief425.zip

Re:Switching stack-segment.


On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African

Quote
Chief) wrote:
> I can't help you with separate stacks, but I can give a few
> hints.

To bad, but I need to get another stack-segment.

Quote
> 1. Increase the stack with "{$M}"

At the moment I'm using {$17000,1024} and I need minimum 16k for
normal operation, in some cases it's not enough, because I have a
couple if routiones running on a wm_timer event.

Quote
> 2. Use "Const" (or "Var" if appropriate) parameters for big
> data structures, including strings.

I've tried to minimize the stack-use.

Quote
> 3. Avoid unnecessary recursion

Not using any recursion.

Quote
> 4. Use dynamic variables in procedures and functions
> (these get allocated on the heap). You can do this even
> with strings.

Might look a little nor on this point.

But my main problem is that on of my wm_timer events do a lot of
string handling, and a simple Sting1:=Sting2+Sting3+Sting4 consumes
_Very_ much memory :-(

I have tried to do the string-handling with PChar's but that's not
possible/easy in those functions.

--
Venlig hilsen / Best regards
        Henning

  _H_P_C_o_n_s_u_l_t_     E-mail:  mailto:henning.peter...@hpc.dk
  Skoletoften 9, Blans    Work:    http://www.hpc.dk
  DK - 6400 Soenderborg   Private: http://home1.inet.tele.dk/oz1lln

Re:Switching stack-segment.


Quote
Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:

: On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
Quote
: Chief) wrote:

: > I can't help you with separate stacks, but I can give a few
: > hints.
:
: To bad, but I need to get another stack-segment.

       Are you calling procedures and passing strings?

: But my main problem is that on of my wm_timer events do a lot of
: string handling, and a simple Sting1:=Sting2+Sting3+Sting4 consumes
: _Very_ much memory :-(

       That's common enough, but are you passing any
of these strings when you call a procedure?

       Sometimes a program needs to be balanced between
global variables, local variables, and stack passed variables.
       I have a Backgammon game that has stack overflow
when I'm winning. :-)

Ken Fischer

---

Re:Switching stack-segment.


On Fri, 5 Jun 1998 22:49:29 GMT, kefis...@iglou.com (Ken Fischer)
wrote:

Quote
> Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:
> : On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
> : Chief) wrote:
> : > I can't help you with separate stacks, but I can give a few
> : > hints.
> :
> : To bad, but I need to get another stack-segment.

>        Are you calling procedures and passing strings?

Not that much. Most of my data is transfered at binary data or
records.

Quote
> : But my main problem is that on of my wm_timer events do a lot of
> : string handling, and a simple Sting1:=Sting2+Sting3+Sting4 consumes
> : _Very_ much memory :-(

>        That's common enough, but are you passing any
> of these strings when you call a procedure?

Usualy I use a var og const declaration to save stact space, but it
still take up too much memory. I sopose you're question refers to the
doubling of stack requeired when passing strings as

        Procedure Proc(S : String);

but everywhere it's posible i use

        Procedure Proc(Const S : String);

any other tips?

Quote
>        Sometimes a program needs to be balanced between
> global variables, local variables, and stack passed variables.
>        I have a Backgammon game that has stack overflow
> when I'm winning. :-)

Well, that's to bad ;-)

--
Venlig hilsen / Best regards
        Henning

  _H_P_C_o_n_s_u_l_t_     E-mail:  mailto:henning.peter...@hpc.dk
  Skoletoften 9, Blans    Work:    http://www.hpc.dk
  DK - 6400 Soenderborg   Private: http://home1.inet.tele.dk/oz1lln

Re:Switching stack-segment.


In article <357b8ff2.51487...@news.inet.tele.dk>,
  henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:

Quote

> On Fri, 5 Jun 1998 22:49:29 GMT, kefis...@iglou.com (Ken Fischer)
> wrote:

> > Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:
> > : On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
> > : Chief) wrote:
> > : > I can't help you with separate stacks, but I can give a few
> > : > hints.
> > :
> > : To bad, but I need to get another stack-segment.

> >        Are you calling procedures and passing strings?
> Not that much. Most of my data is transfered at binary data or
> records.

> > : But my main problem is that on of my wm_timer events do a lot of
> > : string handling, and a simple Sting1:=Sting2+Sting3+Sting4 consumes
> > : _Very_ much memory :-(

Ever thought about using move to concatenate strings, as in

const s1: string[7] = '';
const s2: string[7] = 'Test2';
const s3: string[7] = 'Test3';

begin
  s1:= s2 + s3;

  writeln(s1);
  s1:= 'XXXXXXX';

  move(s2, s1, sizeof(s1)); {may move too much of s2, but doesn't do any harm}
  writeln(s1);

  {move may do nothing, may want to add test}
  move(s3[1], s1[byte(succ(s1[0]))], sizeof(s1) - byte(s1[0]) - 1);

  if byte(s1[0]) + byte(s3[0]) > sizeof(s1) then
    s1[0]:= char(pred(sizeof(s1)))
  else
    s1[0]:= char(byte(s1[0]) + byte(s3[0]));

  writeln(s1);
end.

May not look very pretty (ugly is the correct word), but uses no stack...

Also, I remember that there is a snippet in SWAG about setting up an new
stack, but I don't have it readily available.

- Show quoted text -

Quote

> >        That's common enough, but are you passing any
> > of these strings when you call a procedure?
> Usualy I use a var og const declaration to save stact space, but it
> still take up too much memory. I sopose you're question refers to the
> doubling of stack requeired when passing strings as

>    Procedure Proc(S : String);

> but everywhere it's posible i use

>    Procedure Proc(Const S : String);

> any other tips?

> >        Sometimes a program needs to be balanced between
> > global variables, local variables, and stack passed variables.
> >        I have a Backgammon game that has stack overflow
> > when I'm winning. :-)
> Well, that's to bad ;-)

Regards,

Robert
--
Robert AH Prins
prin...@wcg.co.uk

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re:Switching stack-segment.


In article <357845aa.32489...@news.inet.tele.dk>

Quote
henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:
> On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
> Chief) wrote:

>> I can't help you with separate stacks, but I can give a few
>> hints.
> To bad, but I need to get another stack-segment.

I have never seen a program that *needs* another
stack segment. You might think that you need another
stack segment, but you don't ;)

Quote
>> 1. Increase the stack with "{$M}"
> At the moment I'm using {$17000,1024} and I need minimum 16k for
> normal operation, in some cases it's not enough, because I have a
> couple if routiones running on a wm_timer event.

What is wrong with a stack of 32k? Your stack can be as
large as "64k - the size of your static global data."

Quote
>> 4. Use dynamic variables in procedures and functions
>> (these get allocated on the heap). You can do this even
>> with strings.
> Might look a little nor on this point.

Looking into this might yield great dividend.
If you do this;

Procedure X(Const Y:string);
Var
s1,s2,s3:String;
Rec: MyRecord;
begin

end;

You have "256*3 + sizeof(MyRecord)" bytes on the stack.
If you do

Procedure X(Const Y:string);
Var
s1,s2,s3:^String;
Rec: ^MyRecord;
begin

end;

You have just 16 bytes on the stack. Get my drift?

Quote
> But my main problem is that on of my wm_timer events do a lot of
> string handling, and a simple Sting1:=Sting2+Sting3+Sting4 consumes
> _Very_ much memory :-(

> I have tried to do the string-handling with PChar's but that's not
> possible/easy in those functions.

Using pChars might be code intensive  (e.g., instead of
"Sting1:=Sting2+Sting3+Sting4", you would need to do
something like;
  StrCat(pChar1, pChar2);
  StrCat(pChar1, pChar3);
  StrCat(pChar1, pChar4);

But it does save on stack space.

On the other hand using pointers to strings, and,
 "Sting1^:=Sting2^+Sting3^+Sting4^" might do just
as well.

But before trying any of these, I would try a 32kb stack
first.

Best regards, The Chief
--------
Dr. A{*word*73}la A. Olowofoyeku (The African Chief)
Email: la...@keele.ac.uk
Homepage: http://ourworld.compuserve.com/homepages/African_Chief/
Author of: Chief's Installer Pro v4.25 for Win16 and Win32:
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief425.zip

Re:Switching stack-segment.


In <6lgi3n$in...@cfs2.kis.keele.ac.uk>,
The African Chief <nospam@African_Chief.nospam> wrote:

Quote
> If you do

> Procedure X(Const Y:string);
> Var
> s1,s2,s3:^String;
> Rec: ^MyRecord;
> begin

> end;

> [...]

> On the other hand using pointers to strings, and,
>  "Sting1^:=Sting2^+Sting3^+Sting4^" might do just
> as well.

Unfortunately not, since TP reserves space on the stack for the
(intermediate) results of the additions (here 2*256 Bytes, IIRC).

The only solution I know (besides using PChars, or using a 32 bit
compiler, of course) is to wrap the "+" into procedures:

procedure Add2Strings (var Dest: String; const Src1, Src2: String);
begin
  Dest := Src1 + Src2
end;

procedure Add3Strings ...

... (however many you need).

It doesn't exactly make the program look nicer, but it saves stack
space, since the temp storage is released immediately when the
Add*Strings procedures return.

--
Frank Heckenbach, frank@[NOSPAM.REMOVE.THIS]pascal.gnu.de
Internet links:   http://fjf.gnu.de/
Pascal programs:  http://fjf.gnu.de/programs.html (including BP Crt.Delay fix)
PGP and GPG keys: http://fjf.gnu.de/plan

Re:Switching stack-segment.


On 8 Jun 1998 11:32:07 GMT, nospam@African_Chief.nospam (The African

Quote
Chief) wrote:
> In article <357845aa.32489...@news.inet.tele.dk>
> henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:

> > On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
> > Chief) wrote:

> >> I can't help you with separate stacks, but I can give a few
> >> hints.
> > To bad, but I need to get another stack-segment.

> I have never seen a program that *needs* another
> stack segment. You might think that you need another
> stack segment, but you don't ;)

The program in question is running under windows (compiler BPW7), and
I'm down to 1k local heap, and ~17k stack. In windows local heap (wof
windows use) the stack + the data-segment(including all VMT tables) is
placed into the same segment, and therefor can onlyt take up 64k
overall.
What I want is to move the stack-segment out of the 64k segment. By
doing that I'd get 1) 64k of stack space (+/- overhead) and 2) 17k
space for new objects etc in the datasegment.

Quote
> >> 1. Increase the stack with "{$M}"
> > At the moment I'm using {$17000,1024} and I need minimum 16k for
> > normal operation, in some cases it's not enough, because I have a
> > couple if routiones running on a wm_timer event.

> What is wrong with a stack of 32k? Your stack can be as
> large as "64k - the size of your static global data."

Se above. The data segment consumse ~47kb som there is not that much
space left. (bloddy VMT-tables)

Quote
> >> 4. Use dynamic variables in procedures and functions

[example on how to change .....}
Quote
> Var
> s1,s2,s3:String;
[..... with .....]
> s1,s2,s3:^String;

Have been doing that for long time. Primarily because the program uses
some very large data-arrays for temporary data.

Quote
> Using pChars might be code intensive  (e.g., instead of
> "Sting1:=Sting2+Sting3+Sting4", you would need to do
> something like;
>   StrCat(pChar1, pChar2);
>   StrCat(pChar1, pChar3);
>   StrCat(pChar1, pChar4);
> But it does save on stack space.

> On the other hand using pointers to strings, and,
>  "Sting1^:=Sting2^+Sting3^+Sting4^" might do just
> as well.

As long as you add strings the temporary space is allocated on the
stack. So it don't matter if you use String og ^String as the
variables for your data.

Quote
> But before trying any of these, I would try a 32kb stack
> first.

I'd be glad if I could get that much free space for a stack, and
that's my problem.

--
Venlig hilsen / Best regards
        Henning

  _H_P_C_o_n_s_u_l_t_     E-mail:  mailto:henning.peter...@hpc.dk
  Skoletoften 9, Blans    Work:    http://www.hpc.dk
  DK - 6400 Soenderborg   Private: http://home1.inet.tele.dk/oz1lln

Re:Switching stack-segment.


In article <357bf355.10990...@news.inet.tele.dk>

Quote
henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:

[...]

Quote
>> I have never seen a program that *needs* another
>> stack segment. You might think that you need another
>> stack segment, but you don't ;)
> The program in question is running under windows (compiler BPW7), and
> I'm down to 1k local heap, and ~17k stack. In windows local heap (wof
> windows use) the stack + the data-segment(including all VMT tables) is
> placed into the same segment, and therefor can onlyt take up 64k
> overall.
> What I want is to move the stack-segment out of the 64k segment. By
> doing that I'd get 1) 64k of stack space (+/- overhead) and 2) 17k
> space for new objects etc in the datasegment.
[...]
>> What is wrong with a stack of 32k? Your stack can be as
>> large as "64k - the size of your static global data."
> Se above. The data segment consumse ~47kb som there is not that much
> space left. (bloddy VMT-tables)

I still stand by my statement that you do not need
a new stack segment. Basically, you need to make
more use of data structures allocated on the heap
in order to reduce the size of your data segment.
You do not need a data segment of 47kb. It might
involve a lot of recoding, but you could simply convert
all your global variables from static to dynamic. You would
be surprised at how much you can save from your data
segment by simply converting "String" to "^String". I do
this as a matter of routine (just have one procedure to
allocate the memory for the all the global string pointers  
when the program begins, and another to free all the
memory before the program terminates). Other areas
where this can be done are records and objects.

Instead of;

Var
MyObj:MyObject;
MyRec:MyRecord;

You can have
Var
MyObj:^MyObject;
MyRec:^MyRecord;

Working with pointers to objects should remove the
problem of the VMTs clogging up the data segment.

Treat this problem like you would eat an elephant
(one bite at a time ;-)) - remember, each byte that
you save from the data segment is one byte that
you can add to your stack. You might just need to
tinker with 4 or 5 global variables to achieve the
saving that you need.

However, if you must have another stack segment,
you might want to try Win16 API kludges like
PrestoChangoSelector() and AllocDStoCSAlias().
Perhaps these can be used in some way to solve
your problem? Sorry, but I don't know how they can
actually help you, but perhaps someone else might
be able to point to a way to use them productively
in this type of scenario.

Best regards, The Chief
--------
Dr. A{*word*73}la A. Olowofoyeku (The African Chief)
Email: la...@keele.ac.uk
Homepage: http://ourworld.compuserve.com/homepages/African_Chief/
Author of: Chief's Installer Pro v4.25 for Win16 and Win32:
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief425.zip

Re:Switching stack-segment.


Quote
Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:

: The program in question is running under windows (compiler BPW7), and
: I'm down to 1k local heap, and ~17k stack. In windows local heap (wof
: windows use) the stack + the data-segment(including all VMT tables) is
: placed into the same segment, and therefor can onlyt take up 64k
: overall.

      I am trying to understand what you are saying,
have you constructed your own stack?
      When you say "in the same segment", that confuses
me, segments are 64k from the segment base, and a segment
base can begin every 16 bytes if it does not conflict.
      Doesn't making tables and arrays in a separate unit
give them up to 64k?

: What I want is to move the stack-segment out of the 64k segment. By
: doing that I'd get 1) 64k of stack space (+/- overhead) and 2) 17k
: space for new objects etc in the datasegment.

       Could you explain this better please?   Are you
going by segment base addresses in debug, or what?
       I would expect the stack to get priority, but
space is not allocated in 64k pieces, and segment bases
do not have to be 64k apart, they can be on any address
dividable by 16.

       Could you make the program smaller? :-)

Ken Fischer

---

Re:Switching stack-segment.


Quote
Ken Fischer wrote:

> Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:
> : The program in question is running under windows (compiler BPW7), and
> : I'm down to 1k local heap, and ~17k stack. In windows local heap (wof
> : windows use) the stack + the data-segment(including all VMT tables) is
> : placed into the same segment, and therefor can onlyt take up 64k
> : overall.
>       When you say "in the same segment", that confuses
> me, segments are 64k from the segment base, and a segment
> base can begin every 16 bytes if it does not conflict.

Indeed, one segment can be 64k bytes, i.e. 1 segment value can
address 64 kB. MS-Windows (3.x) uses one (1) segment for local
heap, stack and data segment.
With other words, windows will use _one_ segment value (Seg(pointer))
(or, if you prefer, segment base) for all three, thereby limiting
the total of these three to 64kB, this is something you can't change
normally :(.

Quote
>       Doesn't making tables and arrays in a separate unit
> give them up to 64k?

Most definitely _not_: try it out for yourself: all global
variables from both main program and units are placed in the
same data segments (max. 64kB in real mode).

Quote
> : What I want is to move the stack-segment out of the 64k segment. By
> : doing that I'd get 1) 64k of stack space (+/- overhead) and 2) 17k
> : space for new objects etc in the datasegment.

>        Could you explain this better please?   Are you
> going by segment base addresses in debug, or what?
>        I would expect the stack to get priority, but
> space is not allocated in 64k pieces, and segment bases
> do not have to be 64k apart, they can be on any address
> dividable by 16.

In itself true in real mode, _but_ under windows you are in
protected mode, in which case your segments have become selectors.
You still can only address 64kB with one selector, but don't try
and use just any selector value, that will give you a General
Protection Fault (you must have seen these if you use windows).
For a discussion of windows or protected mode memory management
you'd better try and find a book, too complicated to explain here.
What Henning Petersen wants makes sense, though I have no idea
how do create a separate stack under windows.

Regards,

Remco
--
R.J. Vi?tor                    |  AFE Chemistry
remco @ chem.gla.ac.uk         |  Joseph Black Building
                               |  University of Glasgow
The views expressed in this    |  Glasgow G12 8QQ
message represent only the     |  UK
personal views of the author   |

Re:Switching stack-segment.


The African Chief <nospam@African_Chief.nospam> schrieb im Beitrag
<6lgi3n$in...@cfs2.kis.keele.ac.uk>...

Quote
> In article <357845aa.32489...@news.inet.tele.dk>
> henning.petersen.nospam.9...@hpc.dk (Henning Petersen) wrote:

> > On 5 Jun 1998 16:39:29 GMT, nospam@African_Chief.nospam (The African
> > Chief) wrote:

> >> I can't help you with separate stacks, but I can give a few
> >> hints.
> > To bad, but I need to get another stack-segment.

> I have never seen a program that *needs* another
> stack segment. You might think that you need another
> stack segment, but you don't ;)

Hmm... when one does multithreading (e.g. split a program into several
concurrent tasks), one always needs separated stacks for the threads. This is
true for both cooperative and preemtive threads.

Quote
> >> 1. Increase the stack with "{$M}"
> > At the moment I'm using {$17000,1024} and I need minimum 16k for
> > normal operation, in some cases it's not enough, because I have a
> > couple if routiones running on a wm_timer event.

> What is wrong with a stack of 32k? Your stack can be as
> large as "64k - the size of your static global data."

I guess he's trying to keep as much heap or even DOS memory free as possible.

If you *really* need to swap the stack, try something like:

procedure LargeStack;
begin
  {your code here}
end;

const
  StackSize=64000;

GetMem(Stack,StackSize);
asm
  cli
  mov ax,ss
  mov bx,sp
  mov cx,word ptr Stack
  mov dx,word ptr Stack+2
  mov ss,dx
  mov sp,cx
  add sp,StackSize
  sub sp,2
  push ax
  push bx
  sti
  call LargeStack
  cli
  pop bx
  pop ax
  mov ss,ax
  mov sp,bx
  sti
end;
FreeMem(Stack,StackSize);

I did not test the code above, but I think it should work. Don't forget to
turn the stack checking off in the compiler options. Note that stuff like
exception handling (as done in my EXCEPT unit) might fail in this type of
stack switching.

Quote
> Best regards, The Chief

--
Arsne von Wyss - avonw...@gmx.net
+---------------------------------------------------------------------------+
| Pascal, Delphi & Personal stuff: http://www.beaulieu-software.ch/avonwyss |
|  Prog. Contest Problems Archive: http://www.beaulieu-software.ch/contest  |
+---------------------------------------------------------------------------+
         |  "Is that your C program listing or is it line noise?"  |
         +---------------------------------------------------------+

Re:Switching stack-segment.


Quote
kefis...@iglou.com (Ken Fischer) wrote:
> Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:
> : The program in question is running under windows (compiler BPW7), and
> : I'm down to 1k local heap, and ~17k stack. In windows local heap (wof
> : windows use) the stack + the data-segment(including all VMT tables) is
> : placed into the same segment, and therefor can onlyt take up 64k
> : overall.

>       I am trying to understand what you are saying,
> have you constructed your own stack?
>       When you say "in the same segment", that confuses
> me, segments are 64k from the segment base, and a segment
> base can begin every 16 bytes if it does not conflict.

In principle you're right, but when compiling for windows the compiler
sets DSeg = SSeg, so the you only have 64k for DSeg and SSeg (+ local
heap).
Quote
>       Doesn't making tables and arrays in a separate unit
> give them up to 64k?

No DSeg is DSeg, and all your global data is located in thwe same
segment, so you only have 64k at your hand.

Quote
> : What I want is to move the stack-segment out of the 64k segment. By
> : doing that I'd get 1) 64k of stack space (+/- overhead) and 2) 17k
> : space for new objects etc in the datasegment.

>        Could you explain this better please?   Are you
> going by segment base addresses in debug, or what?

???? I'm not queit sure I understand you but I'll try to rephrase ;-)
The compiler (BPW7) creates an exe with 927k code, 46k data (global
data + VMT-tables), 18k stack and 1k local heap. My problem is that
the compiler puts the data, stack and local heap into the same
segment, though seting a limit of 64k for the sum of these three
data-blocks.
What my idea was/is, is to minimize the stack size, by taking a 64k
chunk of memory, and move the active stack into that segment, thereby
freeing data-segment-space for future expansions of the program, and
getting a full segment (64k) space in my stack.
-HTH

Quote
>        I would expect the stack to get priority, but
> space is not allocated in 64k pieces, and segment bases
> do not have to be 64k apart, they can be on any address
> dividable by 16.

Segments can be placed anywhere, but again the compiler don't let me
do it :-(

Quote
>        Could you make the program smaller? :-)

I wish I could, but it's likly to grow even more. But to do that I
deseratly need more space in DSeg / SSeg ;-)

--
Venlig hilsen / Best regards
        Henning

  _H_P_C_o_n_s_u_l_t_     E-mail:  mailto:henning.peter...@hpc.dk
  Skoletoften 9, Blans    Work:    http://www.hpc.dk
  DK - 6400 Soenderborg   Private: http://home1.inet.tele.dk/oz1lln

Re:Switching stack-segment.


Quote
Henning Petersen (henning.petersen.nospam.9...@hpc.dk) wrote:

: kefis...@iglou.com (Ken Fischer) wrote:
: >        Could you explain this better please?   Are you
: > going by segment base addresses in debug, or what?
:
: ???? I'm not queit sure I understand you but I'll try to rephrase ;-)
: The compiler (BPW7) creates an exe with 927k code, 46k data (global
: data + VMT-tables), 18k stack and 1k local heap.

       927k?????    Is this a team project? :-)   It's way
over my head.    With that much source code there must be
some duplication that could be placed in a shared procedure?    

: My problem is that
: the compiler puts the data, stack and local heap into the same
: segment, though seting a limit of 64k for the sum of these three
: data-blocks.
: What my idea was/is, is to minimize the stack size, by taking a 64k
: chunk of memory, and move the active stack into that segment, thereby
: freeing data-segment-space for future expansions of the program, and
: getting a full segment (64k) space in my stack.
: -HTH

       Apparently code space is not a problem, I can't
begin to suggect anything better than the others here,
       The only thing I can think of that might help
is maybe a dummy constant array, and change the initialization
when needed.    But I suspect you will end up with what
I hate most, a bunch of support files. :-)
       I haven't kept up with TP overlay support, and
I can't even guess if that would help.    Surely there
is something in 32 bit capability to help.

: >        Could you make the program smaller? :-)
:
: I wish I could, but it's likly to grow even more. But to do that I
: deseratly need more space in DSeg / SSeg ;-)

      I don't see how you get by with that size stack
as it is.    I think one of the biggest problems in
programming is finding the technical information about
the system and hardware.   I have trouble just trying
to stay ahead of problems keeping free disk space with
Win95, and I have the Sam's "Windows 95 Unleashed", the
hidden directories do not seem to be covered in the book,
and I just had to sort through 3200 image files before I
erased them.
     If and when your program is released, please let me
know.

Ken Fischer

---

Go to page: [1] [2]

Other Threads