Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51568 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2016-10-03 08:22 -0400 |
| Last post | 2016-10-17 22:05 +0000 |
| Articles | 20 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 08:22 -0400
Re: Stack Sizes foxaudioresearch@gmail.com - 2016-10-03 07:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:14 -0400
Re: Stack Sizes Bernd Linsel <bl1@gmx.com> - 2016-10-03 18:20 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 11:30 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:27 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:12 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 17:52 -0500
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:06 -0700
Re: Stack Sizes Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-10-04 08:31 +0100
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-04 08:46 +0000
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:38 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:59 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-05 09:59 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 10:16 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-06 08:21 +0000
Re: Stack Sizes minforth@arcor.de - 2016-10-04 05:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 08:49 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:28 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:36 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes Brad Eckert <hwfwguy@gmail.com> - 2016-11-09 09:56 -0800
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-11-12 09:15 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 10:35 -0500
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-11 01:01 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 10:21 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:06 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:22 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:04 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-04 20:46 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:40 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 12:26 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:44 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 16:32 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 20:01 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:39 +0000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:36 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 21:28 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-05 22:07 +0100
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-06 00:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-06 02:17 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-04 19:27 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-05 18:58 +0200
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 13:17 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-22 12:35 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 12:18 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 16:07 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:50 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 17:36 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 17:14 -0500
Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-05 14:48 -1000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:49 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-03 16:32 +0000
Re: Stack Sizes Chris Curl <ccurl609@gmail.com> - 2016-10-03 13:53 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 17:54 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-03 23:40 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:30 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-03 21:47 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:22 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:44 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:53 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 14:31 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 08:48 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 13:08 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:11 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 12:08 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-06 21:47 +0100
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:05 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-06 21:57 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 19:21 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 00:10 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:14 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 02:26 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:57 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-07 08:18 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-07 10:52 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-09 16:22 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 01:49 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:21 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 22:39 -0400
Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-10 12:36 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-13 13:45 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-14 01:16 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-15 20:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 02:00 -0400
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 18:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 22:27 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 21:14 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 00:35 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 23:31 -0700
Re: Straight Forth Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-16 20:36 -1000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:11 -0700
Re: Straight Forth Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-17 19:14 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 21:53 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-17 16:54 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-21 22:13 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-21 17:46 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-23 22:26 +0000
Re: Straight Forth Re: Stack Sizes JUERGEN <epldfpga@aol.com> - 2016-10-24 09:13 -0700
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-24 16:28 -0700
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-24 17:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-24 22:23 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-11-04 20:39 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 22:42 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-17 11:12 +0200
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 09:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 19:11 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 16:40 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:19 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 17:25 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:50 -0400
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:04 +0200
Re: Straight Forth Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-18 06:13 +0000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-16 15:21 -0700
Re: Straight Forth Re: Stack Sizes Doug Hoffman <glidedog@gmail.com> - 2016-10-17 04:09 -0400
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:48 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:12 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 00:35 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 12:53 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 12:12 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 16:53 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-09 08:34 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-09 16:03 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-10 03:25 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:29 -0500
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:19 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-10 14:41 +0000
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-10 20:23 +0200
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:16 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 12:54 +0000
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-12 18:27 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 17:06 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-12 13:01 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-12 17:07 -0400
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-13 03:18 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:26 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-12 20:30 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-13 15:52 +0000
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-13 15:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-14 03:08 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:41 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 12:33 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-08 01:12 -0400
Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 21:56 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-08 07:23 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-11 22:39 -0700
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 08:21 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 09:22 +0200
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 09:35 +0200
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 10:51 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 13:21 -0500
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 20:40 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 20:53 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:35 +0000
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-07 01:09 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 15:59 +0000
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 22:05 +0000
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-24 16:28 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <1e7f4d33-4448-48a4-8035-3e66a3d88ccd@googlegroups.com> |
| In reply to | #52152 |
On Tuesday, October 25, 2016 at 5:13:32 AM UTC+13, JUERGEN wrote:
>
> On Saturday, October 22, 2016 at 1:46:13 AM UTC+1, Lawrence D’Oliveiro wrote:
>>
>> On Saturday, October 22, 2016 at 11:13:48 AM UTC+13, Bernd Paysan wrote:
>>>
>>> Am Mon, 17 Oct 2016 16:54:31 -0700 schrieb lawrencedo99:
>>>
>>>> On Tuesday, October 18, 2016 at 10:53:27 AM UTC+13, Bernd Paysan wrote:
>>>>>
>>>>> So 30 years after the great Forth83 "mistake", I can claim that this
>>>>> idea had arrived as general consensus among ISA designers, at least for
>>>>> vector operations where they have the freedom to use them...
>>>>>
>>>>> ...
>>>>>
>>>>> Apparently, these sorts of flags make more sense in general ...
>>>>
>>>> “For vector operations” ≠ “in general”.
>>>
>>> You can't read, as I described at length ...
>>
>> ... all the parts where you were trying to argue that, just because
>> special-purpose vector instructions have become commonplace, that makes
>> them general-purpose?
>>
>> I read all right. And understood, possibly better than you.
>
> Could you please do me a favour and explain where you understand it better
> than Bernd for my understanding and the rest of the people reading this
> thread.
> Very much appreciated.
See Bernd’s own words above, where he says “at least for vector” at one point, then jumps to “in general” at another point, with no connection in-between. To spell it out:
“general-purpose” ⊆ “commonplace”
“vector” ⊆ “special-purpose”
However, nowadays
“vector” ⊆ “commonplace”
Nevertheless,
“vector” ⊈ “general-purpose”
Or, to put it another way,
“vector” ∩ “general-purpose” = ∅
Is that clearer now?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-24 17:20 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <87pompmg8c.fsf@nightsong.com> |
| In reply to | #52171 |
lawrencedo99@gmail.com writes: > Is that clearer now? Nobody cares.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-24 22:23 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <numfm8$7gb$1@dont-email.me> |
| In reply to | #52171 |
On 10/24/2016 7:28 PM, lawrencedo99@gmail.com wrote: > On Tuesday, October 25, 2016 at 5:13:32 AM UTC+13, JUERGEN wrote: >> >> On Saturday, October 22, 2016 at 1:46:13 AM UTC+1, Lawrence D’Oliveiro wrote: >>> >>> On Saturday, October 22, 2016 at 11:13:48 AM UTC+13, Bernd Paysan wrote: >>>> >>>> Am Mon, 17 Oct 2016 16:54:31 -0700 schrieb lawrencedo99: >>>> >>>>> On Tuesday, October 18, 2016 at 10:53:27 AM UTC+13, Bernd Paysan wrote: >>>>>> >>>>>> So 30 years after the great Forth83 "mistake", I can claim that this >>>>>> idea had arrived as general consensus among ISA designers, at least for >>>>>> vector operations where they have the freedom to use them... >>>>>> >>>>>> ... >>>>>> >>>>>> Apparently, these sorts of flags make more sense in general ... >>>>> >>>>> “For vector operations” ≠ “in general”. >>>> >>>> You can't read, as I described at length ... >>> >>> ... all the parts where you were trying to argue that, just because >>> special-purpose vector instructions have become commonplace, that makes >>> them general-purpose? >>> >>> I read all right. And understood, possibly better than you. >> >> Could you please do me a favour and explain where you understand it better >> than Bernd for my understanding and the rest of the people reading this >> thread. >> Very much appreciated. > > See Bernd’s own words above, where he says “at least for vector” at one point, then jumps to “in general” at another point, with no connection in-between. To spell it out: > > “general-purpose” ⊆ “commonplace” > “vector” ⊆ “special-purpose” > > However, nowadays > > “vector” ⊆ “commonplace” > > Nevertheless, > > “vector” ⊈ “general-purpose” > > Or, to put it another way, > > “vector” ∩ “general-purpose” = ∅ > > Is that clearer now? I think this is where Bernd gets to "commonplace"... > ARMv8 also provides a csinv instruction which has all bits > set as true value for the normal integer operations (that's what didn't > happen in the Intel world), so even for the normal integer operation, > having -1 as true flag seems to be widespread enough for CPU designers to > add those instructions (C flags are generated with csinc). I looked at this instruction and it seems to be a way to change a register from zero to -1 conditionally which would be used for setting a Forth type flag. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-11-04 20:39 +0000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nvirm7$raf$4@dont-email.me> |
| In reply to | #52171 |
Am Mon, 24 Oct 2016 16:28:08 -0700 schrieb lawrencedo99: > See Bernd’s own words above, where he says “at least for vector” at one > point, Yes, that point was 20 years ago. > then jumps to “in general” at another point, with no connection > in-between. And that was showing a recently developed ISA, which has a Forth-flag setter for the regular integer instructions, pointing out that the original ARM had that feature by accident, and the ARMv8 had the feature by intention. This part is that you were unable to read. > To spell it out: > > “general-purpose” ⊆ “commonplace” “vector” ⊆ “special-purpose” > > However, nowadays > > “vector” ⊆ “commonplace” > > Nevertheless, > > “vector” ⊈ “general-purpose” > > Or, to put it another way, > > “vector” ∩ “general-purpose” = ∅ > > Is that clearer now? And what you couldn't read is that this extremely important, recently developed ISA has a Forth-flag setter for the general-purpose register file. ARMv8 is one of the most common-place ISAs today. What you can do is logic, what you can't do is simple text understanding. When I give a history lesson, I'm going to show you how things developed: Forth was first with 0/-1 flags. Vector instructions were second, and as I pointed out, 20 years ago, ISA designers like Andy Glew, who wanted Forth flags for integers, didn't get through. But nowadays, ISA designers build Forth-like flags into their general purpose register file instructions. Can you follow me? Can you read as far as more than one paragraph? It is not only vectors anymore. It is now also ordinary scalar registers. And it's no longer "by accident" as with the 32 bit ARM, where all those conditional instructions could do it, it is on purpose. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-16 22:42 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <2ca0b59b-31c1-4e3b-ac37-77bd83d4b75f@googlegroups.com> |
| In reply to | #51933 |
On Monday, October 17, 2016 at 5:14:48 PM UTC+13, Raimond Dragomir wrote:
> Otherwise it's not wise to do arithmetics with logic flags, be they 0/1
> or 0/-1 or whatever.
0/1 has the advantage that you can indeed do arithmetic with it. From old Modula-2 (1980s), the classic double-buffered I/O example:
VAR
DoubleBuf : ARRAY BOOLEAN OF BufType;
CurBuf : BOOLEAN;
... initialization ...
LOOP
... start input into DoubleBuf[CurBuf] ...
... start output from DoubleBuf[NOT CurBuf] ...
.... wait for both to finish ...
CurBuf := NOT CurBuf
END (*LOOP*)
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-17 11:12 +0200 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu24l0$urv$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51933 |
In article <954f22a9-6163-4201-8932-7154c373ce8d@googlegroups.com>, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >luni, 17 octombrie 2016, 05:27:21 UTC+3, rickman a scris: >> On 10/16/2016 9:38 PM, lawrencedo99@gmail.com wrote: >> > On Sunday, October 16, 2016 at 7:00:02 PM UTC+13, rickman wrote: >> >> >> >> On 10/15/2016 11:38 PM, Hugh Aguilar wrote: >> >>> >> >>> Note that in Straight Forth a flag is 1 or 0, so it can be used for >> >>> counting... >> >> >> >> Why can't a true flag of all 1s be used for counting? >> > >> > Because values of 0 and +1 can also be used for indexing, 0 and -1 make it a little trickier. >> >> You mean by using 0= before the add or index? Yes, very tricky. >> >> -- >> >> Rick C > >You can C! a flag in memory and later C@ it without loosing "precision". >Or having to do 0= . >Probably this is the best advantage you can get from a 0/1 flag. >Otherwise it's not wise to do arithmetics with logic flags, be they 0/1 >or 0/-1 or whatever. 0/1 is a good word to insert : 0/1 0= 0= NEGATE ; It works even on "dirty" flags As in lispword >FFA @ symbol-or-number-mask AND 0/1 Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-17 09:20 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <87y41nosky.fsf@nightsong.com> |
| In reply to | #51942 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > : 0/1 0= 0= NEGATE ; : 0/1 0<> NEGATE ;
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-17 19:11 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3lq6$8fm$1@dont-email.me> |
| In reply to | #51944 |
On 10/17/2016 12:20 PM, Paul Rubin wrote: > albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >> : 0/1 0= 0= NEGATE ; > > : 0/1 0<> NEGATE ; Maybe I'm not getting what 0/1 is supposed to do. If you are just trying to clean up the flag, wouldn't juse 0<> do the job? It returns a valid flag no matter what the input. The two examples above perform a logical negation... or something. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-17 16:40 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <87twcapmrs.fsf@nightsong.com> |
| In reply to | #51950 |
rickman <gnuarm@gmail.com> writes: >> : 0/1 0<> NEGATE ; > Maybe I'm not getting what 0/1 is supposed to do. If you are just > trying to clean up the flag, wouldn't juse 0<> do the job? It's turning the flag into 0 or 1 as the name indicates. 0<> would turn it into 0 or -1.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-17 20:19 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3pp3$i7h$1@dont-email.me> |
| In reply to | #51954 |
On 10/17/2016 7:40 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>>> 0/1 is a good word to insert >>>> >>>> : 0/1 0= 0= NEGATE ; >>>> >>>> It works even on "dirty" flags >>>> As in >>>> >>>> lispword >FFA @ symbol-or-number-mask AND 0/1 >>>> >>>> Groetjes Albert >>> >>> : 0/1 0<> NEGATE ; >> >> Maybe I'm not getting what 0/1 is supposed to do. If you are just >> trying to clean up the flag, wouldn't juse 0<> do the job? > > It's turning the flag into 0 or 1 as the name indicates. 0<> > would turn it into 0 or -1. Ok, I lost context. So this would be used to turn the flag into a number? What's wrong with just NEGATE? I guess the idea is to not assume the input is a well formed flag? You trim your posts a little too much. Here it would have been good to retain some of the context. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-17 17:25 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <87lgxmpkoj.fsf@nightsong.com> |
| In reply to | #51960 |
rickman <gnuarm@gmail.com> writes:
> What's wrong with just NEGATE? I guess the idea is to not assume the
> input is a well formed flag?
Correct. It's straightforward to run examples:
: 0/1 0<> NEGATE ;
0 0/1 . 0 ok
47 0/1 . 1 ok
-1 0/1 . 1 ok
-82 0/1 . 1 ok
> You trim your posts a little too much.
Most newsreaders will let you easily view the parent post of the post
you're currently looking at. And plenty of other posters here don't
trim anywhere near enough.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-17 20:50 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3rk5$m8i$2@dont-email.me> |
| In reply to | #51962 |
On 10/17/2016 8:25 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> What's wrong with just NEGATE? I guess the idea is to not assume the >> input is a well formed flag? > > Correct. It's straightforward to run examples: > > : 0/1 0<> NEGATE ; > 0 0/1 . 0 ok > 47 0/1 . 1 ok > -1 0/1 . 1 ok > -82 0/1 . 1 ok > >> You trim your posts a little too much. > > Most newsreaders will let you easily view the parent post of the post > you're currently looking at. And plenty of other posters here don't > trim anywhere near enough. I had to go back four messages. It gets tiresome. Not trying to criticize, just pointing it out. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-18 02:04 +0200 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3ov9$5b0$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51950 |
In article <nu3lq6$8fm$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 10/17/2016 12:20 PM, Paul Rubin wrote: >> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>> : 0/1 0= 0= NEGATE ; >> >> : 0/1 0<> NEGATE ; > >Maybe I'm not getting what 0/1 is supposed to do. If you are just >trying to clean up the flag, wouldn't juse 0<> do the job? It returns a >valid flag no matter what the input. The two examples above perform a >logical negation... or something. It turns a dirty flag into a Hugh flag. I thought the context made that clear. To Paul: if a new word can be defined with only CORE words, I tend to do that. 0<> is in CORE extensions, (In fact 0<>is not in the kernel of ciforths) > >Rick C Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-18 06:13 +0000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <2016Oct18.081316@mips.complang.tuwien.ac.at> |
| In reply to | #51956 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <nu3lq6$8fm$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
>>On 10/17/2016 12:20 PM, Paul Rubin wrote:
>>> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>> : 0/1 0= 0= NEGATE ;
>>>
>>> : 0/1 0<> NEGATE ;
...
>To Paul: if a new word can be defined with only CORE words, I
>tend to do that.
>0<> is in CORE extensions
: 0/1 0= 1+ ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-16 15:21 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <e0b2e526-f514-4786-90a2-3084681344eb@googlegroups.com> |
| In reply to | #51885 |
On Saturday, October 15, 2016 at 8:38:30 PM UTC-7, hughag...@gmail.com wrote:
> A while ago, this subject was discussed. The following code was presented as being idiomatic ANS-Forth:
>
> : >CHAR ( [0,15] -- char )
> DUP 9 > 7 AND + [CHAR] 0 + ;
> ...
> Above, Elizabeth Rather said: "Neither of the previous versions is acceptable." She is referring to my ANS-Forth code:
>
> : indexed-char \ index adr cnt -- char \ the string will be used as an array of chars
> rover 0< abort" *** INDEXED-CHAR given a negative index ***"
> rover <= abort" *** INDEXED-CHAR given an index too large ***"
> + c@ ;
>
> : hexit>char \ [0,15] -- char
> s" 0123456789ABCDEF" indexed-char ;
I think that my ANS-Forth code is better than the idiomatic ANS-Forth code promoted by Elizabeth Rather and Bernd Paysan. In Straight Forth however, this would be very different. We have a string-stack that strings are normally held on. A string is a single word, so it can be hold on the single-precision stack, but this is only done temporarily when storing the string in a data-structure. Strings are normally held on the string-stack. Also, the programmer never deals with chars, so the above function that returns a char doesn't really make sense in Straight Forth. You would not have a char by itself, but you would have a string that was only 1 char in length and is held on the string-stack like any string. This allows useful things to be done with it, such as concatenating it to other strings.
So here is a Straight Forth version:
: hexit>$ ( index -- ) \string: -- str \ the index is [0,15]
s" 0123456789ABCDEF" 1 mid$ ;
Note that we don't need any error-checking for the index being out or range, because MID$ does that automatically. Note also that I didn't bother to factor the 1 MID$ out of HEXIT>$ because this code is so simple and obvious that it doesn't really need to be factored out.
This is very similar to how it would be done in ANS-Forth using the string-stack. The only difference is that S" doesn't automatically put the string on the string-stack and would need a >$ to do this explicitely.
ANS-Forth just lacks support for data. There are no supported data types. In the ANS-Forth version, you end up with a char, but what are you going to do with it? Nothing! There is no way to prepend or append it onto a string --- you would have to write this code out explicitly --- in ANS-Forth you have to write everything explicitly, and then write it all again but slightly differently in the next program.
The reason why nobody wants to program in ANS-Forth is because it is a toy language that doesn't provide any support for programming. There is almost no support for strings, although pretty much every program will involve strings. The programmer gets bogged down in laborously writing code to manipulate strings as arrays, and he doesn't get any productive work done. In Straight Forth, strings have support, so the programmer write code that works with strings easily and focus his mind on more important issues. I provided string-stack.4th for ANS-Forth, but everybody hated it --- support for strings is not idiomatic in ANS-Forth --- nobody will ever use string-stack.4th because they know that Elizabeth Rather would be offended.
In Straight Forth it is possible to hold a string in PTR and CNT in order to manipulate it at the char level, with PTR@ @ providing a char. Most programmers will never do this however. This is only done internally in low-level code such as MID$ --- programmers are encouraged to use the string functions such as MID$ etc. for working with strings, but to not write work with strings as arrays at all and not extract chars from strings.
As I said before, there is novice-level and intermediate-level Straight Forth programming. The novice-level programming involves using the built-in data support, and the intermediate-level programming involves writing low-level code. 99% of all Straight Forth programs can be done using novice-level programming. Everybody is encouraged to write their programs using novice-level techniques even if they are knowledgeable enough to use intermediate-level techniques --- low-level code should not be written gratuitously, but should be avoided as much as possible --- it is entirely acceptable for a programmer to stay at the novice-level indefinitely and never bother to learn how to write low-level code.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-10-17 04:09 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <58048738$0$342$14726298@news.sunsite.dk> |
| In reply to | #51885 |
On 10/15/16 11:38 PM, hughaguilar96@gmail.com wrote: > : indexed-char \ index adr cnt -- char \ the string will be used as an array of chars > rover 0< abort" *** INDEXED-CHAR given a negative index ***" > rover <= abort" *** INDEXED-CHAR given an index too large ***" I have found the use of a negative index to be useful. It refers to the element starting from the end of the array (including strings which I also treat as arrays). So an index of -1 would mean the last char of the string, -2 the second-to-last char, and so on. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-17 13:48 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <184f9aa5-b001-4cf9-acbf-b64ce4938b66@googlegroups.com> |
| In reply to | #51941 |
On Monday, October 17, 2016 at 1:11:01 AM UTC-7, Doug Hoffman wrote:
> On 10/15/16 11:38 PM, hughaguilar96@gmail.com wrote:
>
> > : indexed-char \ index adr cnt -- char \ the string will be used as an array of chars
> > rover 0< abort" *** INDEXED-CHAR given a negative index ***"
> > rover <= abort" *** INDEXED-CHAR given an index too large ***"
>
> I have found the use of a negative index to be useful. It refers to the
> element starting from the end of the array (including strings which I
> also treat as arrays). So an index of -1 would mean the last char of the
> string, -2 the second-to-last char, and so on.
That may be true, but it has nothing to do with my example. In my example the index is supposed to be inside of the string. Here is my code that you snipped:
: indexed-char \ index adr cnt -- char \ the string will be used as an array of chars
rover 0< abort" *** INDEXED-CHAR given a negative index ***"
rover <= abort" *** INDEXED-CHAR given an index too large ***"
+ c@ ;
: hexit>char \ [0,15] -- char
s" 0123456789ABCDEF" indexed-char ;
Anyway, I wrote that code before I had my string-stack.4th package available. Nowadays, I would write this:
: hexit>$ ( index -- ) \ string: -- str \ the index is [0,15]
s" 0123456789ABCDEF" >$ 1 mid$ ; ok
0 hexit>$ .$ 0 ok
9 hexit>$ .$ 9 ok
10 hexit>$ .$ A ok
15 hexit>$ .$ F ok
16 hexit>$ .$ *** MID$ over-reached the end of the string ***
-> 16 hexit>$ .$
^
I wrote string-stack.4th in ANS-Forth, however I'm not an ANS-Forth programmer. Elizabeth Rather says this:
---------------------------------------------------------------------------
Virtually every Forth application needs some kind of array structures. The
reason that some general-purpose one might be "little used" is because it's
so easy to make a version that does *exactly* what the application needs
rather than some generic definition. ...
The objective is to master the toolset and be able to think clearly about
exactly what kind of arrays will be useful in your application
and then build exactly that kind.
---------------------------------------------------------------------------
She is clearly banning the use of string-stack.4th because it is general-purpose and doesn't do *exactly* what the application needs. It provides a generic definition of a string! The horror! The horror!
My string-stack.4th hasn't just been "little used," but it has been shunned completely by the ANS-Forth cult. No ANS-Forth programmer will ever use it because doing so would offend Elizabeth Rather. She demands that every ANS-Forth programmer write every ANS-Forth program from scratch (actually, this mostly involves cut-and-paste-and-modify of old ANS-Forth programs) --- this way you get code "that does *exactly* what the application needs rather than some generic definition."
She describes this as being "so easy" which implies that it gets done often, but the truth is that it never gets done --- none of the ANS-Forth cult are actually writing programs --- what the ANS-Forth cult do with their time is hang out on c.l.f. braying about how they are big Forth experts and/or hanging out on the Forth-200x mailing-list where they make design decisions that will be imposed on the entire Forth community (people such as myself who actually write Forth programs).
In Straight Forth, string-stack.4th will be part of the standard and idiomatic --- you have to abandon ANS-Forth in order to be allowed to use a package like this --- even though string-stack.4th is currently written in ANS-Forth, the ANS-Forth programmers are not allowed to use it.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-18 02:12 +0200 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3pcn$5du$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51946 |
In article <184f9aa5-b001-4cf9-acbf-b64ce4938b66@googlegroups.com>, <hughaguilar96@gmail.com> wrote: <SNIP> >My string-stack.4th hasn't just been "little used," but it has been shunned= > completely by the ANS-Forth cult. No ANS-Forth programmer will ever use it= > because doing so would offend Elizabeth Rather. She demands that every ANS= >-Forth programmer write every ANS-Forth program from scratch (actually, thi= >s mostly involves cut-and-paste-and-modify of old ANS-Forth programs) --- t= >his way you get code "that does *exactly* what the application needs rather= > than some generic definition." > I hate string stacks. They are a too heavy tool for every day use, but when the heat is on ... For the Pascal compiler I'm working on they just don't cut it, and I'll be using strings that are ALLOCATE d (and have a SIZE). String stack fall between the wall and the ship as the Dutch saying goes. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-18 00:35 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <e5f2267c-b298-4555-9f71-68a69ff68cfd@googlegroups.com> |
| In reply to | #51958 |
On Monday, October 17, 2016 at 5:03:21 PM UTC-7, Albert van der Horst wrote: > In article <184f9aa5-b001-4cf9-acbf-b64ce4938b66@googlegroups.com>, > <hughaguilar96@gmail.com> wrote: > <SNIP> > >My string-stack.4th hasn't just been "little used," but it has been shunned= > > completely by the ANS-Forth cult. No ANS-Forth programmer will ever use it= > > because doing so would offend Elizabeth Rather. She demands that every ANS= > >-Forth programmer write every ANS-Forth program from scratch (actually, thi= > >s mostly involves cut-and-paste-and-modify of old ANS-Forth programs) --- t= > >his way you get code "that does *exactly* what the application needs rather= > > than some generic definition." > > > I hate string stacks. They are a too heavy tool for every day use, > but when the heat is on ... > For the Pascal compiler I'm working on they just don't cut it, and > I'll be using strings that are ALLOCATE d (and have a SIZE). > String stack fall between the wall and the ship as the Dutch saying goes. The clever part of my string-stack.4th is that I don't ALLOCATE every time that I make a duplicate on the string-stack (with DUP$ or OVER$ etc.). I have "unique" and "derivative" strings. For example, DUP$ index length MID$ doesn't ALLOCATE to make a new string --- it just makes a derivative, meaning a reference to an existing string. I've already described this elsewhere so I won't go into the details here. The point though, is that ALLOCATE and FREE are typically the big time sinks --- my string-stack.4th was designed to minimize how often these are called --- the actual work being done on the strings is not very time consuming usually. It is meaningless to say, "I hate string stacks." You don't really know what you are talking about. Nobody else has ever written a string-stack like mine, with unique and derivative strings --- I invented this. If I wasn't going to have the unique and derivative strings, and I was just going to ALLOCATE every time that a copy of a string was needed, then I wouldn't bother with the string-stack. In Straight Forth, a string takes up only one cell (cells are 64-bit, and pointers are 32-bit, so there is room for both the pointer and the count packed together in one cell as a struct). This is much more convenient than in ANS-Forth were the address and count take up two cells. So, the string-stack is not primarily provided for convenience --- the string-stack is provided for efficiency (minimizing calls to ALLOCATE and FREE) --- the string-stack is somewhat convenient though, because it gets strings off the data-stack and out of the way of other data that may be on the data-stack. Note that I also have a double-stack for data that takes up two cells --- specifically, for double-precision numbers and ratios. One of the problems with ANS-Forth (actually with all Forths) is that having one-cell and two-cell data intermixed on the same stack makes complicated hard-to-read stack-juggling. In Straight Forth I have the data-stack, the string-stack and the double-stack and all data goes on the appropriate stack --- you can have a lot of data being worked on in a function, and it is easy to access because it is not all on the same stack getting in each other's way.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-18 12:53 +0200 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu4uuu$d2c$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51993 |
In article <e5f2267c-b298-4555-9f71-68a69ff68cfd@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Monday, October 17, 2016 at 5:03:21 PM UTC-7, Albert van der Horst wrote= <SNIP> >> > >> I hate string stacks. They are a too heavy tool for every day use, >> but when the heat is on ... >> For the Pascal compiler I'm working on they just don't cut it, and >> I'll be using strings that are ALLOCATE d (and have a SIZE). >> String stack fall between the wall and the ship as the Dutch saying goes. > >The clever part of my string-stack.4th is that I don't ALLOCATE every time = >that I make a duplicate on the string-stack (with DUP$ or OVER$ etc.). I ha= >ve "unique" and "derivative" strings. For example,=20 >DUP$ index length MID$=20 >doesn't ALLOCATE to make a new string --- it just makes a derivative, meani= >ng a reference to an existing string. I've already described this elsewhere= > so I won't go into the details here. The point though, is that ALLOCATE an= >d FREE are typically the big time sinks --- my string-stack.4th was designe= >d to minimize how often these are called --- the actual work being done on = >the strings is not very time consuming usually. <SNIP> Using ALLOCATE this is a sophisticated stringhandling mechanism. Your strings are not on a stack, they can be randomly deleted and allocated. You shouldn't call it a string stack, which associates it with restricted tools that have been published. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web