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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-10 22:39 -0400 |
| Message-ID | <nthjd3$2jv$1@dont-email.me> |
| In reply to | #51739 |
On 10/10/2016 11:21 AM, Cecil Bayona wrote: > On 10/10/2016 12:49 AM, rickman wrote: >> On 10/9/2016 7:22 PM, hughaguilar96@gmail.com wrote: >>> On Friday, October 7, 2016 at 7:52:57 AM UTC-7, Walter Banks wrote: >>>> The idea has been around since at least the 70's with the TI9900. >>> >>> Mark Wills is our big TI9900 guy around here. >>> >>> Is the IT9900 still used at all? I have read that it was the best >>> processor of its era --- I have also read however that the TI99/4A >>> was the worst computer of its era --- somewhat like putting a >>> race-car engine in a go-kart. >> >> It's era included the PDP-11 computer line and LSI-11 computer chips. I >> think trying to claim some sort of superiority of one line of computer >> designs over another is a bit pointless. How do you measure "best"? The >> TI-990 was a reasonably popular mini-computer line, but never had >> overwhelming sales. The TMS9900 chip came in a humongous 64 pin package >> and required a 4 phase clock, not entirely different from many of the >> first CPUs like the 8080. But the 9900 had exactly one significant >> successor, the 9995 which had an 8 bit data bus. All in all this >> product line didn't get much traction other than in TI's own computers. >> >> I can't imagine you can buy any 9900 type chips other than HDL in an >> FPGA. I've got a 9900 computer board I modified to use 2716 EPROMs >> rather than the old 2708 EPROMs. I also built a 9995 board with some 8 >> kB of fast RAM and one EPROM. Both are still around somewhere, haven't >> touched them in years. >> > The device was slow by later standards but it never stood a change, > programming wise it was decent. > > TI used every trick to possibly cripple the CPU in the TI99/4, > unfortunately that is a horrible market ploy that most likely backfired > on them. Most likely designers that saw the performance of the TI99/4 > were turned off before they looked at the device. You can still find the > chips an the TI99/4 on eBay for all it's worth. > > Actually those EPROMs you mentioned are rather expensive, the much > larger sizes are way cheaper. The 1Mb 28c1000 parts are available > inexpensively and are prime parts from distributors. I recently bought > some 27C256 and 29C256 devices for a CDP 1802, and Z80 projects and they > cost more than the 28c1000 parts which are 4X bigger and way faster. As > soon as I can find some decent wire-wrap 32 pin sockets I will buy some > of those chips and save some money on future projects even if I only use > part of the devices. I think you don't realize I switched the board from 2708 to 2716 EPROMs because the 2716 was the biggest part you could get at the time! The 2716 was much easier to program than the 2708 as were all succeeding 27xx devices. The 1702A was a real bear! I have an old 8008 computer somewhere that uses 1702As (by that I mean it reads and programs them). Crazy stuff, switching high voltages on the address and/or data lines... wow! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-10 12:36 +0200 |
| Subject | Straight Forth Re: Stack Sizes |
| Message-ID | <ntfr0b$hol$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51733 |
In article <4f3794f4-58f2-47b7-8d27-b2b246e325f1@googlegroups.com>, <hughaguilar96@gmail.com> wrote: <SNIP Ti 9900> >---------------------------------------------------------------------------= >-- > >In Straight Forth we have four user registers: PTR CNT REG and ACC. Note th= >at PTR and CNT can only hold integers (the fractional part is zero'd) --- P= >TR and CNT are typically used together to describe an array and the term PC= > refers to this register pair. <SNIP implementation details> I can see that you've done a clever implementation, (or is it desing phase?) not so much the motivation behind it. > >A novice-level Straight Forth programmer should only use the built-in HOFs;= > he should not write his own HOFs and he should not use BEGIN WHILE REPEAT = >(iteration is a common source of bugs, which is why novices are discouraged= <SNIP explanation> If the motivation is to allow simplication in behalf of novices, you would do well to give some simple examples of original Forth versus Straight Forth. 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-13 13:45 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <c517cb14-c7a6-424a-8ca2-ae1237d39382@googlegroups.com> |
| In reply to | #51738 |
On Monday, October 10, 2016 at 3:28:09 AM UTC-7, Albert van der Horst wrote:
> In article <4f3794f4-58f2-47b7-8d27-b2b246e325f1@googlegroups.com>,
> <hughaguilar96@gmail.com> wrote:
> >In Straight Forth we have four user registers: PTR CNT REG and ACC. Note th=
> >at PTR and CNT can only hold integers (the fractional part is zero'd) --- P=
> >TR and CNT are typically used together to describe an array and the term PC=
> > refers to this register pair.
> <SNIP implementation details>
>
> I can see that you've done a clever implementation, (or is it desing phase?)
> not so much the motivation behind it.
It is pointless for me to program in ANS-Forth when I'm not an ANS-Forth programmer --- I have to either abandon Forth or write my own Forth.
I remember way back in 1984/1985 when I was learning Forth, that Forth-83 was well known to have serious problems, but all the Forth enthusiasts (there were a lot in those days) assured me that a new standard was coming soon that would save Forth --- I never imagined at the time that 30 years later it would be up to me to do this --- I assumed that the Forth community had leadership who would lead the way, but this never happened.
ANS-Forth is just a warmed-over version of Charles Moore's Forth written in the 1970s for the PDP-11. The design assumes an extreme register shortage such as the PDP-11 and 16-bit x86 had --- but this hasn't been the real-world for quite some time. By comparison, Straight Forth assumes a 64-bit processor with 16 registers --- this has been the standard since the turn of the century.
Modern computers have a lot of registers, so in Straight Forth I provide the REG ACC PTR CNT "user registers" (this would not have been realistic in the 1970s) --- PTR and CNT (which can be accessed as the register-pair PC) are restricted to integers only (they can be used for passing data into HOFs and also back up to the calling function) --- REG and ACC are general-purpose and allow a fractional part (they can be used for passing data into sub-functions but not back up to the calling function).
I also have local variables which are more robust, but will be slower in most implementations. They are in the local-frame and hence have an address like any variable. They can hold single-precision, double-precision, ratio or float data. Quotations can access the parent function's local variables (obviously; that is the definition of what a quotation is). Quotations are generally not needed --- REG and ACC are almost always sufficient --- PTR and CNT too, although they are mostly for boosting the speed of HOFs (all iteration is done in HOFs, and iteration is the #1 drag on speed).
I have >R R@ RDROP etc.. I don't provide R> because it makes for hard-to-read code; use R@ RDROP instead. Actually, RDROP is almost never needed because functions automatically discard all of the >R data that is still be on the return-stack when they exit. In Straight Forth it is idiomatic to never use RDROP at all, but to just leave >R data on the return-stack to be automatically discarded.
>R R@ etc. are almost never needed --- the user registers should be your first choice, local variables your second choice, and >R R@ etc. are mostly only for the super-rare cases in which you have a variable number of parameters.
I actually have RBUF and RT that are defined like this:
RBUF ( size -- ) r( -- data... )
allocate a memory-block on the return-stack
SIZE must be a multiple of W (the cell size) --- if it is negative it discards the buffer
the memory-block is zero'd out
RT ( -- ptr ) r( data... -- data... )
provide a pointer to the latest RBUF (the return-stack top-value)
>R R@ etc. are defined in terms of these with macros.
> >A novice-level Straight Forth programmer should only use the built-in HOFs;=
> > he should not write his own HOFs and he should not use BEGIN WHILE REPEAT =
> >(iteration is a common source of bugs, which is why novices are discouraged=
> <SNIP explanation>
>
> If the motivation is to allow simplication in behalf of novices, you
> would do well to give some simple examples of original Forth
> versus Straight Forth.
The two built-in data-structures are the array and the chain. I discourage the use of arrays --- they are mostly only used for strings of chars (chars are 32-bit UTF) --- arrays are needed for some purposes, such as table lookup, so they are provided.
I recommend the use of the chain for almost all data. I just made up the term "chain" so I wouldn't specify a particular data-structure. As a practical matter, I'm using AVL trees with an UP pointer, and I expect that most implementations will be similar. The UP pointer is necessary so that it is possible to move left and right through the chain (the current node in the chain but is not necessarily the root node).
You want "simple examples" of Straight Forth versus ANS-Forth??? Well, this is what Elizabeth Rather (designer of ANS-Forth) says:
-----------------------------------------------------------------------------
...in Forth it's so easy to build data structures that are exactly right for
the particular application at hand that worrying about what pre-built
structures you have and how to use them is just not worth the bother.
-----------------------------------------------------------------------------
Nobody has time to implement chains in ANS-Forth --- not worth the bother! --- so it is impossible to directly compare ANS-Forth with Straight Forth.
For whatever it is worth though, here is ye olde hottie-counting program in Straight Forth:
class person chain
w field person.sex \ 'M' or 'F'
end-class
: init-person ( node -- node ) \ s( name -- )
init-chain ptr! \ s( -- )
[char] M ptr@ person.sex ! \ default is male
ptr@ ;
: new-person ( -- node ) \ s( name -- )
heap-new person
init-person ;
class chick person
w field chick.hotness \ scale of 1 to 10
end-class
: init-chick ( hotness node -- node ) \ s( name -- )
init-person ptr!
[char] F ptr@ person.sex ! \ override the default
ptr@ chick.hotness ! \ set her hotness
ptr@ ;
: new-chick ( hotness -- node ) \ s( name -- )
heap-new chick
init-chick ;
: hottie-count local{ personA | people chicks tens nines eights -- }
personA @ ptr! \ PTR@ is our PERSON chain
{
1 people +!
ptr@ is-a chick if 1 chicks +!
ptr@ chick.hotness @ reg! \ REG@ is our chick's hotness
reg@ 8 = eights +!
reg@ 9 = nines +!
reg@ 10 = tens +! \ Yay! We found a 10!
then
} |full-rite
cr ." total people: " people @ .
cr ." total chicks: " chicks @ .
cr ." level 10 chicks: " tens @ .
cr ." level 9 chicks: " nines @ .
cr ." level 8 chicks: " eights @ .
;
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-14 01:16 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <ca565952-72a4-4d8a-8a57-45d484fe89c7@googlegroups.com> |
| In reply to | #51840 |
On Thursday, October 13, 2016 at 1:46:01 PM UTC-7, hughag...@gmail.com wrote: > Quotations are generally not needed --- REG and ACC are almost always sufficient --- PTR and CNT too, although they are mostly for boosting the speed of HOFs (all iteration is done in HOFs, and iteration is the #1 drag on speed). That was a typo --- I meant: "Locals are generally not needed..." Quotations are obviously needed quite a lot --- as I said, all iteration is done in HOFs --- so, any use of iteration involves a quotation being executed repeatedly inside of HOF.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-15 20:38 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <6ea5be06-1671-4301-83e2-b073e5efa99f@googlegroups.com> |
| In reply to | #51840 |
On Thursday, October 13, 2016 at 1:46:01 PM UTC-7, hughag...@gmail.com wrote:
> : hottie-count local{ personA | people chicks tens nines eights -- }
> personA @ ptr! \ PTR@ is our PERSON chain
> {
> 1 people +!
> ptr@ is-a chick if 1 chicks +!
> ptr@ chick.hotness @ reg! \ REG@ is our chick's hotness
> reg@ 8 = eights +!
> reg@ 9 = nines +!
> reg@ 10 = tens +! \ Yay! We found a 10!
> then
> } |full-rite
> cr ." total people: " people @ .
> cr ." total chicks: " chicks @ .
> cr ." level 10 chicks: " tens @ .
> cr ." level 9 chicks: " nines @ .
> cr ." level 8 chicks: " eights @ .
> ;
Note that in Straight Forth a flag is 1 or 0, so it can be used for counting:
reg@ 10 = tens +!
I find this to be quite succinct and readable; control structures such as IF THEN are require the reader to consider two possibilities, which confuses the mind. Also, in most implementations, it will be quite efficient --- on the 64-bit x86, branches can be mispredicted, but the CMOV instruction (used inside of the = conditional) avoids this problem.
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 + ;
Then we had this exchange:
On Sunday, May 24, 2015 at 5:21:05 PM UTC-7, Bernd Paysan wrote:
> Hans Bezemer wrote:
> > ...True, it
> > is a clever piece of programming, but in our opinion it is bad
> > style. Why? Because you are using a flag as a bitmask, which is a
> > completely different datatype. Although there is no such thing as
> > “data typing” in Forth, this way of programming makes it
> > difficult to understand and maintain a program, which the
> > ANS-Forth standard acknowledges:
>
> Honestly, this is only a problem if you don't know that idiom. A lot of
> people don't know that you can use masks and logical operations, so they
> will find that operation strange.
> ...
> Therefore, I would reiterate what I told Hugh some times: If you don't know
> something, it's *not* the fault of the person who uses and knows that thing.
> It's entirely your fault, and if you want to be a wise person, you'd rather
> learn it than complain.
>
> IMHO the whole datatype based thinking about cells in Forth is ill-advised.
> First, and foremost, a cell is a bit pattern, and if you add and subtract
> it, it's a mod 2^n ring. You can use that to some degrees as integer, but
> it's not an integer. It's a cell.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
Elizabeth Rather responded:
> Thank, you, Bernd, well-said.
>
> Cheers,
> Elizabeth
Note that I was not involved in this thread. Bernd Paysan is just taking a gratuitous shot at me --- Elizabeth Rather responds positively to this.
A little later we had this:
On Tuesday, May 26, 2015 at 11:37:37 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/26/15 8:15 AM, rickman wrote:
> > On 5/26/2015 1:20 PM, WJ wrote:
> >> That code is unreadable and unmaintainable. It's very hard
> >> to figure out how it accomplishes its task. I would not
> >> pay a programmer to produce code like that.
> >>
> >> This is somewhat more understandable:
> >>
> >> : >char
> >> dup 9 > if [char] A 10 - else [char] 0 then
> >> + ;
> >
> > If you have any reason to look at the definition of >char then I can't
> > see how you would not understand how it works. Perhaps this would be a
> > better definition...
> >
> > \ Convert n to ASCII char
> > : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ;
> >
> > Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I
> > think that exact code has been read and understood as well as maintained
> > for many years now. I am pretty sure I have seen something similar to
> > it way back when I was learning assembly language. I think it took me
> > two minutes to see what it was doing.
>
> Indeed, proper documentation as in rickman's version above is essential
> to readable & maintainable code. Neither of the previous versions is
> acceptable, although I find the shorter code quite clear (and, as
> rickman notes, it's been around for many years). I would have preferred
> [CHAR] instead of ASCII, however, as it's Standard.
>
> Cheers,
> Elizabeth
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 ;
This is why I say that, although I write ANS-Forth programs, I'm not an ANS-Forth programmer. Elizabeth Rather and her Forth-200x committee appointee Bernd Paysan truly hate my ANS-Forth code. They don't consider me to be an ANS-Forth programmer; they told me I wasn't an ANS-Forth programmer in 2009; they will never allow me to be an ANS-Forth programmer, nor a Forth-200x programmer either. To be an ANS-Forth or Forth-200x programmer, it would be necessary for me to write code like this:
: >CHAR ( [0,15] -- char )
DUP 9 > 7 AND + [CHAR] 0 + ;
It is impossible for me to ever become an ANS-Forth programmer! To me, this looks like the tricky code that was common in the 1970s when saving memory was the #1 priority. In the 1970s, my code would have been unacceptable because the string s" 0123456789ABCDEF" uses too much memory. In the days of the Commodore Vic-20, it was necessary to count every byte!
Straight Forth is for everybody like me who is unable to become an ANS-Forth programmer. Bernd Paysan said: "It's entirely your fault." This is just another way of saying that I have to take responsibility for myself. I like Bernd Paysan's quote so much that I'm going to make it the motto of Straight Forth:
"It's entirely your fault!"
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-16 02:00 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <ntv50e$utv$1@dont-email.me> |
| In reply to | #51885 |
On 10/15/2016 11:38 PM, hughaguilar96@gmail.com wrote:
> On Thursday, October 13, 2016 at 1:46:01 PM UTC-7,
> hughag...@gmail.com wrote:
>> : hottie-count local{ personA | people chicks tens nines eights --
>> } personA @ ptr! \
>> PTR@ is our PERSON chain { 1 people +! ptr@ is-a chick if 1 chicks
>> +! ptr@ chick.hotness @ reg! \ REG@ is
>> our chick's hotness reg@ 8 = eights +! reg@ 9 = nines +! reg@
>> 10 = tens +! \ Yay! We found a
>> 10! then } |full-rite cr ." total people: " people @ . cr ."
>> total chicks: " chicks @ . cr ." level 10 chicks: " tens @ .
>> cr ." level 9 chicks: " nines @ . cr ." level 8 chicks: " eights
>> @ . ;
>
> Note that in Straight Forth a flag is 1 or 0, so it can be used for
> counting: reg@ 10 = tens +! I find this to be quite succinct and
> readable; control structures such as IF THEN are require the reader
> to consider two possibilities, which confuses the mind. Also, in most
> implementations, it will be quite efficient --- on the 64-bit x86,
> branches can be mispredicted, but the CMOV instruction (used inside
> of the = conditional) avoids this problem.
Why can't a true flag of all 1s be used for counting? That represents
-1, so subtracting the flag gives the result of counting the true flags.
If you are going to use an idiom, I don't see how adding is better
than subtracting, especially if you have to use a different value for
the true flag.
> 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 + ;
>
> Then we had this exchange:
>
> On Sunday, May 24, 2015 at 5:21:05 PM UTC-7, Bernd Paysan wrote:
>> Hans Bezemer wrote:
>>> ...True, it is a clever piece of programming, but in our opinion
>>> it is bad style. Why? Because you are using a flag as a bitmask,
>>> which is a completely different datatype. Although there is no
>>> such thing as “data typing” in Forth, this way of programming
>>> makes it difficult to understand and maintain a program, which
>>> the ANS-Forth standard acknowledges:
>>
>> Honestly, this is only a problem if you don't know that idiom. A
>> lot of people don't know that you can use masks and logical
>> operations, so they will find that operation strange. ...
>> Therefore, I would reiterate what I told Hugh some times: If you
>> don't know something, it's *not* the fault of the person who uses
>> and knows that thing. It's entirely your fault, and if you want to
>> be a wise person, you'd rather learn it than complain.
>>
>> IMHO the whole datatype based thinking about cells in Forth is
>> ill-advised. First, and foremost, a cell is a bit pattern, and if
>> you add and subtract it, it's a mod 2^n ring. You can use that to
>> some degrees as integer, but it's not an integer. It's a cell.
>>
>> -- Bernd Paysan "If you want it done right, you have to do it
>> yourself"
>
> Elizabeth Rather responded:
>> Thank, you, Bernd, well-said.
>>
>> Cheers, Elizabeth
>
> Note that I was not involved in this thread. Bernd Paysan is just
> taking a gratuitous shot at me --- Elizabeth Rather responds
> positively to this.
You weren't mentioned. How is it a shot at *you*???
> A little later we had this:
>
> On Tuesday, May 26, 2015 at 11:37:37 AM UTC-7, Elizabeth D. Rather
> wrote:
>> On 5/26/15 8:15 AM, rickman wrote:
>>> On 5/26/2015 1:20 PM, WJ wrote:
>>>> That code is unreadable and unmaintainable. It's very hard to
>>>> figure out how it accomplishes its task. I would not pay a
>>>> programmer to produce code like that.
>>>>
>>>> This is somewhat more understandable:
>>>>
>>>> : >char dup 9 > if [char] A 10 - else [char] 0 then + ;
>>>
>>> If you have any reason to look at the definition of >char then I
>>> can't see how you would not understand how it works. Perhaps
>>> this would be a better definition...
>>>
>>> \ Convert n to ASCII char : >CHAR ( n -- char ) DUP 9 > 7 AND +
>>> ASCII 0 + ;
>>>
>>> Lol, saying it is unreadable and unmaintainable is a bit of a
>>> stretch. I think that exact code has been read and understood as
>>> well as maintained for many years now. I am pretty sure I have
>>> seen something similar to it way back when I was learning
>>> assembly language. I think it took me two minutes to see what it
>>> was doing.
>>
>> Indeed, proper documentation as in rickman's version above is
>> essential to readable & maintainable code. Neither of the previous
>> versions is acceptable, although I find the shorter code quite
>> clear (and, as rickman notes, it's been around for many years). I
>> would have preferred [CHAR] instead of ASCII, however, as it's
>> Standard.
>>
>> Cheers, Elizabeth
>
> 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 anegative index ***"
> rover <= abort" *** INDEXED-CHAR given an index too large ***"
> + c@ ;
>
> : hexit>char \ [0,15] -- char s" 0123456789ABCDEF" indexed-char ;
>
> This is why I say that, although I write ANS-Forth programs, I'm not
> an ANS-Forth programmer. Elizabeth Rather and her Forth-200x
> committee appointee Bernd Paysan truly hate my ANS-Forth code. They
> don't consider me to be an ANS-Forth programmer; they told me I
> wasn't an ANS-Forth programmer in 2009; they will never allow me to
> be an ANS-Forth programmer, nor a Forth-200x programmer either. To be
> an ANS-Forth or Forth-200x programmer, it would be necessary for me
> to write code like this:
>
> : >CHAR ( [0,15] -- char ) DUP 9 > 7 AND + [CHAR] 0 + ;
>
> It is impossible for me to ever become an ANS-Forth programmer! To
> me, this looks like the tricky code that was common in the 1970s when
> saving memory was the #1 priority. In the 1970s, my code would have
> been unacceptable because the string s" 0123456789ABCDEF" uses too
> much memory. In the days of the Commodore Vic-20, it was necessary to
> count every byte!
>
> Straight Forth is for everybody like me who is unable to become an
> ANS-Forth programmer. Bernd Paysan said: "It's entirely your fault."
> This is just another way of saying that I have to take responsibility
> for myself. I like Bernd Paysan's quote so much that I'm going to
> make it the motto of Straight Forth: "It's entirely your fault!"
It is hard to imagine what goes on in the mind of a person like this. I
certainly have no idea.
--
Rick C
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-16 18:38 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <faa26675-e251-4b48-b528-23daf0e80d4e@googlegroups.com> |
| In reply to | #51886 |
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.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-16 22:27 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu1ctk$nrs$1@dont-email.me> |
| In reply to | #51920 |
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
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-10-16 21:14 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <954f22a9-6163-4201-8932-7154c373ce8d@googlegroups.com> |
| In reply to | #51926 |
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.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-17 00:35 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu1keh$8et$1@dont-email.me> |
| In reply to | #51933 |
On 10/17/2016 12:14 AM, Raimond Dragomir 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. You don't need to change the entire language to use bytes to store flags. c! will store a TRUE as all ones. c@ will retrieve a value of 255 on the stack. This will be treated as a TRUE as long as you don't use it for anything but logic before you use it as logic. If you want to store a value of 1 in the bytes so you can later count them, then store them this way. 1 AND c! By changing your entire Forth to use 1/0 as logic values you lose the ability to use an arbitrary value as a flag. In ANS Forth any value that is not zero is treated as a TRUE by any function that evaluates a logic flag. So a flag and a value ANDed together will give you a TRUE if the value is not zero and the flag is TRUE or FALSE if either the value is zero or the flag is FALSE. Just as you can use a flag as a mask to perform logic on a value leaving at its present value or setting it to zero which is what is done in the example of the ascii char conversion. : >CHAR ( [0,15] -- char ) DUP 9 > 7 AND + [CHAR] 0 + ; Someone threw around the term "idiomatic". I'm not sure that's a bad thing. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-10-16 23:31 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <e6194eb1-9e34-41cb-8096-16ffbfab791c@googlegroups.com> |
| In reply to | #51935 |
> By changing your entire Forth to use 1/0 as logic values you lose the > ability to use an arbitrary value as a flag. Nope. You only loose the ability to use the flag as a mask. And the ability to decrement. But gain the ability to increment. :D I never used the flag value directly in a program (for incrementing or decrementing or masking or any arithmetics). And my forth use 0/1 flags. And I can assure you that my forth programs work exactly the same in my 0/1 flags forth and in any 0/-1 flags forth.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-10-16 20:36 -1000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <mYOdnY4n4s3s7JnFnZ2dnUU7-ffNnZ2d@supernews.com> |
| In reply to | #51935 |
On 10/16/16 6:35 PM, rickman wrote: > On 10/17/2016 12:14 AM, Raimond Dragomir 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. > > You don't need to change the entire language to use bytes to store > flags. c! will store a TRUE as all ones. c@ will retrieve a value of > 255 on the stack. This will be treated as a TRUE as long as you don't > use it for anything but logic before you use it as logic. If you want > to store a value of 1 in the bytes so you can later count them, then > store them this way. > > 1 AND c! > > By changing your entire Forth to use 1/0 as logic values you lose the > ability to use an arbitrary value as a flag. In ANS Forth any value > that is not zero is treated as a TRUE by any function that evaluates a > logic flag. So a flag and a value ANDed together will give you a TRUE > if the value is not zero and the flag is TRUE or FALSE if either the > value is zero or the flag is FALSE. Just as you can use a flag as a > mask to perform logic on a value leaving at its present value or setting > it to zero which is what is done in the example of the ascii char > conversion. > > : >CHAR ( [0,15] -- char ) DUP 9 > 7 AND + [CHAR] 0 + ; > > Someone threw around the term "idiomatic". I'm not sure that's a bad > thing. Flags were 0 and 1 until Forth83, when they were changed to 0 and -1. A lot of people were mad about the change, but 30 years on we're happy with it (it was the transition that was painfull), and find masks at least as useful as counting values, probably moreso. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-17 13:11 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <489a3e19-944f-4290-8338-434e069933d1@googlegroups.com> |
| In reply to | #51940 |
On Sunday, October 16, 2016 at 11:36:39 PM UTC-7, Elizabeth D. Rather wrote:
> On 10/16/16 6:35 PM, rickman wrote:
> > On 10/17/2016 12:14 AM, Raimond Dragomir 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.
> >
> > You don't need to change the entire language to use bytes to store
> > flags. c! will store a TRUE as all ones. c@ will retrieve a value of
> > 255 on the stack. This will be treated as a TRUE as long as you don't
> > use it for anything but logic before you use it as logic. If you want
> > to store a value of 1 in the bytes so you can later count them, then
> > store them this way.
> >
> > 1 AND c!
> >
> > By changing your entire Forth to use 1/0 as logic values you lose the
> > ability to use an arbitrary value as a flag. In ANS Forth any value
> > that is not zero is treated as a TRUE by any function that evaluates a
> > logic flag. So a flag and a value ANDed together will give you a TRUE
> > if the value is not zero and the flag is TRUE or FALSE if either the
> > value is zero or the flag is FALSE. Just as you can use a flag as a
> > mask to perform logic on a value leaving at its present value or setting
> > it to zero which is what is done in the example of the ascii char
> > conversion.
> >
> > : >CHAR ( [0,15] -- char ) DUP 9 > 7 AND + [CHAR] 0 + ;
> >
> > Someone threw around the term "idiomatic". I'm not sure that's a bad
> > thing.
>
> Flags were 0 and 1 until Forth83, when they were changed to 0 and -1. A
> lot of people were mad about the change, but 30 years on we're happy
> with it (it was the transition that was painfull), and find masks at
> least as useful as counting values, probably moreso.
>
> Cheers,
> Elizabeth
Charles Moore got kicked out of Forth Inc. in 1982. Forth-83 came out in 1983.
Forth-83 was a major screw-up by Elizabeth Rather, and ANS-Forth was another major screw-up from Elizabeth Rather, and Forth-200x is the current major screw-up from Elizabeth Rather.
Elizabeth Rather has never made a positive contribution to Forth. The only way for Forth to be saved, is for Elizabeth Rather to kicked out of the Forth community. It doesn't really matter that much if Straight Forth becomes the new standard, or something else, so long as it is designed by programmers rather than by an idiot salesperson and her sycophants --- I obviously think that Straight Forth is going in the right direction --- I am willing to accept input from any Forth programmer though.
> >> luni, 17 octombrie 2016, 05:27:21 UTC+3, rickman a scris:
> > : >CHAR ( [0,15] -- char ) DUP 9 > 7 AND + [CHAR] 0 + ;
> >
> > Someone threw around the term "idiomatic". I'm not sure that's a bad
> > thing.
Anyway, 0/1 is the obvious choice for a flag because it is common to add the flag to a counter as I did in my hottie-counting example. It is very rare to use a flag as a mask, and it results in hard-to-read code such as the idiomatic ANS-Forth version of >CHAR shown above --- if you really need this though, then just NEGATE your flag to get a mask --- the 0/1 flag seems so obvious a design decision to me as to be hardly worth a debate, but as I said above, I'm willing to listen to Forth programmers' opionions.
Here is yet another excerpt from my Straight Forth document:
-----------------------------------------------------------------------------
In Straight Forth we have these functions:
TRUE ( -- 1 ) A TRUE flag is 1 (not -1 like in ANS-Forth).
FALSE ( -- 0 ) A FALSE flag is 0.
FLAG ( val -- flag ) Convert any non-zero into TRUE, and leave zero as FALSE.
NOT ( val -- flag ) Convert zero into TRUE, and convert any non-zero into FALSE.
TOG ( val -- ~val ) Toggle all of the bits (integer part only).
AND ( a b -- val ) AND all of the bits (integer part only).
OR ( a b -- val ) Inclusive OR all of the bits (integer part only).
XOR ( a b -- val ) Exclusive OR all of the bits (integer part only).
Note that a TRUE flag is 1, so it can be used as a value to be added to a counter (this can sometimes be useful for eliminating IF THEN constructs). Note also that Straight Forth has NOT and FLAG (rather than 0= and 0<> as used in ANS-Forth) which can improve readability. All bit-logic operations support only the integer part, and are good for 32 bits. The concept of doing bit-logic on the fractional part doesn't make much sense anyway --- normally bit-logic is only used for I/O or flags, which only involve integers.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-10-17 19:14 -0400 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <20161017191421.6b37816b@_> |
| In reply to | #51945 |
On Mon, 17 Oct 2016 13:11:49 -0700 (PDT) hughaguilar96@gmail.com wrote: > In Straight Forth we have these functions: > TRUE ( -- 1 ) A TRUE flag is 1 > (not -1 like in ANS-Forth). FALSE ( -- 0 > ) A FALSE flag is 0. FLAG ( val -- > flag ) Convert any non-zero into TRUE, and leave zero > as FALSE. NOT ( val -- flag ) Convert > zero into TRUE, and convert any non-zero into FALSE. TOG > ( val -- ~val ) Toggle all of the bits (integer part > only). AND ( a b -- val ) AND all of the > bits (integer part only). OR ( a b -- val > ) Inclusive OR all of the bits (integer part only). > XOR ( a b -- val ) Exclusive OR all of > the bits (integer part only). > > Note that a TRUE flag is 1, so it can be used as a value to be added > to a counter (this can sometimes be useful for eliminating IF THEN > constructs). Note also that Straight Forth has NOT and FLAG (rather > than 0= and 0<> as used in ANS-Forth) which can improve readability. > All bit-logic operations support only the integer part, and are good > for 32 bits. The concept of doing bit-logic on the fractional part > doesn't make much sense anyway --- normally bit-logic is only used > for I/O or flags, which only involve integers. I would argue that when using zero as false and true as non-zero, then the best non-zero value for true is -1 (all bits set). As others have noted, -1 can be used for masking with AND, OR, XOR and will generate a false (0) and true (non-zero) result without needing to convert true, non-zero results to true as either 1 or -1. A single bit value of 1 for true can't be used for this. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-10-17 21:53 +0000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nu3h83$vjj$1@dont-email.me> |
| In reply to | #51940 |
Am Sun, 16 Oct 2016 20:36:32 -1000 schrieb Elizabeth D. Rather: > Flags were 0 and 1 until Forth83, when they were changed to 0 and -1. A > lot of people were mad about the change, but 30 years on we're happy > with it (it was the transition that was painfull), and find masks at > least as useful as counting values, probably moreso. IIRC, Andy Glew reported in comp.arch, that he proposed to add a setcc instruction to the P6 which returned all bits set for "true", just as the MMX compare instructions do; to be used for masking. This was dismissed, but the MMX and SSE compare instructions indeed return Forth flags, not C flags. That's absolutely necessary for a vector unit. Looking at ARMv8's vector instructions shows the same pattern. 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, and that for already 20 years now. 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). ARMv7 just uses two conditional move instructions, one with the false flag (#0), one with the true flag (#1 in the C case, and MVN #0 in the Forth case), so ARMv7 can generate Forth flags with the same cost as C flags, but just as a consequence of general architecture features. csinv on ARMv8 is dedicated at generating Forth flags. Apparently, these sorts of flags make more sense in general, because for the Forth world only, that wouldn't be sufficient incentive to add instructions like that. -- 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-17 16:54 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <8d83e23f-76fd-428e-8e8c-4b087d0821d3@googlegroups.com> |
| In reply to | #51947 |
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”.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-10-21 22:13 +0000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nue3u6$d47$3@dont-email.me> |
| In reply to | #51955 |
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 that the vector instructions were first (20 years ago with MMX), and that recent ISAs like ARMv8 also have it for the integer case, with special instructions (where ARMv7 had it "by accident" with a general instruction, not by design). So it's now "in general". In the P6 case, it was already suggested by the designers, and dismissed by management. Read it again. Those parts you deleted. -- 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-21 17:46 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <4d111d08-e44d-4563-896b-e174f5c6f4d6@googlegroups.com> |
| In reply to | #52099 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-10-23 22:26 +0000 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <nujdf4$m75$1@dont-email.me> |
| In reply to | #52105 |
Am Fri, 21 Oct 2016 17:46:11 -0700 schrieb lawrencedo99: > On Saturday, October 22, 2016 at 11:13:48 AM UTC+13, Bernd Paysan wrote: > ... 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. No, I mean, read the part of my posting you deleted. I didn't write that special-purpose vector instructions have become commonplace, but that the Forth-like flag first defined in the special-purpose vector instructions *now* became part of the normal integer instruction set. You can't read. Deleting the actual argument, because you stopped reading after the first few sentences means you are only skipping over texts, not reading them. -- 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 | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-10-24 09:13 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <871ea8e0-b167-4d7e-9513-a3204014e084@googlegroups.com> |
| In reply to | #52105 |
On Saturday, October 22, 2016 at 1:46:13 AM UTC+1, lawren...@gmail.com 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.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web