Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Beeping is cute, if you are in the office ;) -- Alan Cox


devel / comp.lang.forth / Re: Forth CPU on an FPGA Wanted

SubjectAuthor
* Forth CPU on an FPGA WantedChristopher Lozinski
+- Re: Forth CPU on an FPGA WantedJames Brakefield
+* Re: Forth CPU on an FPGA WantedPaul Rubin
|`* Re: Forth CPU on an FPGA WantedJames Brakefield
| +* Re: Forth CPU on an FPGA WantedPaul Rubin
| |+* Re: Forth CPU on an FPGA WantedJames Brakefield
| ||`* Re: Forth CPU on an FPGA WantedPaul Rubin
| || +- Re: Forth CPU on an FPGA Wanteddxforth
| || `* Re: Forth CPU on an FPGA WantedJames Brakefield
| ||  `* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   +* Re: Forth CPU on an FPGA WantedJames Brakefield
| ||   |`* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   | `* Re: Forth CPU on an FPGA WantedStephen Pelc
| ||   |  `- Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   +* Re: Forth CPU on an FPGA WantedAnton Ertl
| ||   |+* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   ||+- Re: Forth CPU on an FPGA Wantednone
| ||   ||`- Re: Forth CPU on an FPGA WantedAnton Ertl
| ||   |`* Re: Forth CPU on an FPGA Wantedminf...@arcor.de
| ||   | +* Re: Forth CPU on an FPGA Wantednone
| ||   | |`* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   | | `* Re: Forth CPU on an FPGA Wantednone
| ||   | |  `- Re: Forth CPU on an FPGA WantedPaul Rubin
| ||   | `* Re: Forth CPU on an FPGA WantedAnton Ertl
| ||   |  `* Re: Forth CPU on an FPGA WantedJames Brakefield
| ||   |   +- Re: Forth CPU on an FPGA WantedJurgen Pitaske
| ||   |   +* Re: Forth CPU on an FPGA WantedJon Nicoll
| ||   |   |+* Re: Forth CPU on an FPGA Wantedminf...@arcor.de
| ||   |   ||`- Re: Forth CPU on an FPGA WantedJurgen Pitaske
| ||   |   |+- Re: Forth CPU on an FPGA WantedJurgen Pitaske
| ||   |   |`- Re: Forth CPU on an FPGA WantedAlexander Wegel
| ||   |   +- Re: Forth CPU on an FPGA Wantedminf...@arcor.de
| ||   |   +* Re: Forth CPU on an FPGA WantedBrian Fox
| ||   |   |`- Re: Forth CPU on an FPGA Wanteddxforth
| ||   |   `- Re: Forth CPU on an FPGA WantedMe Unknown
| ||   `* Re: Forth CPU on an FPGA WantedRick C
| ||    `* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||     +* Re: Forth CPU on an FPGA Wanteddxforth
| ||     |`* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||     | +- Re: Forth CPU on an FPGA Wanteddxforth
| ||     | `* Re: Forth CPU on an FPGA WantedAnton Ertl
| ||     |  `* Re: Forth CPU on an FPGA Wanteddxforth
| ||     |   +* Re: Forth CPU on an FPGA WantedStephen Pelc
| ||     |   |`* Re: Forth CPU on an FPGA WantedMarcel Hendrix
| ||     |   | +- Re: Forth CPU on an FPGA Wanteddxforth
| ||     |   | `* Re: Forth CPU on an FPGA WantedAndy Valencia
| ||     |   |  +- Re: Forth CPU on an FPGA WantedPaul Rubin
| ||     |   |  +* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||     |   |  |+* Re: Forth CPU on an FPGA Wanteddxforth
| ||     |   |  ||`* Re: Forth CPU on an FPGA WantedKrishna Myneni
| ||     |   |  || `- Re: Forth CPU on an FPGA Wanteddxforth
| ||     |   |  |`- Re: Forth CPU on an FPGA WantedS Jack
| ||     |   |  `* Re: Forth CPU on an FPGA WantedAndy Valencia
| ||     |   |   `- Re: Forth CPU on an FPGA WantedPaul Rubin
| ||     |   `* Re: Forth CPU on an FPGA WantedAnton Ertl
| ||     |    `- Re: Forth CPU on an FPGA Wanteddxforth
| ||     +- Re: Forth CPU on an FPGA Wantednone
| ||     `* Re: Forth CPU on an FPGA WantedRick C
| ||      `* Re: Forth CPU on an FPGA WantedPaul Rubin
| ||       `* Re: Forth CPU on an FPGA WantedRick C
| ||        `- Re: Forth CPU on an FPGA WantedPaul Rubin
| |`* Re: Forth CPU on an FPGA WantedRick C
| | `* Re: Forth CPU on an FPGA WantedPaul Rubin
| |  `* Re: Forth CPU on an FPGA WantedRick C
| |   `* Re: Forth CPU on an FPGA WantedPaul Rubin
| |    `* Re: Forth CPU on an FPGA WantedRick C
| |     `- Re: Forth CPU on an FPGA WantedPaul Rubin
| +- Re: Forth CPU on an FPGA WantedMatthias Koch
| `- Re: Forth CPU on an FPGA WantedRick C
+- Re: Forth CPU on an FPGA WantedBrad Eckert
+- Re: Forth CPU on an FPGA WantedIlya Tarasov
+- Re: Forth CPU on an FPGA WantedBob Edwards
`* Re: Forth CPU on an FPGA WantedMatthias Koch
 `* Re: Forth CPU on an FPGA WantedMatthias Koch
  `- Re: Forth CPU on an FPGA WantedPaul Rubin

Pages:123
Re: Forth CPU on an FPGA Wanted

<0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13780&group=comp.lang.forth#13780

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:345:: with SMTP id 66mr31633753qkd.499.1625061517745; Wed, 30 Jun 2021 06:58:37 -0700 (PDT)
X-Received: by 2002:a05:620a:703:: with SMTP id 3mr16165467qkc.184.1625061517569; Wed, 30 Jun 2021 06:58:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 06:58:37 -0700 (PDT)
In-Reply-To: <2021Jun30.123352@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:a0d0:9f90:65f8:6947:4b2e:8ac7; posting-account=AoizIQoAAADa7kQDpB0DAj2jwddxXUgl
NNTP-Posting-Host: 2600:1700:a0d0:9f90:65f8:6947:4b2e:8ac7
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: jim.brak...@ieee.org (James Brakefield)
Injection-Date: Wed, 30 Jun 2021 13:58:37 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
 by: James Brakefield - Wed, 30 Jun 2021 13:58 UTC

On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:

ADA is used extensively in Europe for safety critical systems

Check out
https://www.adacore.com/about-ada
and
https://www.adacore.com/about-spark

> >If this is so important, why are there no Ada-based Forths around?
> Why should there be?

An ADA based Forth would do wonders for its stature.

> - 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 2021: https://euro.theforth.net/2021

Re: Forth CPU on an FPGA Wanted

<bf967cb3-ff4c-4ccc-9842-203bee42e178n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13781&group=comp.lang.forth#13781

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a0c:c3d1:: with SMTP id p17mr37066028qvi.44.1625065792722; Wed, 30 Jun 2021 08:09:52 -0700 (PDT)
X-Received: by 2002:a05:6214:1cb:: with SMTP id c11mr37423888qvt.47.1625065790414; Wed, 30 Jun 2021 08:09:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 08:09:50 -0700 (PDT)
In-Reply-To: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=85.210.153.81; posting-account=eAOrwQkAAABheFES5y-02sBOFdTlBRio
NNTP-Posting-Host: 85.210.153.81
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at> <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bf967cb3-ff4c-4ccc-9842-203bee42e178n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: jpita...@gmail.com (Jurgen Pitaske)
Injection-Date: Wed, 30 Jun 2021 15:09:52 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 77
 by: Jurgen Pitaske - Wed, 30 Jun 2021 15:09 UTC

On Wednesday, 30 June 2021 at 14:58:38 UTC+1, James Brakefield wrote:
> On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > "minf...@arcor.de" <minf...@arcor.de> writes:
>
> ADA is used extensively in Europe for safety critical systems
>
> Check out
> https://www.adacore.com/about-ada
> and
> https://www.adacore.com/about-spark
> > >If this is so important, why are there no Ada-based Forths around?
> > Why should there be?
> An ADA based Forth would do wonders for its stature.
> > - 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 2021: https://euro.theforth.net/2021

I am trying to grasp what the target is here:

Which performance is required?
If not known, any processor running a Forth would be good enough.
or the Core CPU in FPGAs with custiom IOs
Except if done for fun.

There are 2 books in the Forth Bookshelf:

1802 with FIG Forth as a starting point for FPGA
https://www.amazon.co.uk/gp/product/B01N42VLJE/ref=dbs_a_def_rwt_bibl_vppi_i14
More details in the Forth-eV Wiki

and

EP32 done by TING, and you can download the whole lot from many places
https://www.amazon.co.uk/gp/product/B00K6N87UG/ref=dbs_a_def_rwt_bibl_vppi_i20

The first decision for such a project is:
WHICH TARGET FPGA
I would recommend the TRENZ parts, as they are Breadboard friendly.
If a connection to external HW is not wanted or required - why not stay in the Simulation stage?,
Speed should not be an issue ...

And next decision is the toolchain, VHDL, VERILOG, ELSE

Which Forth Words should be implemented :
Here as well the question is target speed requirement.
Or more importantly:
WHAT IS THE TARGET APPLICATION?
If not known, any Forth implementation on a PC or microcontroller should be adequate.
Except for a hobby project.

Which FORTH should be used?
There are only 3 options I can see:
MPE VFX
FORTH INC's SW
One of the probably 100 free Forths
which are mostly incompatible, so it is a hard decision, as you would exclude all of the others
None of them is prepared for FPGA, except for mecrisp.

And to touch the point about ADA:
THIS IS A NO-NO FOR ANY FORTHER PROBABLY,
ALL THE USUAL FLEXIBILITY IS GONE:

it would mean to adhere/obey to pre-defined ADA rules
Not only this
but as well to adhere to the rather flexible Forth Standards which contradict the ADA targets...

Let's see what happens.
As there is no clear target definition,
the end result stays as open.

Re: Forth CPU on an FPGA Wanted

<c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13782&group=comp.lang.forth#13782

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:a18:: with SMTP id i24mr1948084qka.151.1625068529442;
Wed, 30 Jun 2021 08:55:29 -0700 (PDT)
X-Received: by 2002:ac8:74c8:: with SMTP id j8mr5828833qtr.367.1625068529078;
Wed, 30 Jun 2021 08:55:29 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 08:55:28 -0700 (PDT)
In-Reply-To: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=84.92.96.37; posting-account=xy4V0QkAAAAoGgkMsSsv6bfFPHkQXvOY
NNTP-Posting-Host: 84.92.96.37
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at>
<99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at>
<0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: jkn...@nicorp.f9.co.uk (Jon Nicoll)
Injection-Date: Wed, 30 Jun 2021 15:55:29 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Jon Nicoll - Wed, 30 Jun 2021 15:55 UTC

On Wednesday, June 30, 2021 at 2:58:38 PM UTC+1, James Brakefield wrote:
> On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > "minf...@arcor.de" <minf...@arcor.de> writes:
>
> ADA is used extensively in Europe for safety critical systems
>
> Check out
> https://www.adacore.com/about-ada
> and
> https://www.adacore.com/about-spark
> > >If this is so important, why are there no Ada-based Forths around?
> > Why should there be?
> An ADA based Forth would do wonders for its stature.

Rust would be the the 'safety-based' language-du-jour for this in 2021.

I have my doubts as to whether such a thing would do
either language any favours though.

J^n

Re: Forth CPU on an FPGA Wanted

<2ee19caa-02ef-448d-8b89-388dcb09cd0en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13783&group=comp.lang.forth#13783

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:4888:: with SMTP id i8mr23120530qtq.166.1625071497057;
Wed, 30 Jun 2021 09:44:57 -0700 (PDT)
X-Received: by 2002:ac8:40ca:: with SMTP id f10mr32646241qtm.319.1625071496902;
Wed, 30 Jun 2021 09:44:56 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 09:44:56 -0700 (PDT)
In-Reply-To: <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=79.224.105.219; posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 79.224.105.219
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at>
<99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at>
<0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com> <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2ee19caa-02ef-448d-8b89-388dcb09cd0en@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Wed, 30 Jun 2021 16:44:57 +0000
Content-Type: text/plain; charset="UTF-8"
 by: minf...@arcor.de - Wed, 30 Jun 2021 16:44 UTC

Jon Nicoll schrieb am Mittwoch, 30. Juni 2021 um 17:55:30 UTC+2:
> On Wednesday, June 30, 2021 at 2:58:38 PM UTC+1, James Brakefield wrote:
> > On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > > "minf...@arcor.de" <minf...@arcor.de> writes:
> >
> > ADA is used extensively in Europe for safety critical systems
> >
> > Check out
> > https://www.adacore.com/about-ada
> > and
> > https://www.adacore.com/about-spark
> > > >If this is so important, why are there no Ada-based Forths around?
> > > Why should there be?
> > An ADA based Forth would do wonders for its stature.
> Rust would be the the 'safety-based' language-du-jour for this in 2021.
>

For desktop applications or a desktop Forth system perhaps.
Rust's footprint is still too big for small devices.

Re: Forth CPU on an FPGA Wanted

<86fa02bc-8f0c-4afa-8dd0-16030391a320n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13785&group=comp.lang.forth#13785

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ad4:4bc6:: with SMTP id l6mr14477815qvw.42.1625077181862; Wed, 30 Jun 2021 11:19:41 -0700 (PDT)
X-Received: by 2002:a0c:a9d9:: with SMTP id c25mr2574079qvb.0.1625077181747; Wed, 30 Jun 2021 11:19:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 11:19:41 -0700 (PDT)
In-Reply-To: <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=85.210.153.81; posting-account=eAOrwQkAAABheFES5y-02sBOFdTlBRio
NNTP-Posting-Host: 85.210.153.81
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at> <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com> <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <86fa02bc-8f0c-4afa-8dd0-16030391a320n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: jpita...@gmail.com (Jurgen Pitaske)
Injection-Date: Wed, 30 Jun 2021 18:19:41 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
 by: Jurgen Pitaske - Wed, 30 Jun 2021 18:19 UTC

On Wednesday, 30 June 2021 at 16:55:30 UTC+1, Jon Nicoll wrote:
> On Wednesday, June 30, 2021 at 2:58:38 PM UTC+1, James Brakefield wrote:
> > On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > > "minf...@arcor.de" <minf...@arcor.de> writes:
> >
> > ADA is used extensively in Europe for safety critical systems
> >
> > Check out
> > https://www.adacore.com/about-ada
> > and
> > https://www.adacore.com/about-spark
> > > >If this is so important, why are there no Ada-based Forths around?
> > > Why should there be?
> > An ADA based Forth would do wonders for its stature.
> Rust would be the the 'safety-based' language-du-jour for this in 2021.
>
> I have my doubts as to whether such a thing would do
> either language any favours though.
>
> J^n

It is not clear, how RUST gets close to ADA.

Re: Forth CPU on an FPGA Wanted

<9d3fa741-0f7e-48d6-8fd3-c92920f99c19n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13786&group=comp.lang.forth#13786

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:9f04:: with SMTP id i4mr5813408qke.363.1625077233213; Wed, 30 Jun 2021 11:20:33 -0700 (PDT)
X-Received: by 2002:ac8:7156:: with SMTP id h22mr11736550qtp.17.1625077232980; Wed, 30 Jun 2021 11:20:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 11:20:32 -0700 (PDT)
In-Reply-To: <2ee19caa-02ef-448d-8b89-388dcb09cd0en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=85.210.153.81; posting-account=eAOrwQkAAABheFES5y-02sBOFdTlBRio
NNTP-Posting-Host: 85.210.153.81
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at> <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com> <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com> <2ee19caa-02ef-448d-8b89-388dcb09cd0en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9d3fa741-0f7e-48d6-8fd3-c92920f99c19n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: jpita...@gmail.com (Jurgen Pitaske)
Injection-Date: Wed, 30 Jun 2021 18:20:33 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 20
 by: Jurgen Pitaske - Wed, 30 Jun 2021 18:20 UTC

On Wednesday, 30 June 2021 at 17:44:57 UTC+1, minf...@arcor.de wrote:
> Jon Nicoll schrieb am Mittwoch, 30. Juni 2021 um 17:55:30 UTC+2:
> > On Wednesday, June 30, 2021 at 2:58:38 PM UTC+1, James Brakefield wrote:
> > > On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > > > "minf...@arcor.de" <minf...@arcor.de> writes:
> > >
> > > ADA is used extensively in Europe for safety critical systems
> > >
> > > Check out
> > > https://www.adacore.com/about-ada
> > > and
> > > https://www.adacore.com/about-spark
> > > > >If this is so important, why are there no Ada-based Forths around?
> > > > Why should there be?
> > > An ADA based Forth would do wonders for its stature.
> > Rust would be the the 'safety-based' language-du-jour for this in 2021.
> >
> For desktop applications or a desktop Forth system perhaps.
> Rust's footprint is still too big for small devices.

RUST to get close to ADA - WHY?

Re: Forth CPU on an FPGA Wanted

<eda61062-9a01-4c6f-9488-ae92143fa3f3n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13787&group=comp.lang.forth#13787

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:1026:: with SMTP id a6mr36839177qkk.331.1625078733126;
Wed, 30 Jun 2021 11:45:33 -0700 (PDT)
X-Received: by 2002:ae9:f30b:: with SMTP id p11mr3389928qkg.466.1625078733003;
Wed, 30 Jun 2021 11:45:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 30 Jun 2021 11:45:32 -0700 (PDT)
In-Reply-To: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=79.224.105.219; posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 79.224.105.219
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at>
<99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at>
<0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <eda61062-9a01-4c6f-9488-ae92143fa3f3n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Wed, 30 Jun 2021 18:45:33 +0000
Content-Type: text/plain; charset="UTF-8"
 by: minf...@arcor.de - Wed, 30 Jun 2021 18:45 UTC

James Brakefield schrieb am Mittwoch, 30. Juni 2021 um 15:58:38 UTC+2:
> On Wednesday, June 30, 2021 at 5:39:33 AM UTC-5, Anton Ertl wrote:
> > "minf...@arcor.de" <minf...@arcor.de> writes:
>
> ADA is used extensively in Europe for safety critical systems
>
> Check out
> https://www.adacore.com/about-ada
> and
> https://www.adacore.com/about-spark
> > >If this is so important, why are there no Ada-based Forths around?
> > Why should there be?
> An ADA based Forth would do wonders for its stature.

Would it kill those everlasting boring STATE-dependency discussions?
Certainly not.

Re: Forth CPU on an FPGA Wanted

<1pblyf8.6o8cdktbvsvaN%awegel@arcor.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13788&group=comp.lang.forth#13788

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!RqtRux2UIb+RYn66PKAUYw.user.gioia.aioe.org.POSTED!not-for-mail
From: awe...@arcor.de (Alexander Wegel)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Wed, 30 Jun 2021 22:34:02 +0200
Organization: Aioe.org NNTP Server
Lines: 8
Message-ID: <1pblyf8.6o8cdktbvsvaN%awegel@arcor.de>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at> <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com> <c0f297c3-5062-4963-b833-fba1616bbe4an@googlegroups.com>
NNTP-Posting-Host: RqtRux2UIb+RYn66PKAUYw.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: MacSOUP/D-2.8.5 (ea919cf118) (Mac OS 10.14.6)
X-Notice: Filtered by postfilter v. 0.9.2
 by: Alexander Wegel - Wed, 30 Jun 2021 20:34 UTC

Jon Nicoll <jkn_gg@nicorp.f9.co.uk> wrote:

> Rust would be the the 'safety-based' language-du-jour for this in 2021.
>
> I have my doubts as to whether such a thing would do
> either language any favours though.

Looks like there are one or two already.

Re: Forth CPU on an FPGA Wanted

<60DD03F0.5070602@rogers.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13789&group=comp.lang.forth#13789

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: brian....@rogers.com (Brian Fox)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Wed, 30 Jun 2021 19:53:20 -0400
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <60DD03F0.5070602@rogers.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <2021Jun30.123352@mips.complang.tuwien.ac.at> <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="cf6e945e1caeb0896c42680ca28cdf96";
logging-data="7428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+N9SdwOIoEzviQSv9+kVmCjzjx3Yn1aaQ="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
Cancel-Lock: sha1:SK1BR1zgIYX1YyxAxgyP8MKUxDY=
In-Reply-To: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
 by: Brian Fox - Wed, 30 Jun 2021 23:53 UTC

On 2021-06-30 9:58 AM, James Brakefield wrote:
>
> An ADA based Forth would do wonders for its stature.
>

Paul Bennett used Forth for Safety Critical systems for many years.
Perhaps he still does. (?)

In this age of fancy native code compilers, certifying a nice tidy
threaded Forth system can be simpler IMHO.

I am long out of industry but I should think a case could be made
for closer to metal programming being more reliable than machine
generated code that attempts to protect us from the real world.

I don't know of any literature to support my hypothesis however.

Re: Forth CPU on an FPGA Wanted

<sbj87d$lcq$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13790&group=comp.lang.forth#13790

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Thu, 1 Jul 2021 12:10:55 +1000
Organization: Aioe.org NNTP Server
Lines: 26
Message-ID: <sbj87d$lcq$1@gioia.aioe.org>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com> <2021Jun30.084236@mips.complang.tuwien.ac.at>
<99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com>
<2021Jun30.123352@mips.complang.tuwien.ac.at>
<0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
<60DD03F0.5070602@rogers.com>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Thu, 1 Jul 2021 02:10 UTC

On 1/07/2021 09:53, Brian Fox wrote:
> On 2021-06-30 9:58 AM, James Brakefield wrote:
>>
>> An ADA based Forth would do wonders for its stature.
>>
>
> Paul Bennett used Forth for Safety Critical systems for many years.
> Perhaps he still does. (?)
>
> In this age of fancy native code compilers, certifying a nice tidy
> threaded Forth system can be simpler IMHO.
>
> I am long out of industry but I should think a case could be made
> for closer to metal programming being more reliable than machine
> generated code that attempts to protect us from the real world.
>
> I don't know of any literature to support my hypothesis however.

Moore's own belief in minimalism which hasn't changed over the years?
A modern day Diogenes he's received much the same flack for his views
and stance. Including from forthers who assert 'that's impractical
for the modern era, you can't do that' :)

"Every age, and especially our own, stands in need of a Diogenes; but
the difficulty is in finding men who have the courage to be one, and
men who have the patience to endure one." - Jean le Rond d'Alembert

Re: Forth CPU on an FPGA Wanted

<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13804&group=comp.lang.forth#13804

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:7302:: with SMTP id x2mr2382124qto.16.1625274107931; Fri, 02 Jul 2021 18:01:47 -0700 (PDT)
X-Received: by 2002:a0c:a362:: with SMTP id u89mr2271661qvu.50.1625274107795; Fri, 02 Jul 2021 18:01:47 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Fri, 2 Jul 2021 18:01:47 -0700 (PDT)
In-Reply-To: <87tulggrhe.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=72.50.0.29; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 72.50.0.29
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87wnqjnie9.fsf@nightsong.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sat, 03 Jul 2021 01:01:47 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 105
 by: Rick C - Sat, 3 Jul 2021 01:01 UTC

On Tuesday, June 29, 2021 at 7:50:55 PM UTC-4, Paul Rubin wrote:
> James Brakefield <jim.bra...@ieee.org> writes:
> >> I just mean "larger than just a Forth core", not large in absolute
> >> terms.
> >
> > Not sure of your background? I employ hardware and software with
> > equal skill.
> I mostly write web server backend code in real life these days, and have
> done some large-ish 32-bit embedded stuff. I dabble in hardware and
> smaller MCU's at a hobbyist level at most. But, "large FPGA project" is
> no different than "large software project" afaict. Yes some are large
> enough to need dozens of people, yet plenty can be done by 1 person.
> > Not so much a Forth CPU, rather the code density the goes with it.
> Koopman's book may have some comparisons of of code density between a
> Forth and traditional CPUs. I'll look when I get a chance. I doubt
> that Forth wins by all that much, if it wins at all. Yes you get short
> single opcodes for things like addition, but you also have to deal with
> stack juggling, get more stuff from memory, etc.
>
> Is a small difference in code density even that much of an advantage
> these days?

We've had discussions like this in the past... many times. They typically show you have done little if anything with Forth or stack processors. There is very little stack juggling in most applications. If there is it shows the presence of a poor programmer, a poor compiler or both. Compilers can do the same thing with Forth code that they do with C or any other language, optimize.

The code density doesn't come from stack instructions or even the starting language. It comes from the modularization and module reuse that Forth promotes and facilitates. You don't get that with clumsy languages.

> > And have often used direct threaded code when doing low level C or
> > assembler.
> Hmm, not sure how the DTC concept would apply in those cases, unless you
> mean old microcomputer compilers. I think these days, compilers produce
> native code.

Again, I think you are showing your ignorance. There is nothing incompatible between DTC and modern tools.

> > At one time the VHDL and Verilog compilers would report the numbers
> > and type of simple gates.... I've always understood digital computers
> > as an assembly of flip-flops and combinatorial logic.
> Maybe they still do, just like fancy compilers produce assembly code
> that you can inspect. But inspecting the assembly code is different
> from understanding the compiler, and some people want to understand the
> compiler.

Synthesis tools continue to produce logic counts and you can even see schematics of the logic. This is very useful when you desire to optimize a portion of the logic. You can work with a small function and see exactly what it produces for logic usage.

> > Likewise one doesn't need to understand the workings of an optimizing
> > Forth compiler as long as meaning is preserved.
> Yes, it's up to the user. It does seem to me that some Forthers choose
> to not use optimizing Forth compilers, instead preferring tools whose
> workings they understand. Others might be drawn to Forth because they
> can understand a simple Forth compiler, and then be willing to use an
> optimizing compiler since as you say, meaning is preserved.
>
> I can see that myself: I can understand (or in principle write) a simple
> Forth compiler or a simple C compiler. So I'm willing to use GCC even
> though it is complex and I can't understand it. Same goes for certain
> low level VLSI tools.

I don't have any particular need to "understand" the tools as long as they produce good results. It's figuring out what is wrong when you get poor results that is a PITA. Fortunately that happens seldom.

> But, at least at the moment, I don't know of such a thing as a simple
> Verilog compiler. I have no idea how I would go about writing one. So
> the FPGA process is mysterious, and therefore imho unappealing to the
> particular Forth sensibility that calls for understanding things.

There are open source HDL tools. I'm sure they aren't very difficult to view.

Even though I have no idea how to write an HDL tool, I understand how they work in the sense of knowing the code to write to produce what I want. Why would I need more? I can't reverse engineer the computer that controls my car ignition or the browser I'm writing this on either. So?

If the FPGA "process" is mysterious, then that's your limitation in using technology, not the FPGA process.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Re: Forth CPU on an FPGA Wanted

<87im1r7t38.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13805&group=comp.lang.forth#13805

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 00:30:03 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <87im1r7t38.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="18130"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vNMNRwBIwSgH8MC9LmzwY"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:tM64GUvE9zFjOU1Bd4mB7shsc7Y=
sha1:a8WROhpCUDe12xbMmtVsUuej038=
 by: Paul Rubin - Sat, 3 Jul 2021 07:30 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> There is very little stack juggling in most applications. If there is
> it shows the presence of a poor programmer, a poor compiler or both.

I'd be interested in seeing some Forth applications with very little
stack juggling. The ones I've looked at have considerable.

> Compilers can do the same thing with Forth code that they do with C or
> any other language, optimize.

They do that using register allocation just like C compilers, except
here we're talking about a stack cpu, so it remains to be seen whether
it has registers or PICK-like operations for this purpose.

> The code density doesn't come from stack instructions or even the
> starting language. It comes from the modularization and module reuse
> that Forth promotes and facilitates.

In that case, why not use a conventional cpu? OP said the attraction of
a stack cpu was code density.

> Again, I think you are showing your ignorance. There is nothing
> incompatible between DTC and modern tools.

Nothing stops you from using DTC, but it's a relatively inefficient
technique compared with generating native code. IIRC, SwiftForth
switched from ITC to native code when 32-bit processors arrived, because
native 32-bit code was denser. DTC is even less dense than ITC.

Here's a comparison of code density between various schemes if it
matters:

https://dercuano.github.io/notes/tiny-interpreters-for-microcontrollers.html

> I don't have any particular need to "understand" the tools as long as
> they produce good results.

Well that's nice for you, but (some) other users do find it important,
and that is a significant attraction of Forth to such users.

> Even though I have no idea how to write an HDL tool, I understand how
> they work in the sense of knowing the code to write to produce what I
> want. Why would I need more?

If your goal is to understand things rather than to produce things, that
is you want to be Mr. Spock instead of Harry Mudd, then obviously if you
don't understand your thing you have failed.

> If the FPGA "process" is mysterious, then that's your limitation in
> using technology, not the FPGA process.

The FPGA process is mysterious because the workings of the important dev
tools are all secret, afaict. That is different from normal compilers.
Even if (say) the Microsoft C compilre is closed source, it does the
about same stuff that other compilers do, that you can read books about.
So you can say you basically know how it works. But I don't know of
such books about HDL compilers.

Re: Forth CPU on an FPGA Wanted

<87eecf7ssr.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13806&group=comp.lang.forth#13806

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 00:36:20 -0700
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <87eecf7ssr.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<2021Jun30.084236@mips.complang.tuwien.ac.at>
<99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com>
<60dc4924$0$23424$e4fe514c@newszilla.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="18130"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18awdv5VKHD9xDiGNeT8Mpc"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:KOIA27H4ITaykT+BhGqQyVwN0Y0=
sha1:HG7vcaSvrXEf1JdyWeAQormhjBs=
 by: Paul Rubin - Sat, 3 Jul 2021 07:36 UTC

albert@cherry.(none) (albert) writes:
> Also I hate the trash talk that GCC cannot be understood.
> It is complex and a comprehensive understanding is quite an undertaking.
> However because it has a reasonable architecture and is reasonably
> documented, I managed to modify it in behalf of a customer.

That's reasonable but it doesn't give you a total understanding of the
compiler, like you can have of a small Forth or Lisp compiler.

Imagine a 100 page, complicated math proof which is well written and
organized into lemmas, etc. You can examine it lemma by lemma,
understand any individual lemma, etc. But can you present the whole
proof to a classroom and answer questions about it, without referring to
the paper or to notes, like you can with the familiar theorems of
calculus? That is the difference between GCC and a simple Forth.

> That is what matters.

What matters to you is what matters to YOU. What matters to someone
else may be different. It does seem to me, as an empirical observation,
that quite a few Forthers like Forth because it gives them 100%
comprehension of the software. That is something to take into account
when discussing Forth.

Re: Forth CPU on an FPGA Wanted

<sbp76l$1o8s$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13807&group=comp.lang.forth#13807

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 18:30:13 +1000
Organization: Aioe.org NNTP Server
Lines: 14
Message-ID: <sbp76l$1o8s$1@gioia.aioe.org>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
<87im1r7t38.fsf@nightsong.com>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Sat, 3 Jul 2021 08:30 UTC

On 3/07/2021 17:30, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> There is very little stack juggling in most applications. If there is
>> it shows the presence of a poor programmer, a poor compiler or both.
>
> I'd be interested in seeing some Forth applications with very little
> stack juggling. The ones I've looked at have considerable.

If by "stack juggling" one means 'I dislike the stack and would rather use
locals' then forth would be inadvisable for that person. It would be like
asking me to like C or Pascal - which isn't going to happen, regardless of
the excellent applications written in those languages. Experienced forthers
are well attuned to clumsy coding. It informs them they've made a poor
choice and need to reconsider.

Re: Forth CPU on an FPGA Wanted

<87a6n37ppg.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13808&group=comp.lang.forth#13808

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 01:43:07 -0700
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <87a6n37ppg.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
<87im1r7t38.fsf@nightsong.com> <sbp76l$1o8s$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="19230"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LDDnqi1Pr7EfY9joRqHgf"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:TSTG/V+GmL4c1NVK9fhBluHWnAM=
sha1:IXJLD4k/z6Aam7BydpkKC92FUBo=
 by: Paul Rubin - Sat, 3 Jul 2021 08:43 UTC

dxforth <dxforth@gmail.com> writes:
> If by "stack juggling" one means 'I dislike the stack and would rather
> use locals' then forth would be inadvisable for that person.

By stack juggling I just mean there is significant use of DUP, SWAP,
DROP, ROT, and related words in the program. I keep hearing that a
really well designed Forth program has its words take parameters in the
right order so that those stack operations are rarely used. But the
Forth programs I've looked at do use those words.

> Experienced forthers are well attuned to clumsy coding. It informs
> them they've made a poor choice and need to reconsider.

Ok, I'd be interested in seeing examples of programs where good choices
were made, so the code isn't clumsy.

Re: Forth CPU on an FPGA Wanted

<8735sv7osp.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13809&group=comp.lang.forth#13809

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 02:02:46 -0700
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <8735sv7osp.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<7be66fa2-5a9d-4ec9-9dd7-c1b4b7ff253an@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="19230"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KQoywpLTjBCQTnYfJRvr3"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:J6EvtL35yON0L53/DxL4jcAGuTo=
sha1:fL2Tx5kKOvdZY1v9PqA3xPA3ji0=
 by: Paul Rubin - Sat, 3 Jul 2021 09:02 UTC

James Brakefield <jim.brakefield@ieee.org> writes:
> Ugh, Koopman hasn't done anything stack computer related in 30 years!

Has anything new happened in the field since then?

> It is now common terminology to use the terms direct threaded code,
> indirect threaded code, byte code, subroutine threaded code and
> in-lined code with respect to different Forth compilation techniques.

I'm familiar with DTC, ITC, bytecode (TTC), and STC. Not sure what you
mean by in-lined, if not direct generation of native machine code.

> So a Verilog compiler does a rough translation to some templates of
> basic functions (including muxes, priority encoders and decoders) and
> lets the optimizer reduce and simplify the translation. That's my
> guess.

That might be ok as a wide outline, but it completely misses every level
of detail. If you want to write a C compiler, there are tons of
compiler books such as the famous Dragon books:

https://en.wikipedia.org/wiki/Dragon_Book

If you read one those books it will tell you in detail how to implement
every phase of a compiler: scanning, parsing, symbol tables, type
checking, semantic analysis, code generation, register allocation,
peephole optimizations, etc. You can write a quite serious compiler by
just reading the book and coding the stuff it says. In fact GCC was
originally basically written that way.

I don't know of anything like that for HDL. That's what I mean about
mystery.

> I grew up on tinker toys and erector sets. The knack for building things
> out of small standard parts is necessary (take for instance music).

There is more to it than that. Reaching a usable high level
organization of a large program like a compiler, or a large piece of
music like a symphony, takes quite a bit of understanding of existing
knowledge in those fields. Mozart and Beethoven both had significant
amounts of formal composition instruction before they wrote their famous
works. You can't build a usable suspension bridge starting with the
instructions for erector sets: you have to study civil engineering.

The thing about Forth is that it's simple enough that you can implement
it with just a bit of cleverness and understanding, rather than a lot of
pointy headed compiler theory. It's like building a cabin or bookshelf
with a hammer and saw, based on your earlier experience with erector
sets. It's beautiful and satisfying, and that's a good enough reason to
do it. But you usually can't scale that approach to building a
skyscraper or airliner.

Re: Forth CPU on an FPGA Wanted

<87y2an69yp.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13810&group=comp.lang.forth#13810

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 02:08:30 -0700
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <87y2an69yp.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<cb1cdfa6-44f9-4ada-9a4a-db1ab50eb2b0n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="19230"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ZVrUy/U8g24tffLEwEZ4a"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:rWJO7+VwBo2zzrmZxJkgWxzxnYI=
sha1:zDMzxB6QiYz6lWxJsu5vNqJN1sA=
 by: Paul Rubin - Sat, 3 Jul 2021 09:08 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Many people start a CPU design because it seems like a cool thing to
> do, but have no real requirements. I've rolled a couple of small
> stack processors to do specific jobs and they worked well.

Yes, that's why I kept asking why this thread was started. Why would
you roll a processor to do a specific job? The most obvious reason
(other than that it's cool) is you're using an FPGA to implement
particular timing sensitive functions that you can't do with normal
software on a cpu, and then you need some kind of controller on the FPGA
to organize those functions, so you roll a stack processor. That's
great, but it means the stack processor is no longer the hardware end
goal-- it's part of a larger system.

Re: Forth CPU on an FPGA Wanted

<sbpafa$vk2$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13811&group=comp.lang.forth#13811

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 19:26:02 +1000
Organization: Aioe.org NNTP Server
Lines: 26
Message-ID: <sbpafa$vk2$1@gioia.aioe.org>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87wnqjnie9.fsf@nightsong.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
<87im1r7t38.fsf@nightsong.com> <sbp76l$1o8s$1@gioia.aioe.org>
<87a6n37ppg.fsf@nightsong.com>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Sat, 3 Jul 2021 09:26 UTC

On 3/07/2021 18:43, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> If by "stack juggling" one means 'I dislike the stack and would rather
>> use locals' then forth would be inadvisable for that person.
>
> By stack juggling I just mean there is significant use of DUP, SWAP,
> DROP, ROT, and related words in the program. I keep hearing that a
> really well designed Forth program has its words take parameters in the
> right order so that those stack operations are rarely used. But the
> Forth programs I've looked at do use those words.

It means using those words appropriately. I've seen SWAP CMOVE enough
times to make me wonder whether the latter was designed incorrectly.

>
>> Experienced forthers are well attuned to clumsy coding. It informs
>> them they've made a poor choice and need to reconsider.
>
> Ok, I'd be interested in seeing examples of programs where good choices
> were made, so the code isn't clumsy.

Clumsy to whom? You've seen my TPINST.LST. I've updated/revised it
to the point where I'd struggle to improve it. I don't claim it to be
clever - just well-factored according to the scope of the application.

https://pastebin.com/asr127zF

Re: Forth CPU on an FPGA Wanted

<2021Jul3.110521@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13812&group=comp.lang.forth#13812

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 03 Jul 2021 09:05:21 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 104
Message-ID: <2021Jul3.110521@mips.complang.tuwien.ac.at>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com> <87lf6xskde.fsf@nightsong.com> <67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com> <87mtrawurn.fsf@nightsong.com> <e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com> <87im1r7t38.fsf@nightsong.com> <sbp76l$1o8s$1@gioia.aioe.org> <87a6n37ppg.fsf@nightsong.com>
Injection-Info: reader02.eternal-september.org; posting-host="1fcbf9589a887c7556590dc5e6b341c0";
logging-data="3942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uYHsZvD3z1n4xq7S8kEKp"
Cancel-Lock: sha1:UM/f9MAcGyCohjfgsJBAVPjYbX0=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 3 Jul 2021 09:05 UTC

Paul Rubin <no.email@nospam.invalid> writes:
>dxforth <dxforth@gmail.com> writes:
>> If by "stack juggling" one means 'I dislike the stack and would rather
>> use locals' then forth would be inadvisable for that person.
>
>By stack juggling I just mean there is significant use of DUP, SWAP,
>DROP, ROT, and related words in the program. I keep hearing that a
>really well designed Forth program has its words take parameters in the
>right order so that those stack operations are rarely used. But the
>Forth programs I've looked at do use those words.

Sure they do. If these words were never used, they would not be
there. So designing the Forth program to avoid stack shuffling words
is an ideal, that is usually only partly achieved. Of course, you can
fully achieve it using locals, but that is heretical to the orthodox
Forthers; you can also achieve it by using VARIABLEs or USERs, which
in principle is the same (except that it is not reentrant without
extra work), but is acceptable to orthodox Forthers because the
prophet did it himself.

>Ok, I'd be interested in seeing examples of programs where good choices
>were made, so the code isn't clumsy.

A nice example is integer-to-string conversion in Forth, which is
achieved in very flexible ways using the words <# # #S HOLD SIGN #>.

E.g., if you want to print an unsigned single-cell number with at
least 8 digits (possibly leading zeros), you can do it as follows:

: .8 0 <# # # # # # # # #S #> type ;

You certainly have some stack juggling inside the component words, but
you don't need any stack juggling in .8. The important design element
in this is the hold buffer. In classical Forth it makes these words
non-reentrant, but in Gforth we have added <<# #>> to allow
reentrancy: <<# starts a new hold buffer and #>> deallocates it. So
you can make a reentrant .8 as follows:

: .8 0 <<# <# # # # # # # # #S #> type #>> ;

A example of the ideal at work is
<http://www.complang.tuwien.ac.at/forth/objects/struct.fs>, described
in <http://www.complang.tuwien.ac.at/forth/objects/structs.html>:

In this package the alignment is passed around on the stack along with
the size, both for the fields, and for the structure up to now.
Originally, I passed them around in the order ( size align ), but that
means that one would have to write

cell% swap 2* swap field some-d

to define a double-cell field. Since it is common to do something
with the size and uncommon to do something with the alignment, I
switched the order to ( align size ), and now you can write

cell% 2* field some-d

An example where the alignment plays a role:

struct
float% field point-x
float% field point-y
end-struct point%

struct
cell% field rect-id
point% field rect-ll \ lower left coordinate
point% field rect-ur \ upper-right coordinate
end-struct rect%

The standard then took the approach of not passing the alignment
around. It has words like FIELD: or FFIELD: that include their
alignment, but if you want to, e.g., use a structure as a field, you
have to align manually; e.g.

0
field: rect-id
faligned point +field rect-ll
faligned point +field rect-ur
constant rect

where POINT is the size of a point structure. With some years of
distance, I think that the structure-as-field case is rare enough
(usually I use an address instead anyway) that the simplicity of the
standard approach is a win over the additional features of my
struct.fs.

Anyway, back to the topic of stack juggling: Both structure definition
word sets are examples of how to design words in a way that avoids
stack juggling. There is no stack juggling in the structure
definitions above.

Both structure word sets were inspired by a word set that is similar
to the above usage of the standard structure words that was posted
here in 1989. Unfortunately, I don't remember who posted it. In the
web page linked to above I guessed John Hayes, but another name that
pops up in my head is Mitch Bradley.

- 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 2021: https://euro.theforth.net/2021

Re: Forth CPU on an FPGA Wanted

<sbpfmq$135j$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13813&group=comp.lang.forth#13813

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 20:55:22 +1000
Organization: Aioe.org NNTP Server
Lines: 19
Message-ID: <sbpfmq$135j$1@gioia.aioe.org>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<4f0e5e87-72d0-45e9-b257-7d4fac2bfc8an@googlegroups.com>
<87lf6xskde.fsf@nightsong.com>
<67693a3b-bf4b-4599-b978-4d198165b15fn@googlegroups.com>
<87mtrawurn.fsf@nightsong.com>
<e70ef9ff-b468-4487-9a54-07369f638240n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
<87im1r7t38.fsf@nightsong.com> <sbp76l$1o8s$1@gioia.aioe.org>
<87a6n37ppg.fsf@nightsong.com> <2021Jul3.110521@mips.complang.tuwien.ac.at>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Sat, 3 Jul 2021 10:55 UTC

On 3/07/2021 19:05, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>dxforth <dxforth@gmail.com> writes:
>>> If by "stack juggling" one means 'I dislike the stack and would rather
>>> use locals' then forth would be inadvisable for that person.
>>
>>By stack juggling I just mean there is significant use of DUP, SWAP,
>>DROP, ROT, and related words in the program. I keep hearing that a
>>really well designed Forth program has its words take parameters in the
>>right order so that those stack operations are rarely used. But the
>>Forth programs I've looked at do use those words.
>
> Sure they do. If these words were never used, they would not be
> there. So designing the Forth program to avoid stack shuffling words
> is an ideal, that is usually only partly achieved.
Except it's not "shuffling". Stack operators are essential to a stack-based
language as locals are to a variable-based language. Nobody argues avoiding
locals in C is the ideal which is only partly achieved. The aim, rather, is
to use things that are intrinsic to the language intelligently.

Re: Forth CPU on an FPGA Wanted

<nnd$213ede4a$6528e99f@3f7ea8d48c4748e0>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13815&group=comp.lang.forth#13815

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com> <60dc4924$0$23424$e4fe514c@newszilla.xs4all.nl> <87eecf7ssr.fsf@nightsong.com>
Subject: Re: Forth CPU on an FPGA Wanted
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$213ede4a$6528e99f@3f7ea8d48c4748e0>
Organization: KPN B.V.
Date: Sat, 03 Jul 2021 13:06:01 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!feed.abavia.com!abe002.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 45
Injection-Date: Sat, 03 Jul 2021 13:06:01 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Sat, 3 Jul 2021 11:06 UTC

In article <87eecf7ssr.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>albert@cherry.(none) (albert) writes:
>> Also I hate the trash talk that GCC cannot be understood.
>> It is complex and a comprehensive understanding is quite an undertaking.
>> However because it has a reasonable architecture and is reasonably
>> documented, I managed to modify it in behalf of a customer.
>
>That's reasonable but it doesn't give you a total understanding of the
>compiler, like you can have of a small Forth or Lisp compiler.
>
>Imagine a 100 page, complicated math proof which is well written and
>organized into lemmas, etc. You can examine it lemma by lemma,
>understand any individual lemma, etc. But can you present the whole
>proof to a classroom and answer questions about it, without referring to
>the paper or to notes, like you can with the familiar theorems of
>calculus? That is the difference between GCC and a simple Forth.

Yes, so what? Do you understand the proof of Fermat's conjecture?
Is that relevant?

>
>> That is what matters.
>
>What matters to you is what matters to YOU. What matters to someone
>else may be different. It does seem to me, as an empirical observation,
>that quite a few Forthers like Forth because it gives them 100%
>comprehension of the software. That is something to take into account
>when discussing Forth.

This also matters to me, and I'm working on a simple Forth, to illustrate
that.
What I explained matters to GCC users a great deal.
GCC does a lot and is inherently complicated.
I worked on a real problem for a real client, implicating millions
of turnover, possibly the future of the company. The goal was not
to have insight in how compilers work.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Forth CPU on an FPGA Wanted

<sbph0r$q5h$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13816&group=comp.lang.forth#13816

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: step...@vfxforth.com (Stephen Pelc)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 11:17:47 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <sbph0r$q5h$1@dont-email.me>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <7be66fa2-5a9d-4ec9-9dd7-c1b4b7ff253an@googlegroups.com> <8735sv7osp.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=fixed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 3 Jul 2021 11:17:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="260bd3b0f4ad48e5e8e4bd0a2b8af362";
logging-data="26801"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OlaJIxsNwXYRH5FcyX4wa"
User-Agent: Usenapp/1.09/l for MacOS - Full License
Cancel-Lock: sha1:4Fd3GBJtRI8mouVqmJsTtxqLRGs=
 by: Stephen Pelc - Sat, 3 Jul 2021 11:17 UTC

On 3 Jul 2021 at 11:02:46 CEST, "Paul Rubin" <no.email@nospam.invalid> wrote:

> Has anything new happened in the field since then?

There have been designs and papers by Crispin Bailey (Uni Teesside, Uni York)
and Klaus Scleisiek (MicroCore) among others. These use industry standard
design and layout tools, so can adapt quickly to updated devices and
processes.

>> It is now common terminology to use the terms direct threaded code,
>> indirect threaded code, byte code, subroutine threaded code and
>> in-lined code with respect to different Forth compilation techniques.
>
> I'm familiar with DTC, ITC, bytecode (TTC), and STC. Not sure what you
> mean by in-lined, if not direct generation of native machine code.

Binary or source inlining are just some of the tricks used by code
generators. I prefer to call systems that assume good optimisation
'Native Code Compilers' (NCC).

> The thing about Forth is that it's simple enough that you can implement
> it with just a bit of cleverness and understanding, rather than a lot of
> pointy headed compiler theory. It's like building a cabin or bookshelf
> with a hammer and saw, based on your earlier experience with erector
> sets. It's beautiful and satisfying, and that's a good enough reason to
> do it. But you usually can't scale that approach to building a
> skyscraper or airliner.

Unless you know some of the compiler theory, you will not know how to
deal with some of the problems, e.g. disambiguation was an unpleasant
surprise in the early VFX development.

Stephen

Re: Forth CPU on an FPGA Wanted

<sbph8u$rtf$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13817&group=comp.lang.forth#13817

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: step...@vfxforth.com (Stephen Pelc)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 11:22:06 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <sbph8u$rtf$1@dont-email.me>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87a6n37ppg.fsf@nightsong.com> <2021Jul3.110521@mips.complang.tuwien.ac.at> <sbpfmq$135j$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=fixed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 3 Jul 2021 11:22:06 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="260bd3b0f4ad48e5e8e4bd0a2b8af362";
logging-data="28591"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/DUMBVhWWDBRsHqGPXfsiD"
User-Agent: Usenapp/1.09/l for MacOS - Full License
Cancel-Lock: sha1:nOnheQyZYYAwKGeNOob69kehAeY=
 by: Stephen Pelc - Sat, 3 Jul 2021 11:22 UTC

On 3 Jul 2021 at 12:55:22 CEST, "dxforth" <dxforth@gmail.com> wrote:

>> Sure they do. If these words were never used, they would not be
>> there. So designing the Forth program to avoid stack shuffling words
>> is an ideal, that is usually only partly achieved.
> Except it's not "shuffling". Stack operators are essential to a stack-based
> language as locals are to a variable-based language. Nobody argues avoiding
> locals in C is the ideal which is only partly achieved. The aim, rather, is
> to use things that are intrinsic to the language intelligently.

Hear, Hear!

Stephen

Re: Forth CPU on an FPGA Wanted

<nnd$4fee5075$4f755cd0@c204aead7d4f1150>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13818&group=comp.lang.forth#13818

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com> <87tulggrhe.fsf@nightsong.com> <1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com> <87im1r7t38.fsf@nightsong.com>
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$4fee5075$4f755cd0@c204aead7d4f1150>
Organization: KPN B.V.
Date: Sat, 03 Jul 2021 13:27:19 +0200
Path: i2pn2.org!i2pn.org!news.swapon.de!2.eu.feeder.erje.net!feeder.erje.net!feed.abavia.com!abe002.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 199
Injection-Date: Sat, 03 Jul 2021 13:27:19 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Sat, 3 Jul 2021 11:27 UTC

In article <87im1r7t38.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> There is very little stack juggling in most applications. If there is
>> it shows the presence of a poor programmer, a poor compiler or both.
>
>I'd be interested in seeing some Forth applications with very little
>stack juggling. The ones I've looked at have considerable.

The tingle tangle video on youtube plays the following program
===================================================================
\ $Id: landmann.sco,v 1.4 2018/09/26 12:52:52 albert Exp $
\ Copyright (2018): Albert van der Horst {by GNU Public License}

' rest alias %
' chord alias {}

\ $Id: landmann.sco,v 1.4 2018/09/26 12:52:52 albert Exp $
\ Copyright (2018): Albert van der Horst {by GNU Public License}

' rest alias %
' chord alias {}

\ : ORGAN SPEAKER ;
SCORE Landmann
DEFAULT: 112 /4 MM 6 TRANSPOSE-UP

INFO: Schumann: Froehlicher Landmann transformed by AH & CH

PART one
PDEFAULT: SILVER \ 4 TRANSPOSE-UP
||: 4 /4 MEASURE /8 C2 |
L: m1 /4. F2 /8 A2 /4. C3 /8 F2 |
/8 BES2 D3 F3 D3 /4. C3 /8 A2 |
L: m3 /8 BES2 G2 C2 BES2 A2 F2 C2 A2 |
L: m4 /4 E2 D2 C2 /8 % C2 |
m1 .. m4 bis |
L: m9 /4. G2 /8 F2 /4. E2 /8 C2 |
L: m10 /8 G2 F2 E2 D2 /4. E2 /8 C2 |
m1 .. m3 bis
/4 { BES1 G2 } { C2 E2 } F2 /8 % C2 |
m9 .. m10 bis
m1 .. m3 bis
/4 { BES1 G2 } { C2 E2 } F2 % ||

PART two
\ PDEFAULT: GOLD
PDEFAULT: ORGAN L2
||: 4 /4 MEASURE /8 % |
L: m1 /8 % { C3 F3 A3 } {} % % { F3 A3 C4 } {} % |
/8 % { F3 BES3 D4 } {} % % { F3 A3 C4 } {} % |
L: m3 /8 % { E3 BES3 C4 } {} % % { C3 F3 A3 } {} % |
/8 % { C3 G3 } % { F3 G3 B3 } % { E3 G3 C4 } /4 {} |
m1 .. m3 bis
/8 % { C3 G3 } % { F3 G3 B3 } % { E3 G3 C4 } {} % |
L: m9 /8 % { C3 E3 } {} % % { BES2 C3 } {} % |
/8 % C3 C3 B2 % C3 C3 % |
/8 % { C3 E3 } {} % % { F3 A3 } {} % |
/8 % { F3 BES3 } % {} % { F3 A3 } {} % |
/8 % { E3 BES3 C4 } {} % % { C3 F3 A3 } {} {} |
L: m14 /8 % { D3 G3 } % { BES2 C3 } % { A2 C3 F3 } {} % |
m9 .. m14 bis ||

PART three
\ PDEFAULT: GOLD
PDEFAULT: ORGAN L8
||: 4 /4 MEASURE /8 % |
L: m1 whole rest |
whole rest |
L: m3 whole rest |
whole rest |
m1 .. m3 bis
L: m8 /4 % % % /8 % C3 |
/4. BES3 /8 A3 /4. G3 /8 C3 |
L6 /8 BES3 A3 G3 F3 L8 /4. G3 /8 C3 |
/4. F3 /8 A3 /4. C4 /8 F3 |
/8 BES3 D4 F4 D4 /4. C4 /8 % |
L: m13 whole rest |
m8 .. m13 bis
whole rest |
whole rest ||
\ : ORGAN SPEAKER ;
SCORE Landmann
DEFAULT: 112 /4 MM 6 TRANSPOSE-UP

INFO: Schumann: Froehlicher Landmann transformed by AH & CH

PART one
PDEFAULT: SILVER \ 4 TRANSPOSE-UP
||: 4 /4 MEASURE /8 C2 |
L: m1 /4. F2 /8 A2 /4. C3 /8 F2 |
/8 BES2 D3 F3 D3 /4. C3 /8 A2 |
L: m3 /8 BES2 G2 C2 BES2 A2 F2 C2 A2 |
L: m4 /4 E2 D2 C2 /8 % C2 |
m1 .. m4 bis |
L: m9 /4. G2 /8 F2 /4. E2 /8 C2 |
L: m10 /8 G2 F2 E2 D2 /4. E2 /8 C2 |
m1 .. m3 bis
/4 { BES1 G2 } { C2 E2 } F2 /8 % C2 |
m9 .. m10 bis
m1 .. m3 bis
/4 { BES1 G2 } { C2 E2 } F2 % ||

PART two
\ PDEFAULT: GOLD
PDEFAULT: ORGAN L2
||: 4 /4 MEASURE /8 % |
L: m1 /8 % { C3 F3 A3 } {} % % { F3 A3 C4 } {} % |
/8 % { F3 BES3 D4 } {} % % { F3 A3 C4 } {} % |
L: m3 /8 % { E3 BES3 C4 } {} % % { C3 F3 A3 } {} % |
/8 % { C3 G3 } % { F3 G3 B3 } % { E3 G3 C4 } /4 {} |
m1 .. m3 bis
/8 % { C3 G3 } % { F3 G3 B3 } % { E3 G3 C4 } {} % |
L: m9 /8 % { C3 E3 } {} % % { BES2 C3 } {} % |
/8 % C3 C3 B2 % C3 C3 % |
/8 % { C3 E3 } {} % % { F3 A3 } {} % |
/8 % { F3 BES3 } % {} % { F3 A3 } {} % |
/8 % { E3 BES3 C4 } {} % % { C3 F3 A3 } {} {} |
L: m14 /8 % { D3 G3 } % { BES2 C3 } % { A2 C3 F3 } {} % |
m9 .. m14 bis ||

PART three
\ PDEFAULT: GOLD
PDEFAULT: ORGAN L8
||: 4 /4 MEASURE /8 % |
L: m1 whole rest |
whole rest |
L: m3 whole rest |
whole rest |
m1 .. m3 bis
L: m8 /4 % % % /8 % C3 |
/4. BES3 /8 A3 /4. G3 /8 C3 |
L6 /8 BES3 A3 G3 F3 L8 /4. G3 /8 C3 |
/4. F3 /8 A3 /4. C4 /8 F3 |
/8 BES3 D4 F4 D4 /4. C4 /8 % |
L: m13 whole rest |
m8 .. m13 bis
whole rest |
whole rest ||
===================================================================
The program creates a word of type SCORE, called Landmann

After loading you type
Landmann PLAY

IMHO this is a fine example of "extending the language".
You can use DUP ROT SWAP in this code, but it was nowhere necessary.

An other examply is the assembler in the ciforth blocks.
The first block has some benign stack handling:
------------------------------------------------------------
( ASSEMBLER-GENERIC SPLIT 1PI FIR 1FAMILY, ) \ B9jan27 AvdH
\ Post one byte of INSTRUCTION . Leave REMAINDER.
: POST DUP C, 8 RSHIFT ;
\ Fixup with ms byte of FIX below ADDR, leave next FIX ADDR
: FIX| 1- >R R@ OVER 0FF AND TOGGLE 8 RSHIFT R> ;
: 1PI CREATE , DOES> @ POST DROP ; \ post-it 1 byte opcode
: 2PI CREATE , DOES> @ POST POST DROP ; \ 2 byte
: 3PI CREATE , DOES> @ POST POST POST DROP ; \ 3 byte
\ Fixup from behind starting with ls byte.
: FIR CREATE , DOES> @ HERE BEGIN FIX| OVER 0= UNTIL 2DROP ;
: NO-- PP @ NAME PRESENT ?DUP IF HIDDEN THEN PP ! ;
\ Create a family adding INC to OPCODE with COUNT members
: 1FAMILY, 0 DO DUP NO-- 1PI OVER + LOOP DROP DROP ;
: 2FAMILY, 0 DO DUP NO-- 2PI OVER + LOOP DROP DROP ;
: 3FAMILY, 0 DO DUP NO-- 3PI OVER + LOOP DROP DROP ;
: FAMILY|R 0 DO DUP NO-- FIR OVER + LOOP DROP DROP ;

------------------------------------------------------------

Note that it is restricted to:
1. DUP : I need the top stack item twice
2. OVER : I need the next stack item twice
3. DROP : I need the top stack item no more.
Important is of course that there is no puzzle about
what the stack item presents.
Also notable, this runs on CORE wordset. The Forth language is
not even extended.
Then the remaining 10 screens of the assembler do not contain
a single (!) stack operation.

Another good example is the basic in Forth.
Yes there is a word DEFER that consists mainly of stack operations.
After that it is smooth sailing with few stack operations.
After that you can write BASIC. Of course BASIC doesnot contain stack
operations at all.

Let those examples supersede the silly washing machine example of Brody
that does not actually work.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Forth CPU on an FPGA Wanted

<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13819&group=comp.lang.forth#13819

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:4086:: with SMTP id f6mr5142893qko.95.1625317774417;
Sat, 03 Jul 2021 06:09:34 -0700 (PDT)
X-Received: by 2002:a0c:a9d9:: with SMTP id c25mr4419253qvb.0.1625317774299;
Sat, 03 Jul 2021 06:09:34 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sat, 3 Jul 2021 06:09:34 -0700 (PDT)
In-Reply-To: <sbph8u$rtf$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c05:2f14:600:a4f2:bcab:1d32:220f;
posting-account=-JQ2RQoAAAB6B5tcBTSdvOqrD1HpT_Rk
NNTP-Posting-Host: 2001:1c05:2f14:600:a4f2:bcab:1d32:220f
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87a6n37ppg.fsf@nightsong.com> <2021Jul3.110521@mips.complang.tuwien.ac.at>
<sbpfmq$135j$1@gioia.aioe.org> <sbph8u$rtf$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: mhx...@iae.nl (Marcel Hendrix)
Injection-Date: Sat, 03 Jul 2021 13:09:34 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Marcel Hendrix - Sat, 3 Jul 2021 13:09 UTC

On Saturday, July 3, 2021 at 1:22:08 PM UTC+2, Stephen Pelc wrote:
> On 3 Jul 2021 at 12:55:22 CEST, "dxforth" <dxf...@gmail.com> wrote:
>
> >> Sure they do. If these words were never used, they would not be
> >> there. So designing the Forth program to avoid stack shuffling words
> >> is an ideal, that is usually only partly achieved.
> > Except it's not "shuffling". Stack operators are essential to a stack-based
> > language as locals are to a variable-based language. Nobody argues avoiding
> > locals in C is the ideal which is only partly achieved. The aim, rather, is
> > to use things that are intrinsic to the language intelligently.
> Hear, Hear!

But what is 'intrinsic' in an extensible language? A 'local variable' is a variable
residing on a stack. Instead of '3 pick' one accesses it with a temporary name,
say "x". Forth handles the administration at compile time. It is not more
complicated or inefficient than e.g. IF or LOOP managing labels for branch
targets.

-marcel

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor