Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #18710 > unrolled thread
| Started by | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| First post | 2013-01-13 06:37 +0000 |
| Last post | 2013-01-13 12:44 +0000 |
| Articles | 20 on this page of 100 — 35 participants |
Back to article view | Back to comp.lang.forth
Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 06:37 +0000
Re: Parallax Propeller MK <mk@nospam.co.uk> - 2013-01-13 10:26 +0000
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:22 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-13 07:24 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 13:55 +0000
Re: Parallax Propeller mhx@iae.nl (Marcel Hendrix) - 2013-01-13 17:13 +0200
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 06:23 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:01 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 09:12 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:36 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 10:59 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 23:38 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-17 04:04 -0600
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-17 04:52 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:48 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:10 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:42 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:05 -0500
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 08:41 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-05 10:21 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 21:37 +0100
Re: Parallax Propeller "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 10:44 -1000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 15:52 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:29 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:31 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:46 +0100
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-09 00:11 -0800
Re: Parallax Propeller anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-09 10:25 +0000
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 18:26 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:07 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:49 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:04 -0500
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:21 -0800
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-16 18:09 -0500
Re: Parallax Propeller Ben Bradley <ben_u_bradley@etcmail.com> - 2013-01-18 21:07 -0500
Re: Parallax Propeller "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-19 10:06 +0000
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-19 13:04 +0100
Re: Parallax Propeller "A. K." <akk@nospam.org> - 2013-01-19 13:22 +0100
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-19 13:38 +0100
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-19 17:12 +0100
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-19 16:45 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 17:49 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 20:54 +0200
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 11:04 -0800
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 23:05 +0200
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-20 01:05 -0800
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-20 12:11 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:53 +0200
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:26 +0200
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:23 -0600
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:18 -0600
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 20:32 +0100
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-20 18:08 -0600
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 17:12 -0500
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-20 19:19 -0500
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 21:12 -0500
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-21 09:01 +0100
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-21 21:11 -0500
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-22 09:39 +0200
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-22 10:14 -0500
Re: Parallax Propeller Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2013-01-20 02:03 +0000
Re: Parallax Propeller George Neuner <gneuner2@comcast.net> - 2013-01-19 12:29 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:29 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-24 14:03 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:55 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:03 -0800
Re: Parallax Propeller Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:02 +0100
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:13 -0800
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-29 09:15 +0100
Re: Parallax Propeller Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-01-30 12:19 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-30 21:18 +0100
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-30 22:57 -0800
Re: Parallax Propeller Alex McDonald <blog@rivadpm.com> - 2013-01-31 10:38 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:34 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 10:42 -0800
Re: Parallax Propeller bob@bob.com - 2013-01-19 19:56 -0600
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:40 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-24 23:26 +0000
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-25 11:49 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-25 09:25 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-25 21:57 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-26 18:07 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-27 00:50 -0800
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-27 03:30 -0600
Re: Parallax Propeller Dombo <dombo@disposable.invalid> - 2013-01-27 12:58 +0100
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:38 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-27 03:09 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:51 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-30 02:10 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-30 18:32 -0500
Re: Parallax Propeller David Schultz <abuse@127.0.0.1> - 2013-01-20 11:21 -0600
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-13 16:24 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-14 10:51 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:06 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-16 13:43 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:27 +0000
Re: Parallax Propeller Rafael Deliano <rafael_deliano@arcor.de> - 2013-01-15 21:10 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:26 +0000
Re: Parallax Propeller gavino_himself <visploveslisp@gmail.com> - 2013-01-22 06:26 -0800
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:44 +0000
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-13 06:37 +0000 |
| Subject | Parallax Propeller |
| Message-ID | <lCsIs.2517$1k5.1748@viwinnwfe01.internal.bigpond.com> |
For some reason I found myself reading these newsgroups which I haven't really used for many years. It seems that although the Parallax Propeller web forums are extremely active there never seems to be much discussion elsewhere. Aren't you all curious as to what you are missing out on? I have used just about every kind of micro and architecture over the decades and while I might still use some small "one buck" micros for certain tasks and some special ARM chips for higher end tasks I have almost exclusively been using Propeller chips for everything else. The reason is very simple, they are so simple to work with and there are no "peripheral modules" to worry about other than the counters and video hardware per cog. Every pin is general-purpose and any one of the eight 32-bit cores can use them, you don't have to worry about trying to route a special pin or have the dilemma of using the special pin for one function but not the other etc. The 32-bit CPUs or cogs are a breeze to program and you can work with a variety of languages besides the easy to use Spin compiler that comes with it. For you Forth enthusiasts there has been a big flurry of Forth related threads on the Propeller forums of late and there are several versions of Forth including my own Tachyon Forth. IMHO this is the best way to get into the Propeller and it's hardware. I just can't be bother trying to cram functions and debug interrupts on other chips when I can set a cog to work on a task and still have plenty of resources left over including video on-chip. If you are intrigued or just plain curious it won't kill you unless you are a cat to have a look at my introduction page which has links to projects and the forum etc. http://goo.gl/VX7pc There is the sup'ed up version of the Propeller, the Propeller II coming out in the following months which has 96 I/O, 8 cogs, 128K RAM and 160MIPS/core. BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) that hang off the "I2C bus" from the Propeller and I can load new firmware into each chip using just one extra line to program them in-circuit. *peter*
[toc] | [next] | [standalone]
| From | MK <mk@nospam.co.uk> |
|---|---|
| Date | 2013-01-13 10:26 +0000 |
| Message-ID | <XeqdnWlVy7ZKFm_NnZ2dnUVZ8r2dnZ2d@bt.com> |
| In reply to | #18710 |
On 13/01/2013 06:37, Peter Jakacki wrote: > > For some reason I found myself reading these newsgroups which I haven't > really used for many years. It seems that although the Parallax Propeller > web forums are extremely active there never seems to be much discussion > elsewhere. Aren't you all curious as to what you are missing out on? > > I have used just about every kind of micro and architecture over the > decades and while I might still use some small "one buck" micros for > certain tasks and some special ARM chips for higher end tasks I have > almost exclusively been using Propeller chips for everything else. The > reason is very simple, they are so simple to work with and there are no > "peripheral modules" to worry about other than the counters and video > hardware per cog. Every pin is general-purpose and any one of the eight > 32-bit cores can use them, you don't have to worry about trying to route > a special pin or have the dilemma of using the special pin for one > function but not the other etc. The 32-bit CPUs or cogs are a breeze to > program and you can work with a variety of languages besides the easy to > use Spin compiler that comes with it. > > For you Forth enthusiasts there has been a big flurry of Forth related > threads on the Propeller forums of late and there are several versions of > Forth including my own Tachyon Forth. IMHO this is the best way to get > into the Propeller and it's hardware. I just can't be bother trying to > cram functions and debug interrupts on other chips when I can set a cog > to work on a task and still have plenty of resources left over including > video on-chip. > > If you are intrigued or just plain curious it won't kill you unless you > are a cat to have a look at my introduction page which has links to > projects and the forum etc. > http://goo.gl/VX7pc > > There is the sup'ed up version of the Propeller, the Propeller II coming > out in the following months which has 96 I/O, 8 cogs, 128K RAM and > 160MIPS/core. > > BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) that > hang off the "I2C bus" from the Propeller and I can load new firmware > into each chip using just one extra line to program them in-circuit. > > *peter* > > Had a quick look (again) - it's not very fast and it's not very cheap (compared with a CortexM4 clocked at 150MHz or more). Then there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA on a typical M4 based micro-controller. For some applications I'm sure it's a really good fit but I haven't hit one yet. It's similar in concept to XMOS and Greenchip offerings but like them suffers from a less than first rank supplier which would worry most of my customers. MK
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-13 12:22 +0000 |
| Message-ID | <LFxIs.2582$Ow3.159@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18712 |
On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote: > On 13/01/2013 06:37, Peter Jakacki wrote: >> >> For some reason I found myself reading these newsgroups which I haven't >> really used for many years. It seems that although the Parallax >> Propeller web forums are extremely active there never seems to be much >> discussion elsewhere. Aren't you all curious as to what you are missing >> out on? >> >> I have used just about every kind of micro and architecture over the >> decades and while I might still use some small "one buck" micros for >> certain tasks and some special ARM chips for higher end tasks I have >> almost exclusively been using Propeller chips for everything else. The >> reason is very simple, they are so simple to work with and there are no >> "peripheral modules" to worry about other than the counters and video >> hardware per cog. Every pin is general-purpose and any one of the eight >> 32-bit cores can use them, you don't have to worry about trying to >> route a special pin or have the dilemma of using the special pin for >> one function but not the other etc. The 32-bit CPUs or cogs are a >> breeze to program and you can work with a variety of languages besides >> the easy to use Spin compiler that comes with it. >> >> For you Forth enthusiasts there has been a big flurry of Forth related >> threads on the Propeller forums of late and there are several versions >> of Forth including my own Tachyon Forth. IMHO this is the best way to >> get into the Propeller and it's hardware. I just can't be bother trying >> to cram functions and debug interrupts on other chips when I can set a >> cog to work on a task and still have plenty of resources left over >> including video on-chip. >> >> If you are intrigued or just plain curious it won't kill you unless you >> are a cat to have a look at my introduction page which has links to >> projects and the forum etc. >> http://goo.gl/VX7pc >> >> There is the sup'ed up version of the Propeller, the Propeller II >> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM >> and 160MIPS/core. >> >> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) >> that hang off the "I2C bus" from the Propeller and I can load new >> firmware into each chip using just one extra line to program them >> in-circuit. >> >> *peter* >> >> > Had a quick look (again) - it's not very fast and it's not very cheap > (compared with a CortexM4 clocked at 150MHz or more). Then there is all > the pain of programming and synching multiple cores which is (I think) > worse than the pain of managing DMA on a typical M4 based > micro-controller. > For some applications I'm sure it's a really good fit but I haven't hit > one yet. It's similar in concept to XMOS and Greenchip offerings but > like them suffers from a less than first rank supplier which would worry > most of my customers. > > MK Since I've had a lot of experience with the Propeller and ARMs and I'm familiar with M4s (still pushing out a design) then I can say that unless you actually sit down with it for an hour or two that you will probably continue to have this misconceptions. Is that the way that the Propeller comes across? I've always wondered about that. No, your idea of the Propeller is so off the mark, I'm saying that not to offend, just setting the record straight although I appreciate the honest opinion as this gives me something to work on in explaining what it is and what it is not. First off, don't try to compare this with an XMOS or GreenArrays (I think you mean) as they are very different. No, the Propeller is more like 8 identical 32-bit CPUs + counter and video hardware and 512 longs of RAM each sharing all 32 I/O in common and coupled to a multi-port 32kB RAM (hub). Sounds strange? Okay, but the eight cogs are not really utilised for "parallel processing" but think of each cog as either a CPU or a virtual peripheral or both. The way it's used is that you might setup one cog as an intelligent quad port UART, another as the VGA cog, another as keyboard and mouse etc while maybe only one cog is processing the application. When you see it in action it is very simple to program even for a beginner. Seeing that each cog only has 512 longs of RAM which it directly addresses both source and destination in each 32-bit instruction, it becomes necessary then to run a virtual machine for high level application code. This is what Spin does as it compiles bytecode in hub RAM while one or more cogs may have the Spin interpreter loaded. My Tachyon Forth does something similar but has a much faster runtime speed and of course the target hosts a Forth development and runtime system. So I use bytecode that directly addresses the code in the first 256 longs of the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode instructions/second and since there are no interrupts!! nor any need for them then each cog runs unencumbered. Realtime software development and testing has never been easier. Hopefully I've put it in some kind of nutshell. What do you think? Weird? Yes, but it works really well :) *peter*
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-13 07:24 -0600 |
| Message-ID | <xNGdnX2QML0OKG_NnZ2dnUVZ_rCdnZ2d@supernews.com> |
| In reply to | #18713 |
In comp.lang.forth Peter Jakacki <peterjakacki@gmail.com> wrote: > I use bytecode that directly addresses the code in the first 256 > longs of the Tachyon VM. Each cog runs at a maximum of 2.5M Forth > bytecode instructions/second and since there are no interrupts!! nor > any need for them then each cog runs unencumbered. Realtime software > development and testing has never been easier. > > Hopefully I've put it in some kind of nutshell. What do you think? > Weird? Yes, but it works really well :) I think this looks really good. Fast and simple multi-tasking with even less overhead than the simplest Forth scheduler. Extremely low latency. Cheap, simple. I'm sorry I didn't hear about this years ago. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-13 13:55 +0000 |
| Message-ID | <e1zIs.2586$Ow3.1870@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18715 |
On Sun, 13 Jan 2013 07:24:35 -0600, Andrew Haley wrote: > In comp.lang.forth Peter Jakacki <peterjakacki@gmail.com> wrote: > >> I use bytecode that directly addresses the code in the first 256 longs >> of the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode >> instructions/second and since there are no interrupts!! nor any need >> for them then each cog runs unencumbered. Realtime software development >> and testing has never been easier. >> >> Hopefully I've put it in some kind of nutshell. What do you think? >> Weird? Yes, but it works really well :) > > I think this looks really good. Fast and simple multi-tasking with even > less overhead than the simplest Forth scheduler. Extremely low latency. > Cheap, simple. I'm sorry I didn't hear about this years ago. > > Andrew. Yes, when you run a task in a cog then that is all it has to do. There is no need for task switching or interrupts etc. Some of my biggest headaches had to do with mysterious glitches which always end up being traced back to the wrong interrupts at the wrong time, but only sometimes, just to make it harder to find. The P2 which is due to be released soon allows each cog to run up to 4 tasks with zero switching overhead, you can even set the switching priority patterns in a 32-bit mask. But P2 runs 8 times faster than P1 just in terms of IPS alone without taking in account the many enhancements. Although the P2 has not yet been released there are many of us testing code for this on FPGA boards such as the DE2-115 or Nanos because Parallax made the FPGA binary for the P2 openly available. Can you beat that? Never ever heard of any chip company doing anything even close to that. *peter*
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2013-01-13 17:13 +0200 |
| Message-ID | <16901890028434@frunobulax.edu> |
| In reply to | #18716 |
Peter Jakacki <peterjakacki@gmail.com> writes Re: Parallax Propeller > On Sun, 13 Jan 2013 07:24:35 -0600, Andrew Haley wrote: [..] >> I think this looks really good. Fast and simple multi-tasking with even >> less overhead than the simplest Forth scheduler. Extremely low latency. >> Cheap, simple. I'm sorry I didn't hear about this years ago. [..] > The P2 which is due to be released soon allows each cog to run up to 4 > tasks with zero switching overhead, you can even set the switching > priority patterns in a 32-bit mask. But P2 runs 8 times faster than P1 > just in terms of IPS alone without taking in account the many > enhancements. Although the P2 has not yet been released there are many of > us testing code for this on FPGA boards such as the DE2-115 or Nanos > because Parallax made the FPGA binary for the P2 openly available. Can > you beat that? Never ever heard of any chip company doing anything even > close to that. Let me say that I too think this chip seems to be really nice! Indeed strange it didn't get a larger following from the Forth crowd. The YouTube videos show it's not a toy and that impressive things can be done. I had not enough time to delve through your tuts and the forum in depth, so maybe you are willing to answer a few quick questions? The stack depth seems to be limited to a very low value (12?). Is this the Forth implementation, or is a limitation of the chip? I saw in other threads on the forum that people talk about a few hundredth stack positions. What is a "branch stack?". The loop stack also seems to do something I'm not familiar with. The memory (512 longs?) seems to be seriously limited. What is the idea here? You have eight 32-bit high-speed processors but no RAM to match? Is this the case for the P2 too? (Hardware details are certainly well hidden :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-16 06:23 -0600 |
| Message-ID | <C82dne64V7NDBmvNnZ2dnUVZ_oqdnZ2d@supernews.com> |
| In reply to | #18717 |
Marcel Hendrix <mhx@iae.nl> wrote:
> Let me say that I too think this chip seems to be really nice! Indeed
> strange it didn't get a larger following from the Forth crowd. The YouTube
> videos show it's not a toy and that impressive things can be done.
>
> I had not enough time to delve through your tuts and the forum in depth,
> so maybe you are willing to answer a few quick questions?
>
> The stack depth seems to be limited to a very low value (12?). Is this
> the Forth implementation, or is a limitation of the chip? I saw in other
> threads on the forum that people talk about a few hundredth stack
> positions.
>
> What is a "branch stack?". The loop stack also seems to do something I'm
> not familiar with.
There is no real indirect addressing into cog memory. So, to push
onto the stack, you do this:
_PUSHACC mov X,ACC ' Accumulator operation used for fast constants
_PUSHX mov ACC,#0 ' clear it for next operation
_PUSHX1 mov tos+11,tos+10
mov tos+10,tos+9
mov tos+9,tos+8
mov tos+8,tos+7
mov tos+7,tos+6
mov tos+6,tos+5
mov tos+5,tos+4
mov tos+4,tos+3
mov tos+3,tos+2
mov tos+2,tos+1
mov tos+1,tos
mov tos,X ' replace tos with X (DEFAULT)
_PUSHACC_ret
_PUSHX_ret ret
... which sucks mightily, but rejoice! Propeller 2 has IND registers
that allow indirect register access. The manual is a bit vague about
how they work, but I have high hopes they'll allow a stack to be
created.
> The memory (512 longs?) seems to be seriously limited. What is the idea
> here? You have eight 32-bit high-speed processors but no RAM to match?
512 longs *per cog* plus 32k at the hub.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 15:01 +0000 |
| Message-ID | <PgzJs.2730$Ow3.2664@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18843 |
On Wed, 16 Jan 2013 06:23:58 -0600, Andrew Haley wrote: > Marcel Hendrix <mhx@iae.nl> wrote: >> Let me say that I too think this chip seems to be really nice! Indeed >> strange it didn't get a larger following from the Forth crowd. The >> YouTube videos show it's not a toy and that impressive things can be >> done. >> >> I had not enough time to delve through your tuts and the forum in >> depth, so maybe you are willing to answer a few quick questions? >> >> The stack depth seems to be limited to a very low value (12?). Is this >> the Forth implementation, or is a limitation of the chip? I saw in >> other threads on the forum that people talk about a few hundredth stack >> positions. >> >> What is a "branch stack?". The loop stack also seems to do something >> I'm not familiar with. > > There is no real indirect addressing into cog memory. So, to push onto > the stack, you do this: > > _PUSHACC mov X,ACC ' Accumulator operation used for > fast constants _PUSHX mov ACC,#0 ' clear it for next > operation _PUSHX1 mov tos+11,tos+10 > mov tos+10,tos+9 mov tos+9,tos+8 mov > tos+8,tos+7 mov tos+7,tos+6 mov tos+6,tos+5 > mov tos+5,tos+4 mov tos+4,tos+3 mov > tos+3,tos+2 mov tos+2,tos+1 mov tos+1,tos mov > tos,X ' replace tos with X (DEFAULT) > _PUSHACC_ret _PUSHX_ret ret > > ... which sucks mightily, but rejoice! Propeller 2 has IND registers > that allow indirect register access. The manual is a bit vague about > how they work, but I have high hopes they'll allow a stack to be > created. > >> The memory (512 longs?) seems to be seriously limited. What is the idea >> here? You have eight 32-bit high-speed processors but no RAM to match? > > 512 longs *per cog* plus 32k at the hub. > > Andrew. The brute force move looks slow but when you realise that operations on the stack are greatly simplified, that is they are fast and compact, then the benefits of this approach start to make sense. You may see elsewhere that the return stack uses a different method with self-modifying code to keep track of next position but none of the elements are directly addressable as they are on the parameter stack. There is no reason why we can't have more than two stacks in Forth especially considering that the return stack normally gets loop parameters and other stuff shoved onto it when this could lead to crashes if this stack has "junk" on it when Forth exits from a word. So I tend to use a LOOP stack to hold the stack index and limits plus in Tachyon I introduced the BRANCH stack which holds the backward branch address of loops rather than having to read these from slow hub RAM each time and calculating the branch. Normally DO and LOOP etc are immediate words which compile the runtime primitives and branch address but in Tachyon these words are not immediate and are compiled as is. At runtime DO pushes the loop parameters onto the LOOP stack and also the next program address onto the BRANCH stack. When LOOP is executed it runs as normal but instead of reading the following program location for a branch back to the start of the loop it instead loads the top of the BRANCH stack into the IP. Since it's all in cog RAM it is very fast. My Introduction to Tachyon Forth explains a lot of this kind of stuff and along with short tutorials also shows you how you can create a WAV player that reads directly from the SD card without requiring any buffers or variables and only takes up 65 bytes of program RAM. However the P2 has many enhancements including a 256 long stack per cog. Here's a link to the unofficial document I started up for this chip. http://goo.gl/SEi9h *peter*
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-16 09:12 -0600 |
| Message-ID | <3NidnUj714zFXmvNnZ2dnUVZ_sydnZ2d@supernews.com> |
| In reply to | #18846 |
Peter Jakacki <peterjakacki@gmail.com> wrote: > The brute force move looks slow but when you realise that operations > on the stack are greatly simplified, that is they are fast and > compact, then the benefits of this approach start to make sense. You > may see elsewhere that the return stack uses a different method with > self-modifying code to keep track of next position but none of the > elements are directly addressable as they are on the parameter > stack. > > There is no reason why we can't have more than two stacks in Forth > especially considering that the return stack normally gets loop > parameters and other stuff shoved onto it when this could lead to crashes > if this stack has "junk" on it when Forth exits from a word. Yeah, but you must realize that many of us in c.l.f. have been using Forth for a long time and stopped worrying about that a week or two after we started. It really isn't a problem. > However the P2 has many enhancements including a 256 long stack per cog. Much better. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 15:36 +0000 |
| Message-ID | <nOzJs.2732$Ow3.194@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18848 |
On Wed, 16 Jan 2013 09:12:24 -0600, Andrew Haley wrote: > > Yeah, but you must realize that many of us in c.l.f. have been using > Forth for a long time and stopped worrying about that a week or two > after we started. It really isn't a problem. > > Andrew. So you have no need to index I,J,K etc from a outside the loop? I have applications where it makes a lot of sense to refer to loop parameters from outside but there is no easy way to do so when you have return addresses and loop parameters plus whatever else intermixed. There is no good reason to leave Forth this way just because it was that way many decades ago. Anyway, this loop stack permits direct addressing of the multiple levels of loop parameters and in the case of the Propeller 1 is conducive to faster loop execution speed and more compact kernel assembly code. *peter*
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-16 10:59 -0600 |
| Message-ID | <6qmdncpi493EQWvNnZ2dnUVZ_gOdnZ2d@supernews.com> |
| In reply to | #18850 |
Peter Jakacki <peterjakacki@gmail.com> wrote: > On Wed, 16 Jan 2013 09:12:24 -0600, Andrew Haley wrote: > >> >> Yeah, but you must realize that many of us in c.l.f. have been using >> Forth for a long time and stopped worrying about that a week or two >> after we started. It really isn't a problem. > > So you have no need to index I,J,K etc from a outside the loop? No, that's poor Forth style. It tends to indicate unfactored code: Forth isn't about multiply-nested conditionals. This thing tends to happen to people who have come to Forth from other programming languages and don't yet quite Get It. > I have applications where it makes a lot of sense to refer to loop > parameters from outside but there is no easy way to do so when you > have return addresses and loop parameters plus whatever else > intermixed. I doubt it, to be honest. Conventionally, all arguments to a word are passed on the data stack, so that word can be executed from anywhere. It doesn't have to be executed from a word that just happens to have loops in the right place. It can be tested from the interpreter. This is the essence of Forth reuse: each word is a factor, and all arguments are on the stack. > There is no good reason to leave Forth this way just because it was > that way many decades ago. IMO, as you see from my response above, it's that way because it's the right way to do it. > Anyway, this loop stack permits direct addressing of the multiple > levels of loop parameters and in the case of the Propeller 1 is > conducive to faster loop execution speed and more compact kernel > assembly code. Fair enough. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 23:38 +0000 |
| Message-ID | <ERGJs.2741$Ow3.1891@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18853 |
On Wed, 16 Jan 2013 10:59:05 -0600, Andrew Haley wrote: > Peter Jakacki <peterjakacki@gmail.com> wrote: >> On Wed, 16 Jan 2013 09:12:24 -0600, Andrew Haley wrote: >> >> >>> Yeah, but you must realize that many of us in c.l.f. have been using >>> Forth for a long time and stopped worrying about that a week or two >>> after we started. It really isn't a problem. >> >> So you have no need to index I,J,K etc from a outside the loop? > > No, that's poor Forth style. It tends to indicate unfactored code: > Forth isn't about multiply-nested conditionals. This thing tends to > happen to people who have come to Forth from other programming languages > and don't yet quite Get It. > I know I don't have a problem with getting it but there seem to be a lot that don't get any more once they've "got it". Stuck in a loop perhaps? >> I have applications where it makes a lot of sense to refer to loop >> parameters from outside but there is no easy way to do so when you have >> return addresses and loop parameters plus whatever else intermixed. > > I doubt it, to be honest. Conventionally, all arguments to a word are > passed on the data stack, so that word can be executed from anywhere. It > doesn't have to be executed from a word that just happens to have loops > in the right place. It can be tested from the interpreter. This is the > essence of Forth reuse: each word is a factor, and all arguments are on > the stack. > >> There is no good reason to leave Forth this way just because it was >> that way many decades ago. > > IMO, as you see from my response above, it's that way because it's the > right way to do it. > >> Anyway, this loop stack permits direct addressing of the multiple >> levels of loop parameters and in the case of the Propeller 1 is >> conducive to faster loop execution speed and more compact kernel >> assembly code. > > Fair enough. > > Andrew. This last reason should be reason enough. Rather than trying to be "the expert" and beat down someone's rationale for deviations from "pure" Forth you should look at the end result, does it work and how well does it do it. As they say "the proof of the pudding is in the eating". Even Chuck's Forth chips use optimisations such as address registers and shallow circular stacks etc. For different reasons but in similar ways the architecture of Tachyon Forth is designed around both the features and limitations of the Propeller chip. The separate loop stack though is one I have used in other Forths and allows clear unimpeded access to return addresses and loop parameters. *peter*
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-17 04:04 -0600 |
| Message-ID | <5PqdnYkCmrsMUWrNnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #18866 |
Peter Jakacki <peterjakacki@gmail.com> wrote: > On Wed, 16 Jan 2013 10:59:05 -0600, Andrew Haley wrote: > >> Peter Jakacki <peterjakacki@gmail.com> wrote: >>> There is no good reason to leave Forth this way just because it was >>> that way many decades ago. >> >> IMO, as you see from my response above, it's that way because it's the >> right way to do it. >> >>> Anyway, this loop stack permits direct addressing of the multiple >>> levels of loop parameters and in the case of the Propeller 1 is >>> conducive to faster loop execution speed and more compact kernel >>> assembly code. >> >> Fair enough. > > This last reason should be reason enough. Rather than trying to be "the > expert" You asked "So you have no need to index I,J,K etc from a outside the loop?" and I answered "No." I don't really have to try to be "the expert" because in this case I can justify my opinions. As I did. > and beat down someone's rationale for deviations from "pure" > Forth you should look at the end result, does it work and how well does > it do it. As they say "the proof of the pudding is in the eating". Well, yes. On really odd targets you sometimes have to do really odd things. Sometimes it's necessary to cut corners to get the job done because of a shortage of time or resources. That's engineering. > Even Chuck's Forth chips use optimisations such as address registers > and shallow circular stacks etc. For different reasons but in > similar ways the architecture of Tachyon Forth is designed around > both the features and limitations of the Propeller chip. The > separate loop stack though is one I have used in other Forths and > allows clear unimpeded access to return addresses and loop > parameters. I can see that, but the problem here is that stack access is expensive relative to simple cog memory access: for every push there are a dozen reads and a dozen writes. From any reasonable engineering viewpoint this is not good. That you are forced to do so because of the odd architecture of the propeller Mark 1 is a good enough reason, but this seems to be fixed with Mark 2. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2013-01-17 04:52 -0800 |
| Message-ID | <f6987eb3-3d08-4323-bd54-bb7784d6b77a@y8g2000vbb.googlegroups.com> |
| In reply to | #18850 |
On Jan 16, 3:36 pm, Peter Jakacki <peterjaka...@gmail.com> wrote: > So you have no need to index I,J,K etc from a outside the loop? It's quite possible that that need may arise, but if it does, you don't need to access the loop index outside of the loop as "I" (i.e. using the word I). Access it inside the loop as I, and pass it to your out-of-loop word via the stack. That's what the stack is for. If your architecture is sufficiently different however, such that the system overall benefits from the extra stack (and it sounds like it does in your particular case) then overall your decision is probably justified, though being able to access I,J & K by name outside of a loop isn't (IMHO) reason enough alone for justifying the extra stack. I suspect that there is a preference for more stacks among in- experienced implementers. I've only implemented one Forth system, and I remember very distinctly being in favour of more stacks, because the implementation of things like loops, locals etc is perceived to be simpler. It possibly is. However, I persevered and got the job done with just the two stacks, and now I kind of wonder what the fuss was all about! :-)
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-01-24 22:48 -0800 |
| Message-ID | <2bb0e774-9b80-44ae-8873-0d16dbb07335@t6g2000pba.googlegroups.com> |
| In reply to | #18850 |
On Jan 16, 8:36 am, Peter Jakacki <peterjaka...@gmail.com> wrote: > On Wed, 16 Jan 2013 09:12:24 -0600, Andrew Haley wrote: > > > Yeah, but you must realize that many of us in c.l.f. have been using > > Forth for a long time and stopped worrying about that a week or two > > after we started. It really isn't a problem. > > > Andrew. > > So you have no need to index I,J,K etc from a outside the loop? I have > applications where it makes a lot of sense to refer to loop parameters > from outside but there is no easy way to do so when you have return > addresses and loop parameters plus whatever else intermixed. There is no > good reason to leave Forth this way just because it was that way many > decades ago. Anyway, this loop stack permits direct addressing of the > multiple levels of loop parameters and in the case of the Propeller 1 is > conducive to faster loop execution speed and more compact kernel assembly > code. > > *peter* I am getting rid of DO loops altogether in Straight Forth. I'm also getting rid of >R R@ R> etc., or at least deprecating them. I use BEGIN loops with local variables for iteration. DO loops were invented in the 1970s, prior to Forth having local variables --- I and J are just crude implementations of local variables. I think that DO loops are overly complicated. It is weird to have I and J available only in the loop and not outside. Also, if you have nested loops, I means one thing in the outer loop and something else in the inner loop --- that's confusing. Also, it is very confusing that >R R@ R> etc. can be used in a colon word, but they can't carry values into the DO loop --- so they can't really be used as local variables, which is their intended purpose. DO loops are also anti-intuitive and confusing when you are descending rather than ascending. All in all, DO loops are an ugly kludge from the 1970s that can be discarded. Also, I have separate stacks for single-precision and double-precision data (and a third stack for floats) --- I don't jumble different types of data together on the same stack as done in ANS-Forth, which is another 1970s kludge (jumbling everything together was originally done due to a shortage of registers and shortage of memory). BTW --- On the subject of interrupts, the MiniForth didn't have interrupts --- it just did polling. IIRC, that was in DOCOLON and BRANCH. There was no branch instruction in the assembly language, so it was impossible to iterate except in colon words, so it never happened that any significant time went by without DOCOLON or BRANCH executing. There may have been something similar to the x86's CMOVcc instruction --- I can't remember now, as that was almost 20 years ago. It didn't have conditional flags (sign, zero, carry, etc.) like most processors do --- the comparison and what happened in response were hardwired together in the same instruction. That was very low-level programming!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2013-01-24 23:10 -0800 |
| Message-ID | <52dbbaee-c41d-4c9e-a053-9e9acfc360b5@f6g2000yqm.googlegroups.com> |
| In reply to | #19115 |
On Jan 25, 6:48 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > I am getting rid of DO loops altogether in Straight Forth. I'm also > getting rid of >R R@ R> etc., or at least deprecating them. I use > BEGIN loops with local variables for iteration. DO loops were invented > in the 1970s, prior to Forth having local variables --- I and J are > just crude implementations of local variables. I think that DO loops > are overly complicated. It is weird to have I and J available only in > the loop and not outside. Also, if you have nested loops, I means one > thing in the outer loop and something else in the inner loop --- > that's confusing. Also, it is very confusing that >R R@ R> etc. can be > used in a colon word, but they can't carry values into the DO loop --- > so they can't really be used as local variables, which is their > intended purpose. DO loops are also anti-intuitive and confusing when > you are descending rather than ascending. All in all, DO loops are an > ugly kludge from the 1970s that can be discarded. A lot of the problems you cite, which are definately real gotcha's (though one learns to live with them) evaporate when one uses a dedicated stack for loop control. Worth considering. The restrictions/gotcha's are certainly a problem for newbies. If one has implemented their own Forth system, one knows why these restriction exist, so they're never really bothered by them, but if you've come to the languge from some other language, it's going to be a real issue - the reasons why will not be clear. And of course, one should not really have to be familiar with the internal workings of a Forth system in order to use it. Loops is one area where the 2012 standard could do with some more work! Why not mandate a flow-control stack. Go on, take the plunge! You'll be glad you did!
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-01-28 17:42 -0800 |
| Message-ID | <a4032a5a-73c6-485e-8ffa-2ec01da40f51@po6g2000pbb.googlegroups.com> |
| In reply to | #19119 |
On Jan 25, 12:10 am, Mark Wills <forthfr...@gmail.com> wrote: > On Jan 25, 6:48 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > > > I am getting rid of DO loops altogether in Straight Forth. I'm also > > getting rid of >R R@ R> etc., or at least deprecating them. I use > > BEGIN loops with local variables for iteration. DO loops were invented > > in the 1970s, prior to Forth having local variables --- I and J are > > just crude implementations of local variables. I think that DO loops > > are overly complicated. It is weird to have I and J available only in > > the loop and not outside. Also, if you have nested loops, I means one > > thing in the outer loop and something else in the inner loop --- > > that's confusing. Also, it is very confusing that >R R@ R> etc. can be > > used in a colon word, but they can't carry values into the DO loop --- > > so they can't really be used as local variables, which is their > > intended purpose. DO loops are also anti-intuitive and confusing when > > you are descending rather than ascending. All in all, DO loops are an > > ugly kludge from the 1970s that can be discarded. > > A lot of the problems you cite, which are definately real gotcha's > (though one learns to live with them) evaporate when one uses a > dedicated stack for loop control. Worth considering. > > The restrictions/gotcha's are certainly a problem for newbies. If one > has implemented their own Forth system, one knows why these > restriction exist, so they're never really bothered by them, but if > you've come to the languge from some other language, it's going to be > a real issue - the reasons why will not be clear. And of course, one > should not really have to be familiar with the internal workings of a > Forth system in order to use it. That is somewhat of a Catch-22 --- that a person has to write a compiler first, before knowing enough about the language to write a simple program. In my experience, there are more people who have written a Forth compiler, than have written a Forth program --- maybe 10 to 1. Forth is seen as a science-fair project, and not a practical language. The whole point of Straight Forth is to make a language that is easy to learn and easy to use. I'm dropping all of that cruft from the 1970s that was originally introduced to work-around some limitation of the processor, such as lack of registers and lack of memory. There is no point in solving problems that haven't existed in 30 years --- that is like wearing cowboy boots because they work well for horseback riding, and suffering foot problems because they are uncomfortable as heck for walking, and doing this in the city! > Loops is one area where the 2012 standard could do with some more > work! Why not mandate a flow-control stack. Go on, take the plunge! > You'll be glad you did! I think we are on the same page here. In Straight Forth I mandate that the local-stack (which is also used by loops) and the stack used by >R R@ R> are separate. Using the same stack creates incredible confusion --- this was only done because those old 8-bit chips lacked enough registers for each stack to have its own register dedicated as a stack pointer. Actually, the ANS-Forth committee screwed up anyway, because if they were to have only one register dedicated, they should have made it a local stack and discarded >R R@ R> altogether. Those >R R@ R> words are ugly and confusing --- the primary reason they were introduced was because locals were difficult to implement on the early processors (for example, on the 65c02 there is no addressing mode relative to the return-stack pointer S). The >R R@ R> words are mildly useful, in that they facilitate variable numbers of parameters (usually with a sentinel of some kind underneath the data), but that isn't done very often, and it can be done with a linked-list instead (as done in Lisp). I have fond memories of the 65c02, as that was the processor I lost my assembly-language virginity on. I think it is time for Forth to stop supporting such limited processors though. Forth-200x won't stop though, because it is all about supporting 20-year-old (1994) legacy ANS-Forth code, and ANS-Forth was also all about supporting 20-year- old (1974) legacy code. The Forth-200x committee is entirely focused on the past, which is why they don't have a future. By comparison, Straight Forth will be all about supporting modern concepts such as closures --- considering how few Forth programmers there are (pretty close to none), legacy Forth code isn't really something I need to worry about, as it has all been ported over to C a long time ago.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2013-02-05 06:05 -0500 |
| Message-ID | <keqoub$in2$1@speranza.aioe.org> |
| In reply to | #19233 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:a4032a5a-73c6-485e-8ffa-2ec01da40f51@po6g2000pbb.googlegroups.com...
...
> By comparison, Straight Forth will be all about
> supporting modern concepts such as closures ---
People keep telling me C needs this closure concept also. I have
yet to run into some situation that can't be coded in C. I've
coded alot of simple stuff and well as some really complex stuff.
So, what do I need closures for? I suspect the same issue I have
with not needing them is true for Forth too. I.e., closures are
desired by you because it fits your coding style or perhaps your
way of thinking, but they're not _really_ needed. If they're not
*really* needed, should the be present in the language proper?
That's really a question for comp.lang.misc.
However, I think your goal actually requires more than just
eliminating all the ancient Forth cruft. I think you should start
by naming things what they should've be named, e.g., logical not
named NOT, etc. The names need to make sense. ANS and earlier
standards renamed a few things to prevent namespace collisions.
Unfortunately, that means that some names make no sense. That
alienates programmers. Also, I think you should adopt C style
symbol operators instead of using word names, e.g., AND, OR, XOR,
NOT, etc for logical and binary operations. Most currently
successful modern languages have adopted C's style of naming for
such operators. Forth needs some minimal syntax, like braces { },
needs some operators other than +! to manipulate variables
directly, etc. Non-use of variables, specifically, heavy
dependence on the stack, also leads to hard to comprehend code.
Once you get done fixing Forth's problems, is the language still
Forth? I know that question _seems_ silly to you right now, but
it comes directly from my experience with another language: C. In
attempting to create a minimal version of C, once I reduce C to
the minimal language subset of C that is required, fix the
remaining historical language problems, make parsing and compiling
easier, etc, then the language I have left is no longer C anymore.
It's still C looking. It's still C like. But, it's not C. Once
you start radically changing things on your own to "fix" Forth,
i.e., StraightForth, it's not really going to be Forth anymore, at
least not in the classic sense. That's something I think you
haven't truly accepted yet. If you did, we'd be seeing your
progress reports, your questions, your website, etc. I.e.,
StraightForth is a stalled idea since it seems apparent you're not
actually working on it. If you're attempting to inspire interest
in it to attract developers, perhaps you just need to ask.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-05 08:41 -0600 |
| Message-ID | <T5GdnUAcdsK9h4zMnZ2dnUVZ_oGdnZ2d@supernews.com> |
| In reply to | #19452 |
Rod Pemberton <do_not_have@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message > news:a4032a5a-73c6-485e-8ffa-2ec01da40f51@po6g2000pbb.googlegroups.com... > ... > >> By comparison, Straight Forth will be all about >> supporting modern concepts such as closures --- > > People keep telling me C needs this closure concept also. I have > yet to run into some situation that can't be coded in C. I think closures are more C++ than C. Closures are really just about notational convenience and expressiveness. There is nothing that you can't write in C, but it might be a lot of C. > I've coded alot of simple stuff and well as some really complex > stuff. So, what do I need closures for? I suspect the same issue I > have with not needing them is true for Forth too. I.e., closures > are desired by you because it fits your coding style or perhaps your > way of thinking, but they're not _really_ needed. And fitting into a coding style or a way of thinking isn't important, apparently! > If they're not *really* needed, should the be present in the > language proper? From that point of view, nobody *really* needs anything more than assembler. But notation is important: it affects the way we think about things and restricts what we can think about. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-05 10:21 -0800 |
| Message-ID | <7xy5f2vcyx.fsf@ruckus.brouhaha.com> |
| In reply to | #19462 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > I think closures are more C++ than C. Closures are really just about > notational convenience and expressiveness. There is nothing that you > can't write in C, but it might be a lot of C. C++11 has anonymous functions but they're not Scheme-like closures from what I can tell. Closures seem much less useful without garbage collection. Their point is that any variables that are bound in the surrounding context but free in the nested function, have their values copied into the closure when the closure is created, and the closure (with those values) stays around after the surrounding function has returned. Languages without first-class functions usually do this sort of thing with OOP or similar.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web