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 | 20 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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-31 00:06 -0700 |
| Message-ID | <eb7e20dc-1c4e-4ed8-a0f6-49a5ba5bf28c@googlegroups.com> |
| In reply to | #40990 |
vineri, 31 iulie 2015, 04:26:11 UTC+3, Rod Pemberton a scris: > On Wed, 29 Jul 2015 20:58:51 -0400, <hughaguilar96@gmail.com> wrote: > > > On Wednesday, July 29, 2015 at 5:01:27 PM UTC-7, Bernd Linsel wrote: > > >> ...the simpler approach is just separating code and data. When > >> doing embedded stuff in Flash EEPROM, its almost always required anyway. > > > > The standard should have required that code and data be separate, > > and provide separate versions of HERE --- such as CHERE and DHERE > > --- this would also allow code to be compiled without clashing with > > the data being comma'd. > > OMG! You just _don't_ see it do you? ... > I.e., you're recreating C again. > > Hey, let me know when you've finished with your C language > implementation. Sorry, I meant with your Forth clone of > C implementation ... > > > Rod Pemberton > > > -- > Scientists now say we'll experience a mini-ice in 2030. > So, I guess we need more global warming today ... The forth is esspecially suited for embedded constraint systems, isn't it? This is claimed all over the place. Still, it has a single HERE. Tell me how do you implement the forth system on: AVR, PIC, 8051, Cortex-m, etc single-chip microcontrollers? Hint: a ram-only microcontroller is not invented yet.
[toc] | [prev] | [next] | [standalone]
| From | Hannu Vuolasaho <vuokkosetae@gmail.com> |
|---|---|
| Date | 2015-07-31 13:35 +0300 |
| Message-ID | <mpfivv$i80$1@dont-email.me> |
| In reply to | #40998 |
On 31.07.2015 10:06, Raimond Dragomir wrote: > This is claimed all over the place. Still, it has a single HERE. Tell me > how do you implement the forth system on: AVR, PIC, 8051, Cortex-m, etc single-chip microcontrollers? At least Amforth (AVR8) has !i to store flash, !e to store eeprom and EHERE is also found. It is also documented how these differences work. Another option would be put all different spaces after each other in same address space which I believe is done in Flashforth. > > Hint: a ram-only microcontroller is not invented yet. That is possible with serial EEPROM and FPGA and memory module. First write contest binaryblop from EEPROM to FPGA and FPGA populates memory and then MCU on FPGA starts executing from RAM. Best regards, Hannu Vuolasaho
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@gmail.com> |
|---|---|
| Date | 2015-08-01 01:12 -0700 |
| Message-ID | <2f5066c9-185f-4517-8a51-f484199df5dc@googlegroups.com> |
| In reply to | #41006 |
On Friday, July 31, 2015 at 1:36:14 PM UTC+3, Hannu Vuolasaho wrote: > On 31.07.2015 10:06, Raimond Dragomir wrote: > > > This is claimed all over the place. Still, it has a single HERE. Tell me > > how do you implement the forth system on: AVR, PIC, 8051, Cortex-m, etc single-chip microcontrollers? > > At least Amforth (AVR8) has !i to store flash, !e to store eeprom and > EHERE is also found. It is also documented how these differences work. > > Another option would be put all different spaces after each other in > same address space which I believe is done in Flashforth. > FlashForth has three data allocation pointers(DP), one for each memory type. So RAM HERE EEPROM HERE FLASH HERE all return different addresses. @ ! maps the memories into a 64 kB memory space, so all words can work transparently with flash, eeprom and ram. BR Mikael
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-31 15:05 -0700 |
| Message-ID | <d762ec1c-4e7b-4b14-9d8b-80e23aeff2d9@googlegroups.com> |
| In reply to | #40998 |
On Friday, July 31, 2015 at 12:06:30 AM UTC-7, Raimond Dragomir wrote: > The forth is esspecially suited for embedded constraint systems, isn't it? > This is claimed all over the place. Still, it has a single HERE. Tell me > how do you implement the forth system on: AVR, PIC, 8051, Cortex-m, etc single-chip microcontrollers? > > Hint: a ram-only microcontroller is not invented yet. In the old days (1980s and very early 1990s), micro-controllers had only RAM and EPROM. So, the Forth system was in EPROM and it compiled the application program into RAM. This was effectively a "ram-only micro-controller" --- after the program was developed, the image of the application program got burned into EPROM along with the Forth compiler for the product that was shipped to the customer --- when the program was run, the image of the application program had to be copied from the EPROM into the RAM and run in RAM because it had code and data mixed together. The "micro-controller" of the 1980s was essentially a personal-computer --- it had an EPROM rather than a disk-drive, and it had no keyboard or video, but otherwise was pretty much the same (people actually used 80186 processors as micro-controllers, and they had the BIOS and MS-DOS in EPROM along with their application program, and the application program got copied into RAM where it ran). ANS-Forth was designed to be used in such a "ram-only micro-controller." This was already obsolete in 1994 however. I was well aware of the need to separate code and data when I wrote MFX in 1994/1995 (the MiniForth was Harvard Architecture). Most micro-controllers of that era had separate code and data memory. Some (AVR and PIC) were Harvard Architecture so this was required. Some (the 8051) were not Harvard Architecture, but did separate code and data so they could have 64KB for each. Now we have Forth-200x coming out that still has code and data mixed together. Nobody under the age of 45 remembers a time when this was state-of-the-art. Even if people do remember the RAM/EPROM micro-controllers such as I described above, nobody cares --- this is ancient history --- ANS-Forth was obsolete before it even came out, and Forth-200x is mandated (by Forth Inc.) to be 100% compatible with ANS-Forth. ANS-Forth has all the appearance of being a toy for retirees to play with --- just a hobby comparable to restoring a classic car from the 1950s --- not something that is used professionally. I'm not saying that hobbies are bad. Mark Wills has his TI99/4a and Michael Barry has his 6502 retro projects --- if people enjoy hobbies, then good for them --- but this is not what the "Forth standard" should be supporting.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-30 12:03 +0000 |
| Message-ID | <2015Jul30.140349@mips.complang.tuwien.ac.at> |
| In reply to | #40928 |
Bernd Linsel <bl1@gmx.com> writes:
>On 29/07/2015 19:09, Anton Ertl wrote:
>I wanted to point out that on the other side, compiled
>and fully optimized native machine code isn't suitable for inlining
>either.
At least you don't get any additional benefits from it.
>You have to keep an intermediate representation, e.g. the
>classic threaded Forth compilation result, otherwise you cannot benefit
>from eliminating junction points entering and leaving the inlined word.
Yes.
> > When you do it by hand, it's pretty easy to get close to optimal
> > performance for these. And when you let GCC at it (as we did in
> > Gforth), it was also pretty easy.
> >
>
>You haven't apparently seen what I've already encountered, what some
>vendors call e.g. 'MIPS R4000 targeting compiler'.
We have used the R4000 (with gcc) in the past, but the machine with
that is now over 20 years old (and the OS is even older), so we don't
normally turn it on. Anyway, the R4000 has a load latency of three
cycles, so e.g., implementing a direct-threaded add would look as follows (for 32-bit cells):
lw w,(ip)
lw tmp,(sp)
addiu ip,ip,4
addiu sp,sp,4
jr w
addu tos,tos,tmp
This would be even good for 4 cycles of latency on a single-issue
CPU like the R4000.
You could even move to load of w into the branch delay slot of the
previous primitive:
lw tmp,(sp)
addiu ip,ip,4
addiu sp,sp,4
addu tos,tos,tmp
jr w
lw w,(ip)
This variant would be less affected by cache misses in threaded-code
access (and more by cache misses in stack accesses, but these should
be vanishingly few). I could not get gcc to produce this code,
however:-).
> > Just because you have code close to data, you don't need to
> > synchronize the caches. So on architectures that require software
> > synchronization, you only synchronize when you first generate the
> > code, but not later. In contrast, on architectures with hardware
> > synchronization, the hardware synchronizes whenever there is a write
> > to (on some hardware even a read from) a cache line followed by a code
> > execution from the same cache line (but different bytes). And that
> > has led to a slowdown by a factor of 8 of bigForth compared to Gforth
> > on one benchmark.
> >
>OK, but the simpler approach is just separating code and data.
It seems that Forth compiler writers found this quite hard (or not
worth the effort), as evidenced by the fact that they still mixed code
and data many years after the problem was first noticed. Separating
code and data is certainly more work than keeping the system as it is
(with mixed code and data in many Forth systems), so it's unclear why
you would claim that it's simpler.
- 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 | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-11-02 16:29 +0100 |
| Message-ID | <n17vdj$11j$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #40893 |
>> An optimizing native compiler gains of course performance of a large >> register set, if you analyze the data flow on the stack and map it on >> the registers, eliminating nearly all DUPs, SWAPs, DROPs etc (with the >> exception that the stack/register mapping must be consistent on all >> junction points). > > Inlining is also important, because otherwise calls and returns are > the most frequent control-flow operation and, more importantly the > most common register allocation boundary, which makes the large > register set and all the sophistication you mention above much less > effective; alternatively, interprocedural register allocation, but > that is harder and probably less effective. Hallo Anton, I wrote a new code generator with register allocation for Mecrisp-Stellaris, and it automatically inlines short definitions, I choosed of up to 10 bytes of opcodes. But inlining breaks register optimisations, it goes back to canonical stack state, inlines the opcodes and continues with canonical state, just as a Branch-with-Link entry would be prepared. How could I solve optimisation across inlined functions within very limited memory ? I think it would need a decompiler which tracks register usage across the code which is to be inlined and recompiles it with the current local register set, possibly removing or adding stack fetches and stores. But unfortunately, the various ARM Thumb instruction bit fields are complicated enough to make this internal decompiler a multi-kilobyte monster in flash. Buffering the source code of the definitions short enough to maybe be inlined later would be an option, but would also require heavy amounts of memory. Is there another solution ? The sizes I speak of are in the order of 32 kb Flash and 4 kb RAM, with the register allocation enabled compiler already consuming 20 kb Flash and about 1 kb of RAM. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-11-02 16:58 +0100 |
| Message-ID | <n18142$1ie$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #43118 |
PS: In Mecrisp-Stellaris, there is no intermediate representation of the code which could be exploited in a way like you described in "Inlining in Gforth: Early Experiences".
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-02 15:43 +0000 |
| Message-ID | <2015Nov2.164357@mips.complang.tuwien.ac.at> |
| In reply to | #43118 |
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
>I wrote a new code generator with register allocation for
>Mecrisp-Stellaris, and it automatically inlines short definitions, I
>choosed of up to 10 bytes of opcodes. But inlining breaks register
>optimisations, it goes back to canonical stack state, inlines the
>opcodes and continues with canonical state, just as a
>Branch-with-Link entry would be prepared. How could I solve
>optimisation across inlined functions within very limited memory ?
[Please use lines of about 72 chars; I wrapped them myself, but
normally that's your job.]
Normally (without memory worries), I would keep the words in memory in
an intermediate format (e.g., as byte code, but with all things
resolved that need to be resolved when text-interpreting), and then
process that when inlining a call. I don't know if that is viable for
your memory constraints, however. But if you save enough memory from
the optimization, to pay for the intermediate code...
A classic Forth approach is manual marking of words as words to be
inlined. Might help in your situation, too.
>Buffering the source code of the definitions short enough to maybe be
>inlined later would be an option, but would also require heavy
>amounts of memory.
Inlining source code can lead to incorrect results (e.g., consider
what happens if the BASE is changed before inlining). Basically, you
need to record the calls to COMPILE, LITERAL etc.
@InProceedings{gregg&ertl04euroforth,
author = {David Gregg and M. Anton Ertl},
title = {Inlining in {Gforth}: Early Experiences},
booktitle = {EuroForth 2004 Conference Proceedings},
pages = {33--40},
year = {2004},
URL = {http://www.complang.tuwien.ac.at/papers/gregg%26ertl04euroforth.ps.gz},
OPTnote = {not refereed},
abstract = {Many optimizations are easier or more effective for
straight-line code (basic blocks). Straight-line
code in Forth is limited mainly by calls and
returns. Inlining eliminates calls and returns,
which in turn makes the basic blocks longer, and
increases the effectiveness of other
optimizations. In this paper we present a first
prototype implementation of inlining for Gforth.}
}
- 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.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-11-02 18:24 +0100 |
| Message-ID | <n1864q$30c$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #43122 |
> [Please use lines of about 72 chars; I wrapped them myself, but > normally that's your job.] Ok, thank you for doing it this time. > Normally (without memory worries), I would keep the words in memory in > an intermediate format (e.g., as byte code, but with all things > resolved that need to be resolved when text-interpreting), and then > process that when inlining a call. I don't know if that is viable for > your memory constraints, however. But if you save enough memory from > the optimization, to pay for the intermediate code... > > A classic Forth approach is manual marking of words as words to be > inlined. Might help in your situation, too. Manual flagging is available in addition to automatic inlining. But I cannot imagine manual flagging helps for using register allocation across the boundaries of the definition and the one to be inlined. I limit myself to automatically inline basic blocks without calls, so no relocation issues or special cases at all. Perhaps I'll find a nice way to generate and store intermediate code along with short definitions AND to save space... >> Buffering the source code of the definitions short enough to maybe be >> inlined later would be an option, but would also require heavy >> amounts of memory. > > Inlining source code can lead to incorrect results (e.g., consider > what happens if the BASE is changed before inlining). Basically, you > need to record the calls to COMPILE, LITERAL etc. Thank you for the hint ! Until I find a new idea, I think there is no known good solution for the memory limits I have to deal with, so I simply keep the canonic-inlined-canonic frame. Best wishes to Vienna, Matthias
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-11-02 20:09 +0100 |
| Message-ID | <n18c88$iel$1@dont-email.me> |
| In reply to | #43129 |
Matthias Koch wrote: > Manual flagging is available in addition to automatic inlining. > But I cannot imagine manual flagging helps for using register allocation > across the boundaries of the definition and the one to be inlined. But it could help you to keep the tokenized form only if it's manually flagged as "inline". You don't need the tokenized form for longer words, for words with loops and so on. If you like, you could have inline-only words which can't be executed, so only the tokens need to be stored. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-03 12:07 +0000 |
| Message-ID | <2015Nov3.130702@mips.complang.tuwien.ac.at> |
| In reply to | #43129 |
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
>> A classic Forth approach is manual marking of words as words to be
>> inlined. Might help in your situation, too.
>
>Manual flagging is available in addition to automatic inlining.
>But I cannot imagine manual flagging helps for using register allocation
>across the boundaries of the definition and the one to be inlined.
As Bernd wrote, you would keep the intermediate representation only
for the inlined words, and keep the executable only for the others.
Another way is to abandon total correctness and have an EVALUATE-based
solution, along the lines of
: inline: ( "name" -- )
\ note that the inlined word must be used in the same context
\ as the definition (BASE, visible words etc.)
create ';' parse string, immediate
does>
string@ evaluate ;
\ with appropriate definitions of STRING, and STRING@
Saves you the space for the code that converts into the intermediate
representation, and you get the register optimization. Because of the
shortcomings, I would use that sparingly, and only as a final
optimization.
- 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.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-11-03 22:22 +0100 |
| Message-ID | <n1b8eq$4pv$1@dont-email.me> |
| In reply to | #43172 |
Anton Ertl wrote: > Matthias Koch <matthias.koch@hot.uni-hannover.de> writes: >>> A classic Forth approach is manual marking of words as words to be >>> inlined. Might help in your situation, too. >> >>Manual flagging is available in addition to automatic inlining. >>But I cannot imagine manual flagging helps for using register allocation >>across the boundaries of the definition and the one to be inlined. > > As Bernd wrote, you would keep the intermediate representation only > for the inlined words, and keep the executable only for the others. > > Another way is to abandon total correctness and have an EVALUATE-based > solution, along the lines of But that's not at all space efficient. Suppose you only want to inline words which don't call other high level words and don't have loops inside, then you can reduce inlineable words to primitives with a byte code plus the literals and forward branches (relative forward branches, can be encoded within one byte with 3 bits for the branch size). A typical Forth word that's worth to inline shouldn't need more than 10 bytes of tokens. You could have a MACRO: definition, which switches to another vocabulary that only contains those words that may be inside a macro, and which only generate the tokenized form. The good thing about this is that the programmer absolutely knows that these words will be inlined. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-04 09:47 +0000 |
| Message-ID | <2015Nov4.104734@mips.complang.tuwien.ac.at> |
| In reply to | #43196 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Another way is to abandon total correctness and have an EVALUATE-based
>> solution, along the lines of
>
>But that's not at all space efficient.
If you only use it to inline the five most-often called short words,
it probably consumes less space than the code needed to deal with the
intermediate representation.
- 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.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-11-04 14:59 +0100 |
| Message-ID | <n1d2sf$sg5$1@dont-email.me> |
| In reply to | #43214 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Another way is to abandon total correctness and have an EVALUATE-based >>> solution, along the lines of >> >>But that's not at all space efficient. > > If you only use it to inline the five most-often called short words, > it probably consumes less space than the code needed to deal with the > intermediate representation. In that case, postpone+immediate would do fine, too. More cumbersome to write, but for just 5 words, it doesn't really matter. I think the idea of inlining is that you try to factor more and you can convert a number of factors into macros. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-04 14:13 +0000 |
| Message-ID | <2015Nov4.151358@mips.complang.tuwien.ac.at> |
| In reply to | #43226 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> If you only use it to inline the five most-often called short words,
>> it probably consumes less space than the code needed to deal with the
>> intermediate representation.
>
>In that case, postpone+immediate would do fine, too. More cumbersome to
>write, but for just 5 words, it doesn't really matter.
Or, to make it less cumbersome to write, add ]] ... [[, e.g.:
: 2dup ]] over over [[ ; immediate
>I think the idea of inlining is that you try to factor more and you can
>convert a number of factors into macros.
One can see it as optimization without any thoughts about how
programmers react to it. Or, as you do, you can consider the
programmer reaction, but I would present it the other way round: Good
inlining lets you factor as appropriate, without needing to worry
about call overhead.
- 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.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-02 20:29 +0000 |
| Message-ID | <5637c7bd$0$23801$e4fe514c@news.xs4all.nl> |
| In reply to | #43122 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
>>I wrote a new code generator with register allocation for
>>Mecrisp-Stellaris, and it automatically inlines short definitions, I
>>choosed of up to 10 bytes of opcodes. But inlining breaks register
>>optimisations, it goes back to canonical stack state, inlines the
>>opcodes and continues with canonical state, just as a
>>Branch-with-Link entry would be prepared. How could I solve
>>optimisation across inlined functions within very limited memory ?
>[Please use lines of about 72 chars; I wrapped them myself, but
>normally that's your job.]
>Normally (without memory worries), I would keep the words in memory in
>an intermediate format (e.g., as byte code, but with all things
>resolved that need to be resolved when text-interpreting), and then
>process that when inlining a call. I don't know if that is viable for
>your memory constraints, however. But if you save enough memory from
>the optimization, to pay for the intermediate code...
>A classic Forth approach is manual marking of words as words to be
>inlined. Might help in your situation, too.
In case you want to try something simple, this is some sample code
from ciforth. A design decision was that the (;) ( an alias for EXIT)
is obligatory at the end of every high level word.
"
\ Alias of : , define a word that inlines it code.
: :I CREATE IMMEDIATE ] LATEST HIDDEN !CSP
DOES> STATE @ IF BEGIN $@ DUP '(;) <> WHILE , REPEAT 2DROP
ELSE >R THEN ;
"
[ $@ is better known under the name @+ but I refrained from
modifying working library code. One should use COMPILE, here
but I don't have it. LATEST HIDDEN !CSP : those show that
carnal knowledge is of the essential ]
I made it intelligent such that it can be tested interactively.
Otherwise it would be even simpler (but less useful).
>>Buffering the source code of the definitions short enough to maybe be
>>inlined later would be an option, but would also require heavy
>>amounts of memory.
>Inlining source code can lead to incorrect results (e.g., consider
>what happens if the BASE is changed before inlining). Basically, you
>need to record the calls to COMPILE, LITERAL etc.
Right!
<SNIP>
>- 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.rigwit.co.uk/EuroForth2015/
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-11-05 12:02 +0100 |
| Message-ID | <n1fcta$9n1$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #43122 |
Hallo Anton, thank you for the hints ! Saving a stream of "what is to be compiled" along with the actual opcodes works fine for later optimized inlining, but I found it more useful to capture this after constant folding to get a more compact representation, also this helps to process zero-foldable things like [char] without introducing special cases. My first prototype is up and running, now I need to squeeze the memory requirements for it. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2015-11-05 15:57 +0100 |
| Message-ID | <n1fqma$dsl$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #43251 |
Now it works fine ! Experimental Mecrisp-Stellaris RA 1.3 is now released as usual on mecrisp.sourceforge.net Matthias : sqr ( n -- n^2 ) dup * ; ok. : >gray ( u -- x ) dup 1 rshift xor ; ok. : gray+sqr ( n -- x ) dup sqr swap >gray + ; ok. ok. see sqr 00006B22: 4376 muls r6 r6 00006B24: 4770 bx lr ok. see >gray 00006B40: 0873 lsrs r3 r6 #1 00006B42: 405E eors r6 r3 00006B44: 4770 bx lr ok. see gray+sqr 00006B70: 0033 lsls r3 r6 #0 00006B72: 4373 muls r3 r6 00006B74: 0872 lsrs r2 r6 #1 00006B76: 4056 eors r6 r2 00006B78: 199E adds r6 r3 r6 00006B7A: 4770 bx lr ok.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-07-28 15:32 -0400 |
| Message-ID | <mp8lc5$bs1$1@speranza.aioe.org> |
| In reply to | #40845 |
On 27/07/2015 2:02 PM, hughaguilar96@gmail.com wrote: > (the 65c816 and MC6808 both had indexing addressing into the return-stack, for example) --- > they weren't "generic microprocessors" but were in fact C-engines I worked on the MC6808 ISA it was hardly a "C-engine" It didn't meet the minimum feature set required to support C despite the fact that C compilers (including ours) were written for it. The design goals for the MC6808 were compatibility with 6805 and embedded systems applications in general. w..
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-29 16:35 -0700 |
| Message-ID | <3a182102-509c-489d-a8d3-22dae7753844@googlegroups.com> |
| In reply to | #40879 |
On Tuesday, July 28, 2015 at 12:32:26 PM UTC-7, Walter Banks wrote: > On 27/07/2015 2:02 PM, hughaguilar96@gmail.com wrote: > > (the 65c816 and MC6808 both had indexing addressing into the return-stack, for example) --- > > they weren't "generic microprocessors" but were in fact C-engines > > > I worked on the MC6808 ISA it was hardly a "C-engine" It didn't meet > the minimum feature set required to support C despite the fact that C > compilers (including ours) were written for it. The design goals for > the MC6808 were compatibility with 6805 and embedded systems > applications in general. > > w.. The reason why I said the 6808 was designed for C, is that it had indexed-addressing into the return-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. All in all, the 6808 was designed specifically to support C, and it represents the smallest possible processor that can support C. The 6808 is a terrible target for Forth however, because there is no register available to be used as the parameter-stack pointer. This was the chronic problem in the 1980s with register-starved processors --- no register available to be used as the parameter-stack pointer (or, if there is a register available, it lacks an indexed-addressing mode). In the bad-old days, processors were register-starved and they were CISC (so we had instructions that worked only with certain registers) --- the processor was very much designed to support a particular language, as it had instructions provided specifically for that language --- now, with RISC processors that have a lot of registers and an orthogonal instruction-set, the processor is no longer language-specific but is suitable for pretty much any language.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web