Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-10 01:02 -0700 |
| Subject | Re: FP stack |
| Message-ID | <87lgq5b0n2.fsf@nightsong.com> |
| In reply to | #58942 |
Ron Aaron <rambamist@gmail.com> writes: > Wouldn't it have made some sense to make all items take one cell on the > stack so that you could just use SWAP without worrying? Not on the memory starved computers of the classic Forth era.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-10 11:06 +0300 |
| Subject | Re: FP stack |
| Message-ID | <oeuhfo$eo7$2@dont-email.me> |
| In reply to | #58943 |
On 05/10/17 11:02, Paul Rubin wrote: > Ron Aaron <rambamist@gmail.com> writes: >> Wouldn't it have made some sense to make all items take one cell on the >> stack so that you could just use SWAP without worrying? > > Not on the memory starved computers of the classic Forth era. OK... that was a looong time ago. Even today's micro-controllers often have sufficient memory to handle a more sophisticated and less prone to programmer failure approach.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-10 09:58 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May10.115818@mips.complang.tuwien.ac.at> |
| In reply to | #58942 |
Ron Aaron <rambamist@gmail.com> writes:
>IMO, this is one of the weaknesses of ANS Forth. You have to keep track
>of how many cells your data takes up. Strings can be one or two cells,
>so can numbers; and, I suppose, other things as well.
>
>Wouldn't it have made some sense to make all items take one cell on the
>stack so that you could just use SWAP without worrying?
In most cases, numbers just use one cell. It's rare that 64 bits is
not enough. For strings, having address and length as separate cells
gives us easy access to the address and to the length. Of course, you
can argue that we so often use both as an atomic unit that it would be
more convenient to have 128-bit cells on 64-bit machines, and have
extraction words for address and length. And likewise for doubles.
But we also have existing code, and a little convenience is not enough
reason to break that (there are ways to deal with that, though, see
below). Another reason against is that operations like DUP and SWAP
would become more expensive (not much, but still) for data that uses
only 64 of the 128 bits. And finally, small systems with a few KB of
RAM or less are still relevant for Forth, and you don't want to waste
anything there.
One way to deal with the backwards compatibility issues is to have new
words that deal with the new single-cell doubles and single-cell
strings, e.g.
E+ ( e e -- e ) \ where e is a single-cell double-length integer
TTYPE ( t -- ) \ where t is a single-cell string descriptor
T->ADDR ( t -- addr )
T->LEN ( t -- u )
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-10 14:17 +0300 |
| Subject | Re: FP stack |
| Message-ID | <oeusmf$ift$1@dont-email.me> |
| In reply to | #58956 |
On 05/10/17 12:58, Anton Ertl wrote: > Ron Aaron <rambamist@gmail.com> writes: > In most cases, numbers just use one cell. It's rare that 64 bits is > not enough. That may be true, but the doubles exist and people will use them -- in 'portable' code. Doubles always take two cells (I believe, can't remember what the standard says). It's not at all rare to use doubles, especially in code ported from 16 or 32 bit systems. > For strings, having address and length as separate cells > gives us easy access to the address and to the length. Of course, you > can argue that we so often use both as an atomic unit that it would be > more convenient to have 128-bit cells on 64-bit machines, and have > extraction words for address and length. And likewise for doubles. Or you can use counted strings, with cell-sized counts. Now you have the size, and the data, in one cell (you know what I mean). > But we also have existing code, and a little convenience is not enough > reason to break that (there are ways to deal with that, though, see > below). This is true. But if you're already making a new standard, you can deprecate old code. Or make a 'pragma' or such where you notify the compiler you're using old code (or new code, depending on where the pain-point is). > Another reason against is that operations like DUP and SWAP > would become more expensive (not much, but still) Ehh. Not much indeed. > And finally, small systems with a few KB of > RAM or less are still relevant for Forth, and you don't want to waste > anything there. Again, that's true. But are users of tiny systems going to pursue using the latest compiler? Should they? I don't know...
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 13:09 +0100 |
| Subject | Re: FP stack |
| Message-ID | <oeuvnm$sm2$1@dont-email.me> |
| In reply to | #58956 |
On 5/10/2017 10:58, Anton Ertl wrote: > Ron Aaron <rambamist@gmail.com> writes: >> IMO, this is one of the weaknesses of ANS Forth. You have to keep track >> of how many cells your data takes up. Strings can be one or two cells, >> so can numbers; and, I suppose, other things as well. >> >> Wouldn't it have made some sense to make all items take one cell on the >> stack so that you could just use SWAP without worrying? > > In most cases, numbers just use one cell. It's rare that 64 bits is > not enough. For strings, having address and length as separate cells > gives us easy access to the address and to the length. Of course, you > can argue that we so often use both as an atomic unit that it would be > more convenient to have 128-bit cells on 64-bit machines, and have > extraction words for address and length. And likewise for doubles. We already have 80 bit floats (which Win32Forth supports). We will see 128 bit floats on Intel in my lifetime; they already exist on some non-Intel platforms. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-10 15:05 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May10.170504@mips.complang.tuwien.ac.at> |
| In reply to | #58970 |
Alex <alex@rivadpm.com> writes:
>We already have 80 bit floats (which Win32Forth supports). We will see
>128 bit floats on Intel in my lifetime; they already exist on some
>non-Intel platforms.
For some values of "exist". The typical implementation is to use
software to combine two 64-bit floats into a 128-bit float with 106
(2*53) bits of mantissa and the same exponent range as the 64-bit
floats.
Cells grow because memory and data grows: To address To address 8GB,
you need more the 32 bits, so we get 64 bit cells.
By contrast, there is no such technological drive towards larger FP
numbers. Which FP numbers you use depends on the accuracy
requirements of your application: For neural nets, you use 16-bit or
maybe even 8-bit fp, for graphics, often 16-bit FP, for some
computations 32-bit fp, for most scientific work 64-bit FP, and for
extreme cases, more.
Consequently, we see no growth in FP sizes in the hardware. IBM S/360
had 64-bit double-precision FP numbers in 1964, and now, 53 years
later, we have 64-bit double-precision FP numbers in SSE and AVX
instructions on Intel and AMD, and on basically everything else.
Sure, there was an episode of 80-bit FP numbers (8087, 68881), but
that is now legacy stuff. E.g., floating-point arguments are passed
to functions (in 64-bit format) in the XMM (SSE) registers in both the
AMD64 System V ABI (Linux, MacOS) and the x86 Windows ABI.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-10 11:43 +0200 |
| Subject | Re: FP stack |
| Message-ID | <oeunc8$iip$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58930 |
In article <6tednSpqKomGXY_EnZ2dnUU7-N1QAAAA@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 5/9/17 9:10 PM, Alex wrote: >> On 5/10/2017 04:59, Joel Rees wrote: >>> Say you have >>> >>> 1 1. >>> >>> on stack. How do you swap them? >> >> ROT >> >> 1 3. ok[3] >> rot ok[3] >> . 1 ok[2] >> d. 3 ok > >Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? Even you! It is time that my proposal that doubles obligatory start *and* end with a dot is taken seriously. (Before moving them to a dark corner.) Nobody will take .1. for a float. > >Cheers, >Elizabeth Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-10 18:34 +1000 |
| Subject | Re: FP stack |
| Message-ID | <oeujbo$st6$1@gioia.aioe.org> |
| In reply to | #58921 |
Joel Rees wrote: > On Tuesday, May 9, 2017 at 5:39:44 PM UTC+9, Andrew Haley wrote: > > Joel Rees <joel rees@somewhere> wrote: > > > > > >> 2) How many cells should an FP value have on the data stack? 1? 2? 4? > > >> None of these answers is good for all systems. Or maybe an FP value > > >> should be an opaque type with an unspecified size? Then you cannot > > >> access anything below it. > > > > > > As I mentioned elsewhere, I don't understand how this is a concern. > > > > > > When we need to know the byte width of a CELL, if we don't have a > > > constant for it, we make one, just so we don't have to keep writing > > > > > > SP@ SP@ - > > > > > > all over in our code. > > > > > > We have to provide the floating point math words, why not just provide > > > a few constants to tell us how big they are? > > > > That's not the problem. Say you have > > > > 1 1.0e0 > > > > on an integrated stack with floating-point numbers and integers. How > > do you SWAP them? A float might be 1, 2, or 3 cells in size. > > > > Andrew. > > Say you have > > 1 1. > > on stack. How do you swap them? > ... In the case of floats and integers, the short answer is you don't. If you arranged the order of arguments appropriately you shouldn't need to. Forth has used combined stack for decades. ANS functions which cater for floats and integers on the data stack, specify the order in which they should appear (typically float first, integer on top). LMI - claimed to be Forth's second largest vendor - used floats on the data stack exclusively. No float/integer juggling operators were employed or needed.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-10 09:45 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May10.114520@mips.complang.tuwien.ac.at> |
| In reply to | #58946 |
"HAA" <someone@microsoft.com> writes:
>LMI - claimed to be Forth's second largest vendor - used
>floats on the data stack exclusively.
Whoever claims this is wrong. Looking at
<https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked
for LMI since 2000, and AFAIK LMI has not had any business since then,
if it exists at all (Google does not find a web page belonging to LMI).
In any case, even the largest Forth vendors make a short-sighted
decision occasionally. Some are smart enough to revise them. E.g.,
once upon a time even the larges Forth vendors exclusively used 16-bit
cells, and use 2+ to get to the next cell.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-11 19:13 +1000 |
| Subject | Re: FP stack |
| Message-ID | <of19vg$18o9$1@gioia.aioe.org> |
| In reply to | #58952 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >LMI - claimed to be Forth's second largest vendor - used > >floats on the data stack exclusively. > > Whoever claims this is wrong. Looking at > <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked > for LMI since 2000, and AFAIK LMI has not had any business since then, > if it exists at all (Google does not find a web page belonging to LMI). LMI was certainly a major Forth vendor. So what if the owner chose to leave to pursue other interests. > > In any case, even the largest Forth vendors make a short-sighted > decision occasionally. Some are smart enough to revise them. E.g., > once upon a time even the larges Forth vendors exclusively used 16-bit > cells, and use 2+ to get to the next cell. > > - anton MPE is still supplying f/p with floats on the data stack. They must be chronically "short-sighted". Circa 2016 they added yet another to the VFX distribution LIb/SoftFP32.combined.fth. They provide a separate stack version SoftFP32.separate.fth hacked from the former but it's pretty obvious which one would be more efficient. You've been told time and again by those who use combined stack f/p that it poses no issue. You ignore them as you did the ANS TC: "It is the experience of several members of the Technical Committee that with proper coding practices it is possible to write floating-point code that will run identically on systems with a separate floating-point stack and with floating-point numbers kept on the data stack." Just as there were 'haters' of ANS locals who sought to have it replaced with one of their own preference, so there have been 'haters' of ANS combined stack f/p who sought to eliminate that. That's it in a nutshell.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-11 04:50 -0500 |
| Subject | Re: FP stack |
| Message-ID | <RP-dnUJT4qFwronEnZ2dnUU7-S3NnZ2d@supernews.com> |
| In reply to | #59065 |
HAA <someone@microsoft.com> wrote: > > You've been told time and again by those who use combined stack f/p > that it poses no issue. You ignore them as you did the ANS TC: > > "It is the experience of several members of the Technical Committee > that with proper coding practices it is possible to write > floating-point code that will run identically on systems with a > separate floating-point stack and with floating-point numbers kept > on the data stack." > > Just as there were 'haters' of ANS locals who sought to have it > replaced with one of their own preference, so there have been > 'haters' of ANS combined stack f/p who sought to eliminate that. > That's it in a nutshell. Combined floating-point and integer stacks are almost impossible to use for anything except the most trivial code. The only exception to that is when a single cell is used for a floating-point number, but this is not a portable assumption. These days, with 64-bit processors being common, a combined stack might make sense in some circumstances, but I'm unaware of any significant advantage over separate stacks. Given floating-point hardware (and therefore floating point registers) separate stacks make sense, and in the absence of hardware, floating-point arithmetic is unlikely to be a compelling choice for Forth programmers. From a performance point of view, it can take several cycles to transfer a value from the FP registers to the integer registers and back, sometimes as long as a L1 cache access, so if you keep some stack values in registers you're going to spend time shuffling stuff back and forth. That's why we standardized separate stacks. We didn't ignore the old ANS TC, we disagreed with them. And, for what it's worth, I suspect that the world has changed so much that they would also change their opinion if asked today. We are no longer trying to implement software floating-point on Novix. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-11 16:18 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May11.181855@mips.complang.tuwien.ac.at> |
| In reply to | #59069 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>We are no longer trying to implement software
>floating-point on Novix.
And when implementing FP in software (whether on Novix or elsewhere),
the advantage of the unified stack (i.e, avoiding the need to load the
FP value from memory) is small and overall I expect a separate stack
to be faster even in this scenario, because you avoid the stack
manipulation overhead of juggling FP values of system-specific size on
the data stack (i.e., all the PICKs etc.).
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-11 12:12 -0500 |
| Subject | Re: FP stack |
| Message-ID | <lqCdnUORZLMIBonEnZ2dnUU7-X_NnZ2d@supernews.com> |
| In reply to | #59087 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>We are no longer trying to implement software floating-point on >>Novix. > > And when implementing FP in software (whether on Novix or > elsewhere), the advantage of the unified stack (i.e, avoiding the > need to load the FP value from memory) is small and overall I expect > a separate stack to be faster even in this scenario, because you > avoid the stack manipulation overhead of juggling FP values of > system-specific size on the data stack (i.e., all the PICKs etc.). The specific machine architecture is important. The choice of separate versus combined stacks wasn't really so clear for Novix. There you had no registers to spare, so a floating-point stack pointer would have been kept in the user area or in a fixed location in memory. If you kept the floating-point stack pointer in a fixed location, you'd have to stack and unstack it at every context switch, adding overhead. If you kept it in the user area, simply getting the fsp would be : fsp ( -- a) u @ n + @ ; So, you'd have at least three fetches just to get the top fp stack item. I'm not saying that integrated FP would necessarily be faster in practical use, but I understand the decision. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-11 13:53 +0000 |
| Subject | Re: FP stack |
| Message-ID | <5914662a.90083432@news.eternal-september.org> |
| In reply to | #59065 |
On Thu, 11 May 2017 19:13:24 +1000, "HAA" <someone@microsoft.com> wrote: >MPE is still supplying f/p with floats on the data stack. They must be >chronically "short-sighted". Circa 2016 they added yet another to the >VFX distribution LIb/SoftFP32.combined.fth. They provide a separate >stack version SoftFP32.separate.fth hacked from the former but it's >pretty obvious which one would be more efficient. These days, people like to prototype embedded algorithms on PCs. It makes sense to permit an x86 PC to run the same FP code as a Cortex-Mx. Hence the two new FP files which match files of similar names in the target code directories. >You've been told time and again by those who use combined stack f/p >that it poses no issue. You ignore them as you did the ANS TC: > >"It is the experience of several members of the Technical Committee that >with proper coding practices it is possible to write floating-point code that >will run identically on systems with a separate floating-point stack and with >floating-point numbers kept on the data stack." I'm not particularly biased, except for a few embedded systems cases. Even these will disappear as embedded systems migrate to 64 hardware FP over the next few years. There are places in embedded programming where floats and integers are the same size. For example, most Cortex-M4Fs and early Cortex-M7s only provide 32 bit floats. In this case why waste an extra stack and register on a float stack? Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-11 15:43 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May11.174300@mips.complang.tuwien.ac.at> |
| In reply to | #59083 |
stephen@mpeforth.com (Stephen Pelc) writes:
>There are places in embedded programming where floats and integers are
>the same size. For example, most Cortex-M4Fs and early Cortex-M7s
>only provide 32 bit floats. In this case why waste an extra stack
>and register on a float stack?
If you cannot afford a register for the FP stack pointer, keep it in
memory. The result is probably still going to be faster than using
the data stack for FP, for several reasons:
1) No overhead for moving stuff from the integer registers to the FP
registers and back.
2) You can cache the top-of-fp-stack items in fp registers.
3) The separate-stack Forth program will contain fewer stack
manipulation words (just take a look at the faxpy-nostride variants in
this thread).
4) Once you extend your compiler to also be analytical about FP
values, register pressure on the integer registers will decrease even
more (you keep more values in FP registers).
If you take the analytical approach to the extreme, i.e., in PAF (and
if you comply with PAF requirements, i.e., in most code), you get the
same code (including having only one stack pointer, and with FP values
in FP registers and integer values in integer registers) whether the
programmer writes unified-stack or separate-stack code. In that case
ease of programming makes the separate-stack approach preferable.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-12 08:48 -0700 |
| Subject | Re: FP stack |
| Message-ID | <2aeb984e-8198-4c8e-92d3-772d28a437f8@googlegroups.com> |
| In reply to | #59085 |
On Friday, May 12, 2017 at 1:03:10 AM UTC+9, Anton Ertl wrote: > stephen@mpeforth.com (Stephen Pelc) writes: > >There are places in embedded programming where floats and integers are > >the same size. For example, most Cortex-M4Fs and early Cortex-M7s > >only provide 32 bit floats. In this case why waste an extra stack > >and register on a float stack? > > If you cannot afford a register for the FP stack pointer, keep it in > memory. The result is probably still going to be faster than using > the data stack for FP, for several reasons: Are you talking about FP stack in memory, not in the FP hardware? If that's the case, how do you claim (1) below? If you are talking about the FP hardware, are you assuming that the FP registers can be aliased to addressable memory? > 1) No overhead for moving stuff from the integer registers to the FP > registers and back. > > 2) You can cache the top-of-fp-stack items in fp registers. Apparently, you are talking about aliasing the fp registers to the stack. > 3) The separate-stack Forth program will contain fewer stack > manipulation words (just take a look at the faxpy-nostride variants in > this thread). I would rather say I used non-traditional (non-Forth-traditional) stack manipulation, not more stack manipulation. FPICK and FPUT (I think I called them) implemented at the machine code level are both two instructions on any decent processor I can think of. I'm sure, with a little work, you could have the compiler just rename registers the same as SWAP and ROT. > 4) Once you extend your compiler to also be analytical about FP > values, register pressure on the integer registers will decrease even > more (you keep more values in FP registers). And I am not really intending to speak riddles when I suggest that simply having one more general alternate stack on processors that operate on floating point data in general purpose registers will provide even greater room for optimizing out data motion. > If you take the analytical approach to the extreme, i.e., in PAF (and > if you comply with PAF requirements, i.e., in most code), you get the > same code (including having only one stack pointer, and with FP values > in FP registers and integer values in integer registers) whether the > programmer writes unified-stack or separate-stack code. In that case > ease of programming makes the separate-stack approach preferable. PAF -- Portable Assembler (F______?) I'm not following that. Can you unpack it a bit? -- Joel Rees Imagining I'm a novelist: http://reiisi.blogspot.jp/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-11 16:31 +0000 |
| Subject | Re: FP stack |
| Message-ID | <2017May11.183116@mips.complang.tuwien.ac.at> |
| In reply to | #59065 |
"HAA" <someone@microsoft.com> writes:
>MPE is still supplying f/p with floats on the data stack.
Many systems contain obsolete parts to support legacy code.
>They must be chronically "short-sighted".
Stephen Pelc' reply to your posting allows everyone to evaluate that
themselves.
>Circa 2016 they added yet another to the
>VFX distribution LIb/SoftFP32.combined.fth. They provide a separate
>stack version SoftFP32.separate.fth hacked from the former but it's
>pretty obvious which one would be more efficient.
It is? I would like to test this, but:
[~:95291] vfxlin "include /usr/local/VfxLinEval/Lib/SoftFP32.combined.fth"
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/SoftFP32.combined.fth
1e f.
Err# -13 ERR: Undefined word.
-> 1e f.
^
Somehow these packages do not even understand standard FP literals.
>You've been told time and again by those who use combined stack f/p
>that it poses no issue.
Sure, doing it for one particular combined stack implementation is
doable. But will the program work on another combined-stack
implementation with a different number of cell per FP value? E.g.,
Stephen Pelc' posting in favour of a combined stack bases the
recommendation on the condition that FP values take one cell, so he
would write the code specific to this particular FP value size. The
result would be non-portable programs.
>"It is the experience of several members of the Technical Committee that
>with proper coding practices it is possible to write floating-point code that
>will run identically on systems with a separate floating-point stack and with
>floating-point numbers kept on the data stack."
Sure it's possible. It's just not practical.
>Just as there were 'haters' of ANS locals who sought to have it replaced
>with one of their own preference, so there have been 'haters' of ANS
>combined stack f/p who sought to eliminate that. That's it in a nutshell.
The fans of combined stacks had 14 years to come up with lots of code
that was written to comply with the Forth-94 restriction of running on
combined-stack systems with any FP size and on separate-stack systems;
only Krishna Myneni came up with something in this direction, but IIRC
after the separate FP stack proposal had been accepted. By contrast,
right after Forth-94 those interested in getting work done (you call
them 'haters') wrote the FSL with the environmental restriction on a
separate FP stack.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-11 10:18 -1000 |
| Subject | Re: FP stack |
| Message-ID | <OMudnci3Jp24WonEnZ2dnUU7-SHNnZ2d@supernews.com> |
| In reply to | #59065 |
On 5/10/17 11:13 PM, HAA wrote: > Anton Ertl wrote: >> "HAA" <someone@microsoft.com> writes: >>> LMI - claimed to be Forth's second largest vendor - used >>> floats on the data stack exclusively. >> >> Whoever claims this is wrong. Looking at >> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked >> for LMI since 2000, and AFAIK LMI has not had any business since then, >> if it exists at all (Google does not find a web page belonging to LMI). > > LMI was certainly a major Forth vendor. So what if the owner chose to > leave to pursue other interests. > Ray was a physician. In the mid-90's he went back to grad school and became a neonatologist. When he entered practice, he turned over his code and customer list to FORTH, Inc. and we took care of a number of his customers for years. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-11 15:37 -0500 |
| Subject | Re: FP stack |
| Message-ID | <of2hs7$3rd$1@dont-email.me> |
| In reply to | #59093 |
On 5/11/2017 3:18 PM, Elizabeth D. Rather wrote: > On 5/10/17 11:13 PM, HAA wrote: >> Anton Ertl wrote: >>> "HAA" <someone@microsoft.com> writes: >>>> LMI - claimed to be Forth's second largest vendor - used >>>> floats on the data stack exclusively. >>> >>> Whoever claims this is wrong. Looking at >>> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked >>> for LMI since 2000, and AFAIK LMI has not had any business since then, >>> if it exists at all (Google does not find a web page belonging to LMI). >> >> LMI was certainly a major Forth vendor. So what if the owner chose to >> leave to pursue other interests. >> > > Ray was a physician. In the mid-90's he went back to grad school and > became a neonatologist. When he entered practice, he turned over his > code and customer list to FORTH, Inc. and we took care of a number of > his customers for years. > > Cheers, > Elizabeth > Since it's so old, can we have it? -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-11 17:25 -1000 |
| Subject | Re: FP stack |
| Message-ID | <VsadncaAHt6qtojEnZ2dnUU7-dfNnZ2d@supernews.com> |
| In reply to | #59095 |
On 5/11/17 10:37 AM, Cecil Bayona wrote: > On 5/11/2017 3:18 PM, Elizabeth D. Rather wrote: >> On 5/10/17 11:13 PM, HAA wrote: >>> Anton Ertl wrote: >>>> "HAA" <someone@microsoft.com> writes: >>>>> LMI - claimed to be Forth's second largest vendor - used >>>>> floats on the data stack exclusively. >>>> >>>> Whoever claims this is wrong. Looking at >>>> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked >>>> for LMI since 2000, and AFAIK LMI has not had any business since then, >>>> if it exists at all (Google does not find a web page belonging to LMI). >>> >>> LMI was certainly a major Forth vendor. So what if the owner chose to >>> leave to pursue other interests. >>> >> >> Ray was a physician. In the mid-90's he went back to grad school and >> became a neonatologist. When he entered practice, he turned over his >> code and customer list to FORTH, Inc. and we took care of a number of >> his customers for years. >> >> Cheers, >> Elizabeth >> > Since it's so old, can we have it? I can't answer that, Leon is in charge now. I don't even know if he could find a copy, nor do I know why you would want one. There are numerous better free Forths around. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
Page 5 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