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


Groups > comp.lang.forth > #41448

Re: Numeric limits in 8th

Date 2015-08-21 22:59 +0100
From Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>>
Newsgroups comp.lang.forth
Subject Re: Numeric limits in 8th
Message-ID <20150821225935.12db1a92@HP-6550b> (permalink)
References <mqp3s5$t4r$1@dont-email.me> <20150817075421.487fab8e@HP-6550b> <mqs34e$dco$1@dont-email.me>

Show all headers | View raw


On Mon, 17 Aug 2015 10:41:26 +0300
Ron Aaron <rambamist@gmail.com> wrote:

> On 08/17/2015 09:54, Jan Coombs <Jan-54 wrote:
> > As with Ilya's Forth this provides significant user benefit
> > in usage simplification.
>     [...]
> > For smaller systems it might be good to use a variable length
> > representation of stack items. This would reduce the stack
> > memory size, and required memory bandwidth, also remove the
> > upper limit on data item size.
> 
> I think using variable-sized items on the stack would greatly
> complicate matters, and make the code bigger ultimately.  As
> it stands, each stack location contains exactly one-item, and
> no item requires more than one stack location.
> 
> The backing representation of the item - that is, what is
> pointed to by the stack item - can be most anything.  Of
> course there are advantages to keeping that small as well,
> though that's not always possible.

When complexity appears somewhere, it may have disappeared
elsewhere: 

In python the immediate backing representation for a stack item
is a small object, containing just a reference count, and a
pointer to the remainder of the backing representation. 

When DUP or DROP create or destroy stack items, then the python
engine must adjust the reference count. 8th must have some
equivalent complexity for garbage collection?

If a variable size item is stored entirely in the stack then
this creates additional complexity in stack management, but
removes the complexity of garbage collection. 

> "Smaller systems" is a bit of an issue, as that's not within
> the design parameters of 8th.  We are venturing into the
> embedded arena, but only for larger systems (Raspberry Pi, for
> example, will be released very soon). 

Understood, I was stretching my mind, and did not intend to bend
your practicality.  I hope that your well-stocked toolbox gains
many deserving users.
 
> > The Python engine only needs access to the top two or three
> > stack items, how many does 8th require?
> 
> Generally not more than two.  The default stack is 2000 deep,
> but that can be controlled by an option on the command-line.

Thanks, that's interesting, and refreshingly different from the
many languages which need to index the stack for parameter
passing. 

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Numeric limits in 8th Ron Aaron <rambamist@gmail.com> - 2015-08-16 07:35 +0300
  Re: Numeric limits in 8th Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-17 07:54 +0100
    Re: Numeric limits in 8th Ron Aaron <rambamist@gmail.com> - 2015-08-17 10:41 +0300
      Re: Numeric limits in 8th Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-21 22:59 +0100

csiph-web