Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40779 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-07-24 12:19 -0400 |
| Last post | 2015-11-30 02:55 -0500 |
| Articles | 18 on this page of 178 — 30 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-24 10:32 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-25 01:28 -0700
Re: Which scripting for embedded automation? josv@planet.nl - 2015-07-25 07:15 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-25 10:26 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 00:42 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:07 -1000
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 01:44 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 05:57 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:02 +0100
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 08:41 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 08:36 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:20 -0400
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-26 04:01 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 18:53 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 11:18 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 20:25 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:36 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 01:12 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 10:02 +0000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 13:44 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 15:15 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 04:52 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:01 +0100
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:33 +0100
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:34 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 10:47 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:12 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 11:24 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:41 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 12:49 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 14:38 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 12:02 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:11 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 13:50 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 08:56 -0700
Re: Which scripting for embedded automation? Doug Hoffman <glidedog@gmail.com> - 2015-08-09 09:32 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-09 16:30 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-09 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:53 +0000
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-10 08:28 -1000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-11 15:17 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 14:14 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 16:29 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 01:44 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 11:09 +0100
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-08-11 11:03 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 08:08 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 17:21 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-11 22:05 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:50 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-12 18:02 +0100
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:51 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-12 10:18 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-13 10:37 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-14 12:13 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-14 21:30 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 16:57 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 00:12 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:44 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 00:06 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:13 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-18 09:02 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 00:02 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-18 14:20 -1000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 03:12 +0200
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-14 13:09 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:43 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 17:10 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:16 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:31 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:39 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 13:43 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-13 10:55 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 12:06 -0700
Re: Which scripting for embedded automation? Alex McDonald <blog@rivadpm.com> - 2015-08-14 18:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-15 19:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-23 16:59 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 15:52 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:43 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:04 -0700
Re: Which scripting for embedded automation? Julian Fondren <ayrnieu@gmail.com> - 2015-07-26 13:49 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 14:56 -1000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-26 14:20 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 17:29 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-08-10 22:52 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 17:11 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 22:38 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 15:07 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 21:26 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 16:49 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 01:30 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:19 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:31 -0400
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 16:44 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 20:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 18:57 +0200
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:03 -1000
Re: Which scripting for embedded automation? stephen@mpeforth.com (Stephen Pelc) - 2015-07-27 09:12 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:02 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-27 14:14 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:17 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:33 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:05 -1000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:47 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:52 -0400
Re: Which scripting for embedded automation? awegel@arcor.de (Alexander Wegel) - 2015-07-29 12:24 +0200
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 19:22 +0200
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:46 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:47 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:22 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-29 00:48 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:15 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-31 11:34 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 09:21 +0000
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-29 13:27 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-29 18:53 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:40 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:15 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-30 21:51 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:32 +0000
Re: Which scripting for embedded automation? David Thompson <dave.thompson2@verizon.net> - 2015-08-16 02:31 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:53 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 17:50 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:14 +0000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:28 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:24 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 17:09 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-30 02:01 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 17:58 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:26 -0400
Re: Which scripting for embedded automation? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 00:06 -0700
Re: Which scripting for embedded automation? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-07-31 13:35 +0300
Re: Which scripting for embedded automation? Mikael Nordman <oh2aun@gmail.com> - 2015-08-01 01:12 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-31 15:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:03 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:29 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:58 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 15:43 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 18:24 +0100
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 20:09 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:07 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:22 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:47 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:59 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:13 +0000
Re: Which scripting for embedded automation? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:29 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 12:02 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 15:57 +0100
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:32 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 16:35 -0700
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-08-01 22:50 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-01 20:06 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-26 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:32 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 01:46 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:54 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 22:42 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 02:38 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:28 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 05:41 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:49 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-28 14:14 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-28 07:38 -1000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 13:37 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-08-01 22:50 -0400 |
| Message-ID | <mpk0i4$peu$1@speranza.aioe.org> |
| In reply to | #40924 |
On 29/07/2015 7:35 PM, hughaguilar96@gmail.com wrote: > The reason why I said the 6808 was designed for C, is that it had > indexed-addressing into thereturn-stack, so a C-style local frame > could be on the return-stack. The 6808 lacked a base-pointer (like > the BP on the 8086) though. This means that, when building the > local-frame for a sub-function about to be called, you have to push > the values to the return-stack and then adjust the offset to the > local-frame of the calling function. This is somewhat awkward, but > it does work. The compiler has to know at compile-time how many > parameters are being passed into a function so the function can > have code to clean up the return-stack at its termination --- this > means you can't have variable number of arguments (such as PRINTF > etc.) --- maybe this is what you mean when you say that the 6808 > lacked the minimal requirements to support C, but this is not really > necessary in a micro-controller. The 6808 C implementations most stay away from stack frames to produce shorter faster code preferring do compiled stack and you can have variable number of arguments. In embedded systems recursive functions are avoided (Its a reliability issue) and tail end recursion has essentially eliminated stack frames use in most small processors. > All in all, the 6808 was designedspecifically to support C, and > it represents the smallest possibleprocessor that can support C. Except RS08, Senix SX, Microchip PIC12, M6805, National COP8 and 8051 all of which are smaller with multiple C compilers. As I said earlier I worked on the 6808 ISA and your speculation is not correct on its design goals. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-01 20:06 -0700 |
| Message-ID | <6e181634-3e2b-417e-a631-eb1847ede93d@googlegroups.com> |
| In reply to | #41057 |
On Saturday, August 1, 2015 at 7:50:47 PM UTC-7, Walter Banks wrote: > On 29/07/2015 7:35 PM, hughaguilar96@gmail.com wrote: > > > The reason why I said the 6808 was designed for C, is that it had > > indexed-addressing into thereturn-stack, so a C-style local frame > > could be on the return-stack. The 6808 lacked a base-pointer (like > > the BP on the 8086) though. This means that, when building the > > local-frame for a sub-function about to be called, you have to push > > the values to the return-stack and then adjust the offset to the > > local-frame of the calling function. This is somewhat awkward, but > > it does work. The compiler has to know at compile-time how many > > parameters are being passed into a function so the function can > > have code to clean up the return-stack at its termination --- this > > means you can't have variable number of arguments (such as PRINTF > > etc.) --- maybe this is what you mean when you say that the 6808 > > lacked the minimal requirements to support C, but this is not really > > necessary in a micro-controller. > > The 6808 C implementations most stay away from stack frames to produce > shorter faster code preferring do compiled stack and you can have > variable number of arguments. In embedded systems recursive functions > are avoided (Its a reliability issue) and tail end recursion has > essentially eliminated stack frames use in most small processors. I don't know what you mean when you say: "preferring to do compiled stack." I am thinking in terms of a local-frame on the return stack --- you seem to be describing something else, that I don't know about. > > All in all, the 6808 was designedspecifically to support C, and > > it represents the smallest possibleprocessor that can support C. > > Except RS08, Senix SX, Microchip PIC12, M6805, National COP8 and 8051 > all of which are smaller with multiple C compilers. As I said earlier > I worked on the 6808 ISA and your speculation is not correct on its > design goals. Of your list, I only know PIC12 and 8051 (afaik, RS08 is pretty much the same as the 6808 except with less memory). The 8051 C compilers had all the local variables in absolute addresses in the byte-addressable memory. With each call to a function, they had to be moved to the stack in external memory so their memory addresses could be used by the called function, then after the called function returned they were copied back in again. This is not standard C, because you can't pass the address of a local variable into a called function. Also, it is inefficient. The 8051 was inefficient for both C and Forth --- the 8051 was really intended to be programmed in assembly-language and every function would use its own global variables --- it was not designed for any language, or to be used for any application that was so big that all the functions couldn't just have their own static variables in byte-addressable memory. I programmed the PIC16 in assembly-language that is a bigger version of the PIC12 --- it was really intended to be programmed in assembly-language rather than any language. Those were the bad old days --- I don't think anybody really misses the 8051 or the PIC16. Anyway, I don't want to get into an argument with you over the 6808 --- nobody misses that one either.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-07-26 22:56 -0700 |
| Message-ID | <6db7c000-6ab2-417f-affa-9dddcb31f8ca@googlegroups.com> |
| In reply to | #40808 |
On Monday, July 27, 2015 at 12:11:11 AM UTC+3, Rod Pemberton wrote: > On Sun, 26 Jul 2015 13:53:14 -0400, Alex McDonald <> wrote: > > on 26/07/2015 12:01:26, glidedog wrote: > ... > > >> Mark's lament is understandable. Forth doesn't even have a built-in > >> cell-sized-element array wordset. > > > > The definition of a 1 dimensional array is trivial; perhaps that's why. > > > > : 1dim create cells allot does> swap cells + ; > > > > 10 1dim myarray > > 10 0 myarray ! > > 20 1 myarray ! > > 0 myarray @ 1 myarray @ + . > > > > Okay, don't blow a fuse for me butting in without reading most of this, but ... > > How is that on factoring? > > Shouldn't there be a separate word to do array indexing so the indexing > functionality can be re-used? Then, it would be factored, correct? ... > > E.g., > > : [] swap cells + ; > : 1dim create cells allot ; > > 10 1dim myarray > 10 0 myarray [] ! > 20 1 myarray [] ! > 0 myarray [] @ 1 myarray [] @ + . > > Isn't the non-factoring of Forth words the core issue Mark is getting at? > > Or, perhaps, he is pointing out that everyone has forgotten Forth has or > had specialty words like +! and TOGGLE . > > If Forth has or had *those* words, why shouldn't Forth have a word to index > into arrays? > > > Rod Pemberton > > -- > Scientists now say we'll experience a mini-ice in 2030. > So, I guess we need more global warming today ... Hi! For factoring I would go more deeper than that and I'll propose "indexing" operator as '*/' is "scaling" operator: : *+ ( a b c -- a+b*c ;"indexer" should be native code) * + ; By commutativity of '*' we have flexibility for order of stack parameters. So when in interactive mode do a 'see' a observe something like: .. Alpha /BOX 5 *+ ... or .. Alpha 5 /BOX *+ ... I would know that 'Alpha' is an array of Boxes. If I want know size of a Box I would do '/BOX .' If I want to write less I would do something equivalent with: HERE 64 /BOX * allot /BOX 2CONSTANT Alpha and use: Alpha 5 *+ Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 07:32 +0000 |
| Message-ID | <2015Jul27.093222@mips.complang.tuwien.ac.at> |
| In reply to | #40817 |
humptydumpty <ouatubi@gmail.com> writes:
>For factoring I would go more deeper than that
>and I'll propose "indexing" operator as '*/' is "scaling" operator:
>
>: *+ ( a b c -- a+b*c ;"indexer" should be native code) * + ;
Following the stack effect of */, a word with this stack effect should
be called +*, or a word with this name should be defined as:
: *+ ( a b c -- a*b+c ) >r * r> + ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-07-27 01:46 -0700 |
| Message-ID | <2f5fb4da-3699-4d13-a169-59c0eb5218d0@googlegroups.com> |
| In reply to | #40818 |
On Monday, July 27, 2015 at 10:35:56 AM UTC+3, Anton Ertl wrote:
> humptydumpty <> writes:
> >For factoring I would go more deeper than that
> >and I'll propose "indexing" operator as '*/' is "scaling" operator:
> >
> >: *+ ( a b c -- a+b*c ;"indexer" should be native code) * + ;
>
> Following the stack effect of */, a word with this stack effect should
> be called +*, or a word with this name should be defined as:
>
> : *+ ( a b c -- a*b+c ) >r * r> + ;
>
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: http://www.forth200x.org/forth200x.html
> EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
Hi!
In time, I learned to not fight the stack, but follow it.
^^^^
I know that sounds like old jokes from "Tao of programming" .. :)
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 07:54 +0000 |
| Message-ID | <2015Jul27.095409@mips.complang.tuwien.ac.at> |
| In reply to | #40808 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>If Forth has or had *those* words, why shouldn't Forth have a word to index
>into arrays?
There is a commonly-used word
: th cells + ;
But this word is limited to cells. So we would also need
: fth floats + ;
and more for other types. Not sure if that really helps, although I
have occasionally used TH. Maybe CELLS, FLOATS etc. are the factors
you are looking for, and the array access words that are supposedly
lacking. I so, we should also have DOUBLES (or maybe 2CELLS), and, if
we define complex numbers, COMPLEXS; and for additional types that we
might want to put in array, similar words.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-07-27 22:42 -0700 |
| Message-ID | <48df0186-75fb-4cb5-84dd-4dd6fa3f4127@googlegroups.com> |
| In reply to | #40802 |
On Sunday, July 26, 2015 at 2:01:26 PM UTC+3, glid...@gmail.com wrote: > On 7/25/15 10:20 AM, rickman wrote: > > On 7/25/2015 4:28 AM, Mark Wills wrote: > >> On Saturday, 25 July 2015 01:52:11 UTC+1, rickman wrote: > >>> On 7/24/2015 8:00 PM, Don Y wrote: > >>>> On 7/24/2015 4:06 PM, WJ wrote: > >>>> > >>>>> It's obvious that the reason that he is recommending Forth > >>>>> over all other languages is that he knows no language that is > >>>>> higher-level than Forth. And he finds it too difficult to > >>>>> learn another language. > >>>>> > >>>>> If a hammer is the only tool that you have, then you use a > >>>>> hammer for everything. > >>>>> > >>>>> How would these tasks be done with a hammer? > >>>>> > >>>>> Using Gauche Scheme: > >>>>> > >>>>> Write a function that accepts a vector (1-dimensional array) > >>>>> of 16-bit numbers and replaces each number with its > >>>>> difference from the average. > >>>>> > >>>>> (use gauche.uvector) (use gauche.collection) > >>>>> > >>>>> (define (relativize vec) (let ((avg (round->exact (/ (fold + > >>>>> 0 vec) (s16vector-length vec))))) (s16vector-sub! vec avg))) > >>>>> > >>>>> (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) (relativize > >>>>> my-vec) my-vec ===> #s16(-4 -3 -2 -1 0 1 2 3 4 5) > >>>>> > >>>>> > >>>>> Take a string that contains numbers separated by semicolons > >>>>> or commas and convert it to a list of numbers. > >>>>> > >>>>> (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > >>>>> ===> (2 3.14 5.8 9) > >>>> > >>>> What role would these have in the scripting of an automation > >>>> system? IME, tasks in that domain tend to be more procedural > >>>> oriented. > >>> > >>> WJ is an odd sort. You won't find that he is much of a > >>> conversationalist. Rather he communicates in terms of code for > >>> any manner of interesting, even if irrelevant, examples. > >>> > >>> Just one of the many odd birds flitting about in the Forth > >>> newsgroup. > >>> > >>> -- > >>> > >>> Rick > >> > >> He may be an odd sort, but his point is spot on. For *embedded > >> scripting* I wouldn't go near Forth in a bazillion years. Okay, if > >> the *embedded* machine I was using had like, 1K of RAM, then yes, > >> Forth. Otherwise, no way. > >> > >> Look, if you are doing scripting, then you are doing things like: > >> > >> * Pinging IP addresses (e.g. a gateway) and changing routing tables > >> on the fly depending on whether a particular interface is up or > >> not. * Reading through log files, looking for the certain > >> occurrence of strings (error codes/strings, other filenames etc.) * > >> Deleting log or error files * Moving log or error files * Rotating > >> log or error files depending on their age * Searching for files of > >> a given type, or date range, and moving them, or zipping them, or > >> deleting them. > >> > >> Forth has *no* standard way to do any of these things. You'd even > >> have to write your own string array handler FFS. Forget enumerating > >> a disk directory, getting a list of all the files in a structure, > >> with their creation dates, modification dates, filtering by type, > >> sorting by date, looking for duplicate file names (so that you can > >> delete the older versions) etc. > >> > >> Are you kidding me? > >> > >> You want Perl, PHP, and Python. Any of those will take you > >> everywhere you want to go. > >> > >> Forth is next to useless for this sort of thing, unless you have a > >> rack of libraries that you have personally built up over the years. > >> Because, you know, this is Forth, right, and we don't use each > >> other's libraries in the Forth world, because everyone else's code > >> sucks, right? We can *all* do *much* better jobs by ourselves, > >> re-inventing the wheel over and over and over again. > >> > >> Using Forth for this kind of thing would be like setting out to > >> build a house with a hammer and a screwdriver. Someone says "hey, > >> where's the cement mixer?" and you hold up the hammer and the > >> screwdriver and say "we're gonna build our own! It's gonna be the > >> best cement mixer EVER!" > >> > >> Don't get me started! I don't even have a cat that I can kick ;-) > >> > >> Next-door neighbour... he has a cat... > > > > BTW, you only replied to the forth group. If you feel so strongly > > that Forth is such a bad language, why are you here? > > Mark's lament is understandable. Forth doesn't even have a built-in > cell-sized-element array wordset. I think that sort of thing is where > he's coming from. But that's Forth. I long ago made peace with this > aspect and accept Forth as it is and for what it is (and isn't). > > -Doug Hi! As no one said it, I say it: Maybe is not needed so badly. For traversing an array (or parts) would suffice ( HI-limit start-addr ) 'DO ... +LOOP', or 'BEGIN ...' loops & '@+','!+'-like kind of operators. From some comments here, it looks as Forth should give away his freedom to make a room for only one boring way to do things. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-28 02:38 -0700 |
| Message-ID | <b8094572-66c7-4c78-ac9b-317c2d71a6da@googlegroups.com> |
| In reply to | #40861 |
On 7/28/15 1:42 AM, humptydumpty wrote: > On Sunday, July 26, 2015 at 2:01:26 PM UTC+3, glid...@gmail.com > wrote: >> Mark's lament is understandable. Forth doesn't even have a >> built-in cell-sized-element array wordset. I think that sort of >> thing is where he's coming from. But that's Forth. I long ago >> made peace with this aspect and accept Forth as it is and for what >> it is (and isn't). > Maybe is not needed so badly. For traversing an array (or parts) > would suffice ( HI-limit start-addr ) 'DO ... +LOOP', or 'BEGIN ...' > loops & '@+','!+'-like kind of operators. > > From some comments here, it looks as Forth should give away his > freedom to make a room for only one boring way to do things. No. If one (boring to you) way to do something is provided there is absolutely *no* freedom taken to do it any other way one wants. The only really valid problem would be wasted kernel space in resource constrained environments if that way were never used, however big a problem that is. And then only if it were made CORE. -Doug
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-07-28 05:28 -0700 |
| Message-ID | <f6ab88a0-7b58-41fa-ba16-c19f1a3a777f@googlegroups.com> |
| In reply to | #40866 |
On Tuesday, July 28, 2015 at 12:38:21 PM UTC+3, glid...@gmail.com wrote: > On 7/28/15 1:42 AM, humptydumpty wrote: > > On Sunday, July 26, 2015 at 2:01:26 PM UTC+3, glid...@gmail.com > > wrote: > > >> Mark's lament is understandable. Forth doesn't even have a > >> built-in cell-sized-element array wordset. I think that sort of > >> thing is where he's coming from. But that's Forth. I long ago > >> made peace with this aspect and accept Forth as it is and for what > >> it is (and isn't). > > > Maybe is not needed so badly. For traversing an array (or parts) > > would suffice ( HI-limit start-addr ) 'DO ... +LOOP', or 'BEGIN ...' > > loops & '@+','!+'-like kind of operators. > > > > From some comments here, it looks as Forth should give away his > > freedom to make a room for only one boring way to do things. > > No. If one (boring to you) way to do something is provided there is > absolutely *no* freedom taken to do it any other way one wants. > The only really valid problem would be wasted kernel space in resource > constrained environments if that way were never used, however big a > problem that is. And then only if it were made CORE. > > -Doug Hi! Sorry, I think it was a little misunderstanding from my side, sometimes I've got tired to hear over and over again something like: "Oh my dear, there is no native support for arrays, what a damned language!" Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-28 05:41 -0700 |
| Message-ID | <91208083-6227-4d0e-a787-d67ebd21855a@googlegroups.com> |
| In reply to | #40870 |
On 7/28/15 8:28 AM, humptydumpty wrote: > Sorry, I think it was a little misunderstanding from my side, > sometimes I've got tired to hear over and over again something like: > "Oh my dear, there is no native support for arrays, what a damned language!" Feel free to killfile me if that makes you feel better. Btw I don't use profanity. -Doug
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-07-28 05:49 -0700 |
| Message-ID | <ab030127-d77b-40b9-a997-c5bc33c5dc89@googlegroups.com> |
| In reply to | #40871 |
On Tuesday, July 28, 2015 at 3:41:10 PM UTC+3, glid...@gmail.com wrote: > On 7/28/15 8:28 AM, humptydumpty wrote: > > Sorry, I think it was a little misunderstanding from my side, > > sometimes I've got tired to hear over and over again something like: > > "Oh my dear, there is no native support for arrays, what a damned language!" > > Feel free to killfile me if that makes you feel better. Btw I don't use profanity. > > -Doug No way to killfile you! Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-28 14:14 -0400 |
| Message-ID | <mp8gnu$oqu$2@dont-email.me> |
| In reply to | #40872 |
On 7/28/2015 8:49 AM, humptydumpty wrote: > On Tuesday, July 28, 2015 at 3:41:10 PM UTC+3, glid...@gmail.com wrote: >> On 7/28/15 8:28 AM, humptydumpty wrote: >>> Sorry, I think it was a little misunderstanding from my side, >>> sometimes I've got tired to hear over and over again something like: >>> "Oh my dear, there is no native support for arrays, what a damned language!" >> >> Feel free to killfile me if that makes you feel better. Btw I don't use profanity. >> >> -Doug > > No way to killfile you! Some days I think newsgroups would be better if everyone were automatically killfiled in every newsreader. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-28 07:38 -1000 |
| Message-ID | <edKdneq4bouOIyrInZ2dnUU7-SOdnZ2d@supernews.com> |
| In reply to | #40866 |
On 7/27/15 11:38 PM, glidedog@gmail.com wrote: > On 7/28/15 1:42 AM, humptydumpty wrote: >> On Sunday, July 26, 2015 at 2:01:26 PM UTC+3, glid...@gmail.com >> wrote: > >>> Mark's lament is understandable. Forth doesn't even have a >>> built-in cell-sized-element array wordset. I think that sort of >>> thing is where he's coming from. But that's Forth. I long ago >>> made peace with this aspect and accept Forth as it is and for what >>> it is (and isn't). > >> Maybe is not needed so badly. For traversing an array (or parts) >> would suffice ( HI-limit start-addr ) 'DO ... +LOOP', or 'BEGIN ...' >> loops & '@+','!+'-like kind of operators. >> >> From some comments here, it looks as Forth should give away his >> freedom to make a room for only one boring way to do things. > > No. If one (boring to you) way to do something is provided there is > absolutely *no* freedom taken to do it any other way one wants. > The only really valid problem would be wasted kernel space in resource > constrained environments if that way were never used, however big a > problem that is. And then only if it were made CORE. May I repeat once again, the fact that a word is in the CORE wordset doesn't mean it has to be resident in a kernel. It just has to be available in some form (even documentation, to be typed in) to users of a Standard System. If you're programming on a resource-constrained system, you are perfectly free to remove anything you don't think you need from the run-time environment. 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 | glidedog@gmail.com |
|---|---|
| Date | 2015-07-28 13:37 -0700 |
| Message-ID | <3fd44df6-7e4f-45fe-948d-f0c3b9ca2755@googlegroups.com> |
| In reply to | #40877 |
On 7/28/15 1:38 PM, Elizabeth D. Rather wrote:> On 7/27/15 11:38 PM, glidedog@gmail.com wrote: >> On 7/28/15 1:42 AM, humptydumpty wrote: >>> On Sunday, July 26, 2015 at 2:01:26 PM UTC+3, glid...@gmail.com >>> wrote: >> >>>> Mark's lament is understandable. Forth doesn't even have a >>>> built-in cell-sized-element array wordset. I think that sort of >>>> thing is where he's coming from. But that's Forth. I long ago >>>> made peace with this aspect and accept Forth as it is and for what >>>> it is (and isn't). >> >>> Maybe is not needed so badly. For traversing an array (or parts) >>> would suffice ( HI-limit start-addr ) 'DO ... +LOOP', or 'BEGIN ...' >>> loops & '@+','!+'-like kind of operators. >>> >>> From some comments here, it looks as Forth should give away his >>> freedom to make a room for only one boring way to do things. >> >> No. If one (boring to you) way to do something is provided there is >> absolutely *no* freedom taken to do it any other way one wants. >> The only really valid problem would be wasted kernel space in resource >> constrained environments if that way were never used, however big a >> problem that is. And then only if it were made CORE. > > May I repeat once again, the fact that a word is in the CORE wordset > doesn't mean it has to be resident in a kernel. It just has to be > available in some form (even documentation, to be typed in) to users of > a Standard System. If you're programming on a resource-constrained > system, you are perfectly free to remove anything you don't think you > need from the run-time environment. Thanks for that, Elizabeth. -Doug
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-11-28 18:06 +0000 |
| Message-ID | <n3cqg1$vt4$1@dont-email.me> |
| In reply to | #40789 |
WJ wrote: > Paul Rubin wrote: > > > > Otherwise Forth can be used to advantage in the same environments > > > where you would use C, Python or any others. > > > > I didn't say anything about C and I'd consider it comparable to Forth in > > most regards. C would IMHO be a poor choice of scripting language in > > this situation too. > > > > Have you actually used Python? It's not anything like C or Forth. > > Lumping Python with C seems to miss the distinction. If you haven't > > actually used both, then making comparisons between them isn't > > convincing. > > It's obvious that the reason that he is recommending Forth > over all other languages is that he knows no language that > is higher-level than Forth. And he finds it too difficult > to learn another language. > > If a hammer is the only tool that you have, then you use > a hammer for everything. > > How would these tasks be done with a hammer? > > Using Gauche Scheme: > > Write a function that accepts a vector (1-dimensional array) of > 16-bit numbers and replaces each number with its difference > from the average. > > (use gauche.uvector) > (use gauche.collection) > > (define (relativize vec) > (let ((avg (round->exact (/ (fold + 0 vec) (s16vector-length vec))))) > (s16vector-sub! vec avg))) > > (define my-vec (s16vector 0 1 2 3 4 5 6 7 8 9)) > (relativize my-vec) > my-vec > ===> > #s16(-4 -3 -2 -1 0 1 2 3 4 5) > > > Take a string that contains numbers separated by semicolons or > commas and convert it to a list of numbers. > > (map string->number (string-split "2,3.14;5.8,9" #/[,;]/)) > ===> > (2 3.14 5.8 9) Ocaml: #load "str.cma";; List.map float_of_string (Str.split (Str.regexp "[,;]") "2,3.14;5.8,9");; ===> [2.; 3.14; 5.8; 9.]
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-29 02:45 -0500 |
| Message-ID | <n3ea9n$k50$1@dont-email.me> |
| In reply to | #40782 |
On 7/24/2015 1:15 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > [Ok, replying to your crosspost even though my own earlier post was only > on comp.arch.embedded where the original question was. The question > regards scripting home automation stuff on an embedded Linux system]. > >>> Forth is likely to be too low level for this sort of programming. >>> It's virtue is being able to run in very small memory space, like >>> under 10K of code space and a few hundred ram bytes in an MCU. >> I find your analysis of Forth to be very naive. Much the same as >> other languages like C, Forth provides a basic capability with more >> advanced capabilities provided through libraries. > > Sure, I'd consider C to also be low level though. I'd have to add that > Forth doesn't have nearly as many available libraries, because of the > smaller userbase, but I think partly from a minimalist "do everything > yourself" spirit in Forth culture. > >> Suggesting that Forth is only useful where the entire development >> system needs to reside in 10 KB of code is a red herring. > > I didn't mean to suggest a 10K maximum. I meant Forth had the > capability of running in such small space and that this is IMHO a big > achievement and advantage that it has, but it dictated a lot of Forth's > design decisions. Historically Forth was most successful in the era of > 16-bit systems with up to 64k ram, or maybe on MSDOS PC's with up to > 640k. Once you have tens of MB available the tradeoffs in scripting > become a lot different. > > Other Forth advantages include pauseless operation (necessary for > real-time programs), higher cpu efficiency than Python even in simple > interpreters, and very high efficiency (comparable to C) if you use an > optimizing compiler. But, in the context of scripting, these are > usually not important. Python burns more machine resources, but in > return it takes care of a lot of issues for you that you'd have to spend > your own time looking after in Forth or C. > >> Otherwise Forth can be used to advantage in the same environments >> where you would use C, Python or any others. > > I didn't say anything about C and I'd consider it comparable to Forth in > most regards. C would IMHO be a poor choice of scripting language in > this situation too. > > Have you actually used Python? It's not anything like C or Forth. > Lumping Python with C seems to miss the distinction. If you haven't > actually used both, then making comparisons between them isn't > convincing. > >> It typically comes with exactly the sort of capabilities needed for >> this project. A parser is built in with full capability of being used >> in the application and most Forths running under an OS support >> networking. > > If the OP has control over the network protocol then using the Forth > parser can be a simple and efficient solution, especially if the network > devices are all trusted. If there are devices speaking protocols like > XML (some home automation stuff is like that) then Forth starts to be > painful. I don't know if a Forth TLS stack even exists. > >> Referring to Forth as being "like assembler" just shows how little you >> understand the language and appreciate its features. > > I understand Forth pretty well at a technical level, though I'm not a > very fluent user in terms of being used to the idioms it takes to use it > productively. We have had similar discussions before. You criticize my possible lack of experience with Python, then acknowledge your lack of experience with Forth. So if you aren't really fluent with Forth, why do you feel you are in a position to criticize it or even discuss it? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-29 23:02 -0800 |
| Message-ID | <871tb8dl78.fsf@jester.gateway.pace.com> |
| In reply to | #43928 |
rickman <gnuarm@gmail.com> writes: > We have had similar discussions before. You criticize my possible > lack of experience with Python, then acknowledge your lack of > experience with Forth. So if you aren't really fluent with Forth, why > do you feel you are in a position to criticize it or even discuss it? No idea what possessed you to necro a 4 month old post but I've written a KLOC or so of Forth and studied the implementation techniques closely. That's not enough to have the instincts of an expert, but it's way beyond zero experience or newbie range. Plus I've read discussions between experts here on CLF and see the kind of stuff that they find difficult. So I have a reasonable sense of Forth's strong and weak points, it seems to me. Anyway, do you really want a scripting extension that requires an expert to be able to use it? You might give the MicroPython live demo a try: http://micropython.org/live/ (Hmm, it's not working right now, but it's really cool when it does). MicroPython needs around 100k of code space and 10k of ram from what I understand. That's less tiny than Forth can be, but still within range of cheap midrange MCU's including the 2 dollar ESP8266 boards. If not, NodeMCU definitely fits in those things (eLua instead of Python) and lots of them are shipping with it pre-installed.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-30 02:55 -0500 |
| Message-ID | <n3gvc8$9bq$1@dont-email.me> |
| In reply to | #43957 |
On 11/30/2015 2:02 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> We have had similar discussions before. You criticize my possible >> lack of experience with Python, then acknowledge your lack of >> experience with Forth. So if you aren't really fluent with Forth, why >> do you feel you are in a position to criticize it or even discuss it? > > No idea what possessed you to necro a 4 month old post but I've written > a KLOC or so of Forth and studied the implementation techniques closely. > That's not enough to have the instincts of an expert, but it's way > beyond zero experience or newbie range. Plus I've read discussions > between experts here on CLF and see the kind of stuff that they find > difficult. So I have a reasonable sense of Forth's strong and weak > points, it seems to me. Anyway, do you really want a scripting > extension that requires an expert to be able to use it? I think your 1 KLOC has given you a false sense of familiarity with the language. What sorts of things do the experts here claim to have difficulty with in Forth? -- Rick
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.forth
csiph-web