Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!canterbury!fore057
Newsgroups: comp.lang.prolog
Subject: RE: Environments
Message-ID: <1991Mar26.223220.323@csc.canterbury.ac.nz>
From: fore057@csc.canterbury.ac.nz
Date: 26 Mar 91 22:32:20 +1200
Organization: University of Canterbury, Christchurch, New Zealand
Lines: 33

Reply from Per Bilse, one of the authors of PDC Prolog:

From:	IN%"pdev@pdc.dk" 26-MAR-1991 21:42:14.83
Subj:	Re: Environments

I'm out here, but not in a posting capacity.  Recommendations depend on
what areas A and B refer to.  If it's stack space, there's little to do.
Some (all?) Prolog interpreters run on a virtual stack, allowing more than
64K stack, while we (having fully compiled target code) use the CPU
stack; the difference in speed is between 100:1 and 1000:1 :-).  And you
can multiply that with anything between 2 and 5 if running in '286 protected
mode ... the things we sacrifice for a puny performance gain ... :-) ...
If the problem is in the trail, the restriction has been lifted: newer
versions of PDC have a dynamic auto-expanding trail.

Irrespective of all this, I agree with OK that os-related restrictions
of this kind shouldn't be passed on to the programmer.  On the other
hand, we all know that many things are a tight squeeze in DOS and I
suspect situations like the one he describes will only apply in rare
instances: stack + trail will occupy at most 2*64K so if that's causing
memory shortage, he'd be close to the limit anyway.  Nevertheless, the
performance ratio of a running program over a non-running one remains
at approximately 1:0 ...

While we're at it, I know of no modern-day operating system having memory
limitations worth worrying about, or 16-bit near pointers.  Hence, the
UNIX version of PDC Prolog can have stack, trail, gstack, whatever, in
the Gigabyte range.  Nice.

Feel free to post, if you wish.

	Best Wishes
	per (aka pdev, root, mmdf, etc)