Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #52599 > unrolled thread

Are stack machines inherently faster?

Back to article view | Back to comp.lang.forth

Contents

  Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-13 18:33 -0800
    Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-13 23:02 -0500
      Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-14 16:59 -0800
        Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-14 22:27 -0500
          Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-17 06:26 -0800
            Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 08:08 -0800
              Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-17 10:52 -0800
                Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-17 09:57 -1000
                Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-17 15:58 -0800
                  Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 16:29 -0800
                  Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-18 08:26 +0000
                  Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 11:17 +0000
                    Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-18 06:37 -0800
                      Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 15:30 +0000
                        Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:25 -0800
                          Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 05:08 -0500
                            Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 15:12 -1000
                              Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-27 21:06 -0800
                                Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 12:20 +0000
                                Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 13:43 +0000
                                  Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 08:52 -0600
                                    Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 17:19 +0000
                                      Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 11:58 -0600
                                    Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 20:39 +0100
                                      Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 21:56 +0000
                                        Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:22 +0100
                                          Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-29 11:06 +0000
                                      Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-29 09:44 -0600
                                        Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 13:07 -0800
                                    Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:37 -0800
                                  Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:02 -0800
                                    Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 14:41 +0000
                                      Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-29 21:32 -0800
                                  Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 12:43 -0500
                                    Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 18:38 +0000
                                    Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:57 -0800
                              Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 16:50 -0800
                            Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 00:19 -0800
                      Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-18 10:58 -0800
                    Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-19 11:29 +1100
                      Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-18 18:18 -1000
                      Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-19 00:31 -0800
                        Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-20 14:02 +0000
                          Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-20 23:16 -0800
                            Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 09:51 +0000
                              Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-24 14:16 -0800
                                Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 15:26 +0000
                      Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-19 17:42 +0000
                        Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:26 -0800
                          Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-22 10:38 +0000
                            Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 12:46 -0800
                              Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-24 15:15 -0600
                                Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 14:30 -0800
                                  Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-25 05:37 -0800
                                    Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-25 09:58 -0600
                                      Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:39 -0800
                                    Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-25 12:26 -0600
                                      Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:57 -0800
                                        Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-26 13:40 -0600
                                          Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-01 05:35 -0800
                                            Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-01 18:38 -0800
                                              Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 21:52 -0800
                                                Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 08:45 +0200
                                                  Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 08:50 +0000
                                                    Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:34 +0100
                                                      Re: Are stack machines inherently faster? john <anon@example.com> - 2016-12-02 10:20 +0000
                                                      Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:04 +0000
                                                    Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 11:59 +0200
                                                      Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:44 +0000
                                                        Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 13:23 +0200
                                                          Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-12-02 15:12 +0100
                                                            Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-03 17:35 +0200
                                                              Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 10:31 +0100
                                                                Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 12:01 +0200
                                                                  Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 13:53 +0100
                                                                    Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 14:59 +0200
                                                                      Re: Are stack machines inherently faster? minforth@arcor.de - 2017-01-09 08:15 -0800
                                                                        Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 19:33 +0100
                                                        Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
                                                          Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-12-02 21:09 -1000
                                                            Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-03 13:01 +0100
                                                          Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 14:51 +0000
                                              Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-02 04:28 -0800
                                Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-25 16:10 +0000
                                  Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-25 16:51 -0800
                                    Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-26 15:09 -0800
                                  Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-26 13:03 +0100
                                    Re: Are stack machines inherently faster? franck.bensusan@gmail.com - 2016-11-27 10:11 -0800
                                Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 16:00 +0000
                              Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-24 22:44 +0000
                            Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-24 23:11 +0000
                              Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 16:38 -0800
                              Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-25 07:28 +0000
                                Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-25 04:24 -0800
                                  Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-25 14:37 +0000
                                    Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-26 10:54 -0800
                                      Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 10:56 -0800
                          Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:27 -0800
                            Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 11:42 -0800
                        Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:35 -0800
                        Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-22 17:43 +1100
                          Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-22 12:51 +0000
                            Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 13:30 -0800
                    Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-18 20:27 -0800
                    Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:23 -0800
                  Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
              Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-17 12:50 -0800
                Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
    Re: Are stack machines inherently faster? Manuel Rodriguez <aa5@gmx.net> - 2016-11-28 11:00 -0800
      Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-11-28 16:10 -0500
        Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
          Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 00:46 -0600
            Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 02:01 -0500
              Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-12-01 13:01 -0500
                Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-03 17:15 -0800
                  Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 02:29 -0500
                    Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-04 03:41 -0600
                      Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 10:10 -0500
                        Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 17:16 +0000
      Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-28 13:33 -0800
        Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:17 +0100
        Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 09:17 -0800
          Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 14:46 -0500
            Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:44 -0800
              Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 18:39 -0500
                Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-30 15:00 -0800
                  Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 18:42 -0500
                    Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:26 -1000
        Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#53027

On Thursday, December 1, 2016 at 6:35:56 AM UTC-7, Ilya Tarasov wrote:
> > A guess on my part but I will attribute your answer to language issues, 
> > because you are responding as I was making claims that I did not make.
> > 
> > I did not state that performance by Forth is superior to anything else, 
> > or that performance is necessary in all cases but that it "can be 
> > important" in some cases.
> 
> If you think ... evil siberian bear forcing me to drink vodka you are probably wrong. 

Probably wrong? Does that mean that there is a probability less than 0.5 that an evil siberian bear is forcing you to drink vodka?

> > Switching to assembler could be avoided if the Forth compiler is 
> > efficient, not everyone is making a project that involves making a lot 
> > of units, in my case most projects are one of a kind not to be duplicated.
> 
> Switching to assembler is not a disaster. 'Right tool for the right task'.

For a long time, I thought of Forth as being an over-grown macro-assembler. There was no issue of "switching to assembler" --- writing code in assembly was the focus throughout.

That seemed to be the idea at Testra where I wrote MFX for their MiniForth processor --- I wrote quite a lot of assembly code, and I also wrote Forth code that metacompiled assembly (called "macros" in a traditional macro-assembler) --- there wasn't any distinction between hand-writing assembler code and compiling assembler code (because I was the one who wrote the compiler).

[toc] | [prev] | [next] | [standalone]

#53031

On Thursday, December 1, 2016 at 9:38:29 PM UTC-5, hughag...@gmail.com wrote:
> On Thursday, December 1, 2016 at 6:35:56 AM UTC-7, Ilya Tarasov wrote:
> > > A guess on my part but I will attribute your answer to language issues, 
> > > because you are responding as I was making claims that I did not make.
> > > 
> > > I did not state that performance by Forth is superior to anything else, 
> > > or that performance is necessary in all cases but that it "can be 
> > > important" in some cases.
> > 
> > If you think ... evil siberian bear forcing me to drink vodka you are probably wrong. 
> 
> Probably wrong? Does that mean that there is a probability less than 0.5 that an evil siberian bear is forcing you to drink vodka?
> 
> > > Switching to assembler could be avoided if the Forth compiler is 
> > > efficient, not everyone is making a project that involves making a lot 
> > > of units, in my case most projects are one of a kind not to be duplicated.
> > 
> > Switching to assembler is not a disaster. 'Right tool for the right task'.
> 
> For a long time, I thought of Forth as being an over-grown macro-assembler. There was no issue of "switching to assembler" --- writing code in assembly was the focus throughout.
> 
> That seemed to be the idea at Testra where I wrote MFX for their MiniForth processor --- I wrote quite a lot of assembly code, and I also wrote Forth code that metacompiled assembly (called "macros" in a traditional macro-assembler) --- there wasn't any distinction between hand-writing assembler code and compiling assembler code (because I was the one who wrote the compiler).

So there is no hope for a $100 forth desktop pc? with less code that can use online email and bank websites? with nice browser?

[toc] | [prev] | [next] | [standalone]

#53032

On 02/12/2016 7:52, polymorph self wrote:

> So there is no hope for a $100 forth desktop pc? with less code that can use online email and bank websites? with nice browser?

Sure there is!  But you'll have to invest $10M to get it developed and
another $100M to advertise it and get it adopted.

[toc] | [prev] | [next] | [standalone]

#53034

Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 02/12/2016 7:52, polymorph self wrote:
>
>> So there is no hope for a $100 forth desktop pc? with less code that can use online email and bank websites? with nice browser?
>
>Sure there is!  But you'll have to invest $10M to get it developed and
>another $100M to advertise it and get it adopted.

Intel Compute Sticks start at EUR 95.89, so should be be available for
around $100.  Install Linux and, say, Gforth on it, and you have a
Forth desktop PC for $100.

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#53035

In article <2016Dec2.095019@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Ron Aaron <rambamist@gmail.com> writes:
>>
>>
>>On 02/12/2016 7:52, polymorph self wrote:
>>
>>> So there is no hope for a $100 forth desktop pc? with less code that can use online email and bank websites? with nice browser?
>>
>>Sure there is!  But you'll have to invest $10M to get it developed and
>>another $100M to advertise it and get it adopted.
>
>Intel Compute Sticks start at EUR 95.89, so should be be available for
>around $100.  Install Linux and, say, Gforth on it, and you have a
>Forth desktop PC for $100.

When the Raspberry pi was new, I took it to the German Forth conference.
Using the tv set in the hotel room, I could do unix development on it,
such as metacompiling noforth using gforth. That was a 100 Euro desktop.
However that is not what you want to put up with for real work, all day.

The most expensive parts of a computer are the screen and the keyboard.
Good screens start at 200 Euro and a good keyboard is still 100 Euro so
polymorph is being silly.

>
>- anton
-- 
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]

#53037

In article <o1rf7r$7vm$1@cherry.spenarnc.xs4all.nl>, 
albert@cherry.spenarnc.xs4all.nl says...
> The most expensive parts of a computer are the screen and the keyboard.
> Good screens start at 200 Euro and a good keyboard is still 100 Euro so
> polymorph is being silly.
> 

feeding trolls is also silly.

If you really want to take his question seriously
(I can't he's in my bozo bin now so I dont even see his posts)
then ask him exactly what he means and why.

Ask him to define his requirements accurately.
then plonk him when he fails to comply and move on.

-- 
john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

[toc] | [prev] | [next] | [standalone]

#53038

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>When the Raspberry pi was new, I took it to the German Forth conference.
>Using the tv set in the hotel room, I could do unix development on it,
>such as metacompiling noforth using gforth. That was a 100 Euro desktop.

Actually, the Raspi is quite a bit cheaper, but yes, it certainly fits
the bill.

>However that is not what you want to put up with for real work, all day.

Funnily, our sysadmin, who has quite a few big PCs in his room, uses a
Raspi3 as his main interface to the rest of the world (mostly with
ssh, though).

>The most expensive parts of a computer are the screen and the keyboard.
>Good screens start at 200 Euro and a good keyboard is still 100 Euro

One can reuse the TV as screen (like in my good old C64 days).
Concerning keyboards, a Cherry G83 for <EUR20 works, even if it does
not satisfy the refined taste of a keyboard connoisseur.  Anyway,
desktop PCs are typically offered without screen and keyboard these
days, so I would not include that in his $100 price tag.

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#53036

On 02/12/2016 10:50, Anton Ertl wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>>
>>
>> On 02/12/2016 7:52, polymorph self wrote:
>>
>>> So there is no hope for a $100 forth desktop pc? with less code that can use online email and bank websites? with nice browser?
>>
>> Sure there is!  But you'll have to invest $10M to get it developed and
>> another $100M to advertise it and get it adopted.
> 
> Intel Compute Sticks start at EUR 95.89, so should be be available for
> around $100.  Install Linux and, say, Gforth on it, and you have a
> Forth desktop PC for $100.

No, you don't understand qwerty.  He wants all the software to be Forth,
from the OS on up.  Installing Gforth on Linux means you have all the
Linux stuff.  Bloat!  Slow! etc. etc. ad naseum.

For that matter, you can take a Raspberry Pi for $30 and add whatever
software you want for a lot less than $100... but it's (alas!) not a
Forth-based computer.

[toc] | [prev] | [next] | [standalone]

#53039

Ron Aaron <rambamist@gmail.com> writes:
>No, you don't understand qwerty.  He wants all the software to be Forth,
>from the OS on up.  Installing Gforth on Linux means you have all the
>Linux stuff.  Bloat!  Slow! etc. etc. ad naseum.

Sure, that's not just his dream.  My point is that you can get the
desktop PC hardware for $100 (or $30) now.

Concerning the software, there is the myth and dream of a pure Forth
software base that consumes much less resources.  And we have ForthOS
as a base (not sure if it runs on current cheap PCs), but somehow it
has not become very popular.

A problem with having your own OS kernel is that there is a huge
amount of hardware that you would need to have drivers for; even Linux
has this problem to some extent for the hardware in various smartphone
SoCs.  Anyway, using a Linux kernel seems to be a good way to
circumvent this problem; it costs some memory, but the speed is ok in
my experience.

So, the next step is to have the user space in Forth.  Many years ago
I did a proof-of-concept of using Gforth as init process.  These days
one would have to reimplement udev in Forth to do this properly.

Then one would have to write all the applications in Forth.  E.g., you
could use net2o as replacement for some internet programs.  However,
if you want to interface with existing web sites and enable
JavaScript, even if you have implemented the browser in Forth, you
get all the bloat, because the bloat is in the JavaScrupt programs.

>For that matter, you can take a Raspberry Pi for $30 and add whatever
>software you want for a lot less than $100... but it's (alas!) not a
>Forth-based computer.

It can be, to some extent.  The question ist: what's the point?

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#53040

On 02/12/2016 12:44, Anton Ertl wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>> No, you don't understand qwerty.  He wants all the software to be Forth,
>>from the OS on up.  Installing Gforth on Linux means you have all the
>> Linux stuff.  Bloat!  Slow! etc. etc. ad naseum.
...
>> For that matter, you can take a Raspberry Pi for $30 and add whatever
>> software you want for a lot less than $100... but it's (alas!) not a
>> Forth-based computer.
> 
> It can be, to some extent.  The question ist: what's the point?

Absolutely.

The point is (I think) just to endlessly spam the newsgroup.  What
benefit he derives from that, who knows?

An actual point *could* be made that if you (for example) booted a RPI
into a Forth shell, that *might* be a very powerful environment -- for
certain use-cases.  The RPI hardware isn't particularly fast, but it is
pretty reasonable nevertheless.  And as you point out, the Linux kernel
already has the drivers you need to interface with hardware.

I still can't really see the point of it, except as a Gedankenexperiment.

[toc] | [prev] | [next] | [standalone]

#53046

Ron Aaron:
> An actual point *could* be made that if you (for example) booted a RPI
> into a Forth shell

I've done that.  And connected it to a VT420 text terminal.
It's great!

[toc] | [prev] | [next] | [standalone]

#53062

On 02/12/2016 16:12, Lars Brinkhoff wrote:
> Ron Aaron:
>> An actual point *could* be made that if you (for example) booted a RPI
>> into a Forth shell
> 
> I've done that.  And connected it to a VT420 text terminal.
> It's great!

I'm sure it is!  What is the reason you did this, in particular?

[toc] | [prev] | [next] | [standalone]

#53890

Ron Aaron wrote:
> Lars Brinkhoff wrote:
>> Ron Aaron:
>>> An actual point *could* be made that if you (for example) booted a
>>> RPI into a Forth shell
>> I've done that.  And connected it to a VT420 text terminal.  It's
>> great!
>
> I'm sure it is!  What is the reason you did this, in particular?

To provide my kid with a basic programming environment.

[toc] | [prev] | [next] | [standalone]

#53891

On 01/09/2017 11:31, Lars Brinkhoff wrote:
> Ron Aaron wrote:
>> Lars Brinkhoff wrote:
>>> Ron Aaron:
>>>> An actual point *could* be made that if you (for example) booted a
>>>> RPI into a Forth shell
>>> I've done that.  And connected it to a VT420 text terminal.  It's
>>> great!
>>
>> I'm sure it is!  What is the reason you did this, in particular?
> 
> To provide my kid with a basic programming environment.

Interesting.  Did your kid get interested in programming/tech then?

[toc] | [prev] | [next] | [standalone]

#53894

Ron Aaron wrote:
>>>>> An actual point *could* be made that if you (for example) booted a
>>>>> RPI into a Forth shell
>>>> I've done that.  And connected it to a VT420 text terminal.  It's
>>>> great!
>>>
>>> I'm sure it is!  What is the reason you did this, in particular?
>> 
>> To provide my kid with a basic programming environment.
>
> Interesting.  Did your kid get interested in programming/tech then?

He's 3.5 years old, so no programming yet!  So far, he likes to type his
name using local echo.  But I think some simple games would be fun, like
Space Invaders.

Later, he may figure out there is a BYE command to get out of Forth, and
explore the system further.  Only maybe Forth will run inside a PDP-11
emulator, so there will be another layer to break out of.  Which will
get him to a PDP-10 HACTRN, etc, and eventually Linux.

[toc] | [prev] | [next] | [standalone]

#53895

On 01/09/2017 14:53, Lars Brinkhoff wrote:
> Ron Aaron wrote:
>>>>>> An actual point *could* be made that if you (for example) booted a
>>>>>> RPI into a Forth shell
>>>>> I've done that.  And connected it to a VT420 text terminal.  It's
>>>>> great!
>>>>
>>>> I'm sure it is!  What is the reason you did this, in particular?
>>>
>>> To provide my kid with a basic programming environment.
>>
>> Interesting.  Did your kid get interested in programming/tech then?
> 
> He's 3.5 years old, so no programming yet!  So far, he likes to type his
> name using local echo.  But I think some simple games would be fun, like
> Space Invaders.
> 
> Later, he may figure out there is a BYE command to get out of Forth, and
> explore the system further.  Only maybe Forth will run inside a PDP-11
> emulator, so there will be another layer to break out of.  Which will
> get him to a PDP-10 HACTRN, etc, and eventually Linux.
> 

Heh.  By the time he's 7 he'll have rewritten the kernel... better watch
out!

[toc] | [prev] | [next] | [standalone]

#53899

Am Montag, 9. Januar 2017 13:59:59 UTC+1 schrieb Ron Aaron:

> Heh.  By the time he's 7 he'll have rewritten the kernel... better watch
> out!


:-)  but don't bet on it - he'll detect smart phones before the time

[toc] | [prev] | [next] | [standalone]

#53903

minforth@arcor.de wrote:
> Ron Aaron:
>> Heh.  By the time he's 7 he'll have rewritten the kernel... better
>> watch out!
>
> :-)  but don't bet on it - he'll detect smart phones before the time

He already has, but apparently, he thinks the terminal is just as fun as
a smartphone.  Kids never cease to surprise you.

[toc] | [prev] | [next] | [standalone]

#53057

On Fri, 02 Dec 2016 10:44:21 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Concerning the software, there is the myth and dream of a pure Forth
> software base that consumes much less resources.

Even if that Forth dream of fewer resources was true, which I doubt,
transformative technologies can't simply be equivalent, or marginally
superior, or be a substitute good.  They must be radically superior in
order to displace the "good enough" solution that's currently in use.

Also, in the time that is needed to implement such a system, existing
microprocessors will double in speed, perhaps multiple times. So, the
real goal becomes designing a Forth processor and computer that is
perhaps 3200% faster than what exists today just to match the growth of
existing processors 5 years in the future.  For this computer to be
transformative, it would need to be 10 years ahead of it's time, and be
developed in under five years.  Such rapid advancement is usually a
nearly insurmountable goal.

> A problem with having your own OS kernel is that there is a huge
> amount of hardware that you would need to have drivers for; even Linux
> has this problem to some extent for the hardware in various smartphone
> SoCs.

Yes, the "simple" computing hardware of the 8-bit microprocessor
computer era has been over for a long time now.  Forth as an OS is
doable and has been done, but is not realistic for modern computer
users simply due to the lack of Forth software.  Situations which have
dedicated Forth applications are fine, e.g., embedded.

> Anyway, using a Linux kernel seems to be a good way to
> circumvent this problem; it costs some memory, but the speed is ok in
> my experience.
> 
> So, the next step is to have the user space in Forth.

...

> Then one would have to write all the applications in Forth.

What's wrong with translation of C code? e.g., C2Forth etc.  It would
require far less time to convert C code to Forth than to write Forth
code from scratch.  Many translated programs wouldn't need any further
work, i.e., low-use or no need for major improvements.  Only a few
programs would likely need to be coded in Forth from nothing.  This
would likely either be for efficiency or code maintainability.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#53058

On 12/2/16 8:58 PM, Rod Pemberton wrote:
>> Then one would have to write all the applications in Forth.
> What's wrong with translation of C code? e.g., C2Forth etc.  It would
> require far less time to convert C code to Forth than to write Forth
> code from scratch.  Many translated programs wouldn't need any further
> work, i.e., low-use or no need for major improvements.  Only a few
> programs would likely need to be coded in Forth from nothing.  This
> would likely either be for efficiency or code maintainability.

That is actually something that has been done a number of times (at 
least 10 in my direct personal experience), in real world projects. In 
fact, it's quite a lot faster to write original Forth from scratch, 
using the C version as a specification. You have to use that spec for 
*what* is being done, rather than *how*, because the economics of Forth 
are so very different: like building with steel and concrete instead of 
bricks requires very different strategies. A direct translation of C 
would be hideously inefficient and unmaintainable. A re-implemented 
version can work fine. The major issue is more convincing management 
rather than technical issues.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.forth

csiph-web