Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41448
| 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> |
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
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