Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

I am NOT a kludge! I am a computer! -- tts


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

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

 copy mid

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

 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 13:02:17 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 56
Message-ID: <2021Jul3.150217@mips.complang.tuwien.ac.at>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@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> <sbpfmq$135j$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="1fcbf9589a887c7556590dc5e6b341c0";
logging-data="425"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18aOR35RRjqPGP72pBLwP7p"
Cancel-Lock: sha1:+N86asCfT6NOIV/661D3hc78mKk=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 3 Jul 2021 13:02 UTC

dxforth <dxforth@gmail.com> writes:
>On 3/07/2021 19:05, Anton Ertl wrote:
>> Paul Rubin <no.email@nospam.invalid> writes:
>>>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".

Sorry, I misspelled "juggling".

>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.

_All else being equal_, I prefer Forth code without stack manipulation
words to Forth code with. You don't?

As for avoiding locals in variable-based languages, newbies in such
languages typically do not say that they find the language hard to
read because of locals. So of course there is no need for a defender
of the language to step up and appease the newbie by promising that
with enough experience they will learn to design code such that no
locals are necessary.

And there is no cartoon in Chapter 2 of "Starting C" that says "I hate
locals". By contrast, in "Starting Forth" we have:

https://www.forth.com/starting-forth/2-stack-manipulation-operators-arithmetic/#ROT

That being said, there are indeed programming styles in variable-based
languages that reduce or eliminate variables, e.g.,

https://wiki.haskell.org/Pointfree

But note also

<https://wiki.haskell.org/Pointfree#Problems_with_pointfree>

Less radically, method chaining
<https://en.wikipedia.org/wiki/Method_chaining> and fluent interfaces
<https://en.wikipedia.org/wiki/Fluent_interface> lead to fewer (but
still some) variable references.

- 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

<sbpthd$lkl$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.c...@gmx.net (Matthias Koch)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sat, 3 Jul 2021 16:51:25 +0200
Organization: A noiseless patient Spider
Lines: 1
Message-ID: <sbpthd$lkl$1@dont-email.me>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<sb9rpt$j3t$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 3 Jul 2021 14:51:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7b5c98bbbe55d794650766b400e3f49e";
logging-data="22165"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HfFz1Zu3bZNyH62Z3QV3W"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:S3Vbb74f8nT+GKo6go7TwgDuNW4=
In-Reply-To: <sb9rpt$j3t$1@dont-email.me>
Content-Language: de-DE
 by: Matthias Koch - Sat, 3 Jul 2021 14:51 UTC

+ RV32IMC

Re: Forth CPU on an FPGA Wanted

<87tulb5qnw.fsf@nightsong.com>

 copy mid

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

 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 09:05:23 -0700
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <87tulb5qnw.fsf@nightsong.com>
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>
<nnd$213ede4a$6528e99f@3f7ea8d48c4748e0>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="22143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18pg9zyFNMSe0jVKWsSibZd"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:8B5zgTkDOg4W/CM6jV/p4JIq72I=
sha1:jVEX1ofmlEzg4yNG4mkYl28JNyY=
 by: Paul Rubin - Sat, 3 Jul 2021 16:05 UTC

albert@cherry.(none) (albert) writes:
> Yes, so what? Do you understand the proof of Fermat's conjecture?

No of course not, hardly anyone does.

> Is that relevant?

Yes, from Bill Thurston's "On Proof and Progress in Mathematics"
( https://arxiv.org/abs/math/9404236 ):

When I started working on foliations, I had the conception that what
people wanted was to know the answers. I thought that what they
sought was a collection of powerful proven theorems that might be
applied to answer further mathematical questions. But that’s only
one part of the story. More than the knowledge, people want
_personal understanding_.

> 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.

Of course we should refine the bit about "what matters" to: "what
matters depends both on you and the exact thing you are trying to do".
Your client wanted a direct route to a solution and didn't care much
about knowledge. That's fine, and it may even explain why they (or you)
chose to use GCC instead of Forth.

I also use GCC (or more often these days, Python) when I'm after a
direct solution. When I use Forth, I'm usually after something
different, since I find it takes me much longer to code something in
Forth than it would in e.g. Python. In my case it's something like
enjoying different flavors of programming experience and feeling like
I'm gaining something from exercising the Forth perspective, rather than
knowledge per se. It's certainly not for productivity since my
productivity in Forth is pretty low.

Some others do seek total understanding of the programming environment.
That's likely why some Forthers here still program on Z80 systems, or
write their own Forths instead of using existing ones. I understand
this appeal though I haven't really pursued it in Forth. I did have
that feeling when I programmed using a homebrew Lisp a while back, and I
found it satisfying.

Re: Forth CPU on an FPGA Wanted

<87pmvz5qgr.fsf@nightsong.com>

 copy mid

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

 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 09:09:40 -0700
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <87pmvz5qgr.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<87tulggrhe.fsf@nightsong.com>
<7be66fa2-5a9d-4ec9-9dd7-c1b4b7ff253an@googlegroups.com>
<8735sv7osp.fsf@nightsong.com> <sbph0r$q5h$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="22143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wC0HG9CqxQuKqFEe+uBcU"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:XDIp0BMVo1VY4H3h8Pch9Vio5c4=
sha1:XjgSy7k0tDXaPEtrh5YNkkMgUe0=
 by: Paul Rubin - Sat, 3 Jul 2021 16:09 UTC

Stephen Pelc <stephen@vfxforth.com> writes:
> 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.

Nice, but does anything in those designs go architecturally beyond the
stuff in Koopman's book?

>> The thing about Forth is that it's simple enough that you can implement
>> it with just a bit of cleverness and understanding...

> 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.

Does that also apply to a traditional threaded Forth? That's what I had
in mind about Forth being simple. Of course you can use fancier
approaches that do require theory, as in the case of VFX.

Re: Forth CPU on an FPGA Wanted

<87lf6n5q65.fsf@nightsong.com>

 copy mid

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

 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 09:16:02 -0700
Organization: A noiseless patient Spider
Lines: 6
Message-ID: <87lf6n5q65.fsf@nightsong.com>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@googlegroups.com>
<sb9rpt$j3t$1@dont-email.me> <sbpthd$lkl$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c0d61e4ba2f5373aaff7c10414d70952";
logging-data="22143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2WCVrZTk3Gn9e+yd5GXeB"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:HT9a8HuJX8lu6tGraUbrLHZN4xU=
sha1:yH678YcGUmvYboCDSnd/XLlct04=
 by: Paul Rubin - Sat, 3 Jul 2021 16:16 UTC

Matthias Koch <m.cook@gmx.net> writes:
> Also there is Mecrisp-Quintus, which uses the FemtoRV32 CPU designed
> by Bruno Levy and me, implementing RV32I or RV32IM:
> https://github.com/BrunoLevy/learn-fpga ... + RV32IMC

Nice!

Re: Forth CPU on an FPGA Wanted

<00208cf0-636e-4569-9e20-bc58391e5584n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:7ed9:: with SMTP id x25mr6742616qtj.39.1625367022918; Sat, 03 Jul 2021 19:50:22 -0700 (PDT)
X-Received: by 2002:a05:620a:12b4:: with SMTP id x20mr7868382qki.217.1625367022754; Sat, 03 Jul 2021 19:50:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.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: Sat, 3 Jul 2021 19:50:22 -0700 (PDT)
In-Reply-To: <87im1r7t38.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=64.237.230.219; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 64.237.230.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> <1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com> <87im1r7t38.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <00208cf0-636e-4569-9e20-bc58391e5584n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sun, 04 Jul 2021 02:50:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 118
 by: Rick C - Sun, 4 Jul 2021 02:50 UTC

On Saturday, July 3, 2021 at 3:30:06 AM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@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.

Yes, from your tiny corner of the world that exposes you to very, very little Forth and yet you speak as if you are a great authority.

> > 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.

Because the stack processor is smaller and easier to implement in an FPGA. That is the context of the discussion, no? As I stated very clearly, programming in Forth is where the code density comes from. Obviously a stack processor is a good match to Forth, but that is not required.

If someone wants to claim code density improvement from using a stack processor, you should ask them about that.

I did design a hybrid instruction set with indexing into the stack. In a small interrupt routine that did have significant stack juggling, this improved the code density significantly. Without the indexing the code was approximately the same density as some of the register based architectures I compared it to. With the stack indexing it was much better, around 25% improvement if my memory serves me correctly.

The application was for a DDS hardware control application where there were six words that needed to be read and processed to program several registers (again, if I remember correctly). Admittedly this was just one application, but it was the test bench for my CPU design at that time. That's how I use CPUs in FPGAs, to solve problems that are a bit much for small hardware.

> > 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.

It's only inefficient if it doesn't meet the requirements of the application. Since you don't program in Forth and have no Forth applications, I don't see how you are in a position to evaluate that.

> 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.

I think you will find that most people use coding tools the same way they drive a car. They don't need to know what is going on in the transmission to turn the key and step on the gas.

> > 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
, then obviously if you
> don't understand your thing you have failed.

??? What are you talking about? If your goal is to understand things rather than doing anything useful, I have no interest in your problems. Go away!

> > 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.

Actually they are not secret. How FPGA tools work are not secret or mysterious. They are copyrighted or sometimes patented. Big difference.

There are open source HDL synthesizers. Go read about them. They work just the same as the commercial ones. Then please don't bother telling me about them. I have no use for that information. Each synthesis tool has a manual on how to write code to produce good results. That's what I need to know since I am neither Mr Spock or Harry Mudd.

--

Rick C.

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

Re: Forth CPU on an FPGA Wanted

<sbr7om$13jq$1@gioia.aioe.org>

 copy mid

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

 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: Sun, 4 Jul 2021 12:52:09 +1000
Organization: Aioe.org NNTP Server
Lines: 22
Message-ID: <sbr7om$13jq$1@gioia.aioe.org>
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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.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 - Sun, 4 Jul 2021 02:52 UTC

On 3/07/2021 23:09, Marcel Hendrix wrote:
> 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.

Jeff Fox asserted 'the stack was for things that don't need names'.
It says more about the user than Forth when his first extension is
the elimination of stack operators.

Re: Forth CPU on an FPGA Wanted

<5dbc35e4-c3f7-43f5-a913-bb3487b2a3aen@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:1388:: with SMTP id h8mr6808106qtj.147.1625367225126;
Sat, 03 Jul 2021 19:53:45 -0700 (PDT)
X-Received: by 2002:a37:59c7:: with SMTP id n190mr7611081qkb.146.1625367225020;
Sat, 03 Jul 2021 19:53:45 -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 19:53:44 -0700 (PDT)
In-Reply-To: <87y2an69yp.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=64.237.230.219; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 64.237.230.219
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>
<87y2an69yp.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5dbc35e4-c3f7-43f5-a913-bb3487b2a3aen@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sun, 04 Jul 2021 02:53:45 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Rick C - Sun, 4 Jul 2021 02:53 UTC

On Saturday, July 3, 2021 at 5:08:32 AM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@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.

What's your point? Why would any sort of processor be an "end goal'??? Even the Intel CPU in my laptop is not an end goal. The end goal is to run useful programs.

Where do you get these ideas???

--

Rick C.

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

Re: Forth CPU on an FPGA Wanted

<87y2amfrmk.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 00:46:43 -0700
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <87y2amfrmk.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>
<00208cf0-636e-4569-9e20-bc58391e5584n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="21283"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+HcXqEngcl/1cXNjbpVDyd"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:jM0KXKhdSXB6wIQpW47d9svuT/w=
sha1:ROFuUlf6LzLyVyYpwxQOnWBGYdk=
 by: Paul Rubin - Sun, 4 Jul 2021 07:46 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Yes, from your tiny corner of the world that exposes you to very, very
> little Forth and yet you speak as if you are a great authority.

I don't think I'm an authority. I asked to see examples of this well
organized Forth code that doesn't manipulate the stack much. I did get
a few responses, that look like code with rather regular structure, but
I'm not done looking at it yet.

Have you got some code to post?

> Because the stack processor is smaller and easier to implement in an
> FPGA. That is the context of the discussion, no?

OP seems to have gone away, and it's not entirely clear what he wanted.

> [DTC] It's only inefficient if it doesn't meet the requirements of the
> application.

We were discussing code density, for which one method can be compared
with another.

> Since you don't program in Forth and have no Forth applications,

I do use it, though not very much, and mostly for its own sake.

> I don't see how you are in a position to evaluate that.

Look at Brad Rodriguez's series "Moving Forth".

> ??? What are you talking about? If your goal is to understand things
> rather than doing anything useful, I have no interest in your
> problems. Go away!

Shrug, we all have to do some of each. But, where I come from,
scientists were people we were supposed to look up to. What do they do
for a living? Attempt to understand things. Did you take classes in
that DSP stuff that you post about sometimes? Why? To understand it in
order to use it is why.

A big reason so much code and everything else out there is crap is that
people attempt to shovel it out without understanding what they are
doing. I don't believe in that approach. You have to know what you're
doing.

> Actually they are not secret. How FPGA tools work are not secret or
> mysterious.

Can you recommend a book at a similar level to the Dragon books that I
linked?

> There are open source HDL synthesizers. Go read about them. They
> work just the same as the commercial ones.

This looks interesting: http://www.clifford.at/yosys/

The last time I looked into this, there were some Verilog and VHDL
compilers that turned the HDL code into a software simulation for
testing, but that is much different than turning it into hardware.

Re: Forth CPU on an FPGA Wanted

<87tulafqvc.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 01:03:03 -0700
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <87tulafqvc.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>
<87y2an69yp.fsf@nightsong.com>
<5dbc35e4-c3f7-43f5-a913-bb3487b2a3aen@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="21283"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18PyI7zsdmd8jvmBf9R24Pc"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:AOqT97zETtaviKKII2R26JfKHOc=
sha1:REXB55SloZufx1eGDAKqEb8NnQ4=
 by: Paul Rubin - Sun, 4 Jul 2021 08:03 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> What's your point? Why would any sort of processor be an "end
> goal'??? Even the Intel CPU in my laptop is not an end goal. The end
> goal is to run useful programs.

The end goal is up to the user. I wouldn't presume to tell someone else
what their end goal is, or assume that it is the same as mine. In this
particular case, the OP's end goal was unclear enough that I had to ask
what it was. I never got an answer.

I think relatively few Forthers these days use Forth for the pure
purpose of "getting things done". You're one of the exceptions, and the
Forth vendors seem to do a bunch of contract development in Forth. I'm
sure there are others, but a lot seem to choose Forth for personal
satisfaction of one kind or another, rather than as the quickest way to
finish a task.

Re: Forth CPU on an FPGA Wanted

<4daf42c4-8180-4563-a188-0bab004d1910n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:65da:: with SMTP id t26mr8225470qto.308.1625401867877;
Sun, 04 Jul 2021 05:31:07 -0700 (PDT)
X-Received: by 2002:ae9:f30b:: with SMTP id p11mr9218068qkg.466.1625401867712;
Sun, 04 Jul 2021 05:31:07 -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: Sun, 4 Jul 2021 05:31:07 -0700 (PDT)
In-Reply-To: <87y2amfrmk.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=64.237.230.219; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 64.237.230.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> <1be1edc7-be8e-4221-b87e-adcf01e1618bn@googlegroups.com>
<87im1r7t38.fsf@nightsong.com> <00208cf0-636e-4569-9e20-bc58391e5584n@googlegroups.com>
<87y2amfrmk.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4daf42c4-8180-4563-a188-0bab004d1910n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sun, 04 Jul 2021 12:31:07 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Rick C - Sun, 4 Jul 2021 12:31 UTC

On Sunday, July 4, 2021 at 3:46:48 AM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > Yes, from your tiny corner of the world that exposes you to very, very
> > little Forth and yet you speak as if you are a great authority.
> I don't think I'm an authority. I asked to see examples of this well
> organized Forth code that doesn't manipulate the stack much. I did get
> a few responses, that look like code with rather regular structure, but
> I'm not done looking at it yet.
>
> Have you got some code to post?

No, I don't, because I don't consider my code to be remotely typical of any class of application. Who cares really? The issue is not about Forth code nearly as much as it is about you shooting your mouth off based on a few examples you have looked at. Now you challenge others to prove you wrong. I'm not interested in proving anything. I'm just pointing out your short comings which have to do with your methods, not Forth.

> > Because the stack processor is smaller and easier to implement in an
> > FPGA. That is the context of the discussion, no?
> OP seems to have gone away, and it's not entirely clear what he wanted.
>
> > [DTC] It's only inefficient if it doesn't meet the requirements of the
> > application.
>
> We were discussing code density, for which one method can be compared
> with another.

No, we are discussing processors in FPGAs. I've explained the code density issue is not about stack processors, but about using Forth and now you wish to start a second debate about that.

You have had this conversation many times. Why do you continue? Why not look at any of the many other conversations on the topic?

> > Since you don't program in Forth and have no Forth applications,
> I do use it, though not very much, and mostly for its own sake.

Like I said, you don't use it and have no applications.

> > I don't see how you are in a position to evaluate that.
> Look at Brad Rodriguez's series "Moving Forth".

That's a non sequitur. Look at pictures of Niagara Falls.

> > ??? What are you talking about? If your goal is to understand things
> > rather than doing anything useful, I have no interest in your
> > problems. Go away!
> Shrug, we all have to do some of each. But, where I come from,
> scientists were people we were supposed to look up to. What do they do
> for a living? Attempt to understand things. Did you take classes in
> that DSP stuff that you post about sometimes? Why? To understand it in
> order to use it is why.

More non sequitur. You don't need to "understand" things to use them. You need to know how to use them. You don't know enough about HDL tools to use them effectively and you blame it on the tools for not having classes on the inner workings. You don't need to know that. You only need to know how to use the steering wheel, accellerator and brake. Please stop insisting HDL tools are not understood enough to use.

> A big reason so much code and everything else out there is crap is that
> people attempt to shovel it out without understanding what they are
> doing. I don't believe in that approach. You have to know what you're
> doing.

More non sequitur. You need to understand YOUR work, not everyone else's. I don't need to know how a soda can is fabricated to open it and drink the contents. Please stop this pointless line of discussion.

> > Actually they are not secret. How FPGA tools work are not secret or
> > mysterious.
> Can you recommend a book at a similar level to the Dragon books that I
> linked?

Why would I know it exists? I don't need to know any of that to use HDL tools.

> > There are open source HDL synthesizers. Go read about them. They
> > work just the same as the commercial ones.
> This looks interesting: http://www.clifford.at/yosys/
>
> The last time I looked into this, there were some Verilog and VHDL
> compilers that turned the HDL code into a software simulation for
> testing, but that is much different than turning it into hardware.

The open source synthesis tools have been around for years. All you had to do was look. But it is pointless if your goal is to use the tools. It is clear that is not your intent, so it doesn't matter what you find.

--

Rick C.

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

Re: Forth CPU on an FPGA Wanted

<b5ece5ae-c962-4ff2-b52b-ac82c9889d27n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:6214:1865:: with SMTP id eh5mr3457247qvb.3.1625402155922;
Sun, 04 Jul 2021 05:35:55 -0700 (PDT)
X-Received: by 2002:ac8:7608:: with SMTP id t8mr2317198qtq.220.1625402155767;
Sun, 04 Jul 2021 05:35:55 -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: Sun, 4 Jul 2021 05:35:55 -0700 (PDT)
In-Reply-To: <87tulafqvc.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=64.237.230.219; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 64.237.230.219
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>
<87y2an69yp.fsf@nightsong.com> <5dbc35e4-c3f7-43f5-a913-bb3487b2a3aen@googlegroups.com>
<87tulafqvc.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b5ece5ae-c962-4ff2-b52b-ac82c9889d27n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sun, 04 Jul 2021 12:35:55 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Rick C - Sun, 4 Jul 2021 12:35 UTC

On Sunday, July 4, 2021 at 4:03:06 AM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > What's your point? Why would any sort of processor be an "end
> > goal'??? Even the Intel CPU in my laptop is not an end goal. The end
> > goal is to run useful programs.
> The end goal is up to the user. I wouldn't presume to tell someone else
> what their end goal is, or assume that it is the same as mine. In this
> particular case, the OP's end goal was unclear enough that I had to ask
> what it was. I never got an answer.

"it means the stack processor is no longer the hardware end goal"

It seems YOU are obsessed with knowing the "end goal" of using a stack processor, so much so that you don't realize you made the statement.

> I think relatively few Forthers these days use Forth for the pure
> purpose of "getting things done". You're one of the exceptions, and the
> Forth vendors seem to do a bunch of contract development in Forth. I'm
> sure there are others, but a lot seem to choose Forth for personal
> satisfaction of one kind or another, rather than as the quickest way to
> finish a task.

This is just your conjecture with no support. I'll put it with your many other unsupported conjectures.

--

Rick C.

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

Re: Forth CPU on an FPGA Wanted

<162540469421.19496.4389022644605654323@media.vsta.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sun, 04 Jul 2021 06:18:14 -0700
Lines: 25
Message-ID: <162540469421.19496.4389022644605654323@media.vsta.org>
References: <sbr7om$13jq$1@gioia.aioe.org> <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> <e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
X-Trace: individual.net EA2uJhvpjSzrjxrdzrpWYQujuG/C/xilSOKgA7cOg4qlDW1fDf
X-Orig-Path: media
Cancel-Lock: sha1:YCbARcgfCTCil3NHT1GAMpGi1Ug=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Sun, 4 Jul 2021 13:18 UTC

dxforth <dxforth@gmail.com> writes:
> Jeff Fox asserted 'the stack was for things that don't need names'.
> It says more about the user than Forth when his first extension is
> the elimination of stack operators.

I miss Jeff. His sentiment resonates with me, and I like the notion of
classifying by whether something has a name. Local variables resulted in
hateful code which I did not want to write. However, binding a name (once)
to a value (lambda binding, for those in the comp sci world) would sometimes
greatly clarify the code.

: example { someptr arg -- bool }
... ( modifier )
arg + someptr >field !
... ;

Imagine having a read-only name for the argument when you have
non-trivial work to prepare a delta for it. It can certainly float
along in the stack below the work (classic Forth, and certainly how to
think about it by default). But I found this construct at its best
brought clarity to my intention of how I used the arguments.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: Forth CPU on an FPGA Wanted

<87eeceas5h.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 10:46:34 -0700
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <87eeceas5h.fsf@nightsong.com>
References: <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="10792"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18RwNAGwrE48jMbc5NJBIgD"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:JnALuf+ZFFyrHtSNJzUlByy8aOU=
sha1:lTTnX9J4+mpLgudTWZ3WogaJYGc=
 by: Paul Rubin - Sun, 4 Jul 2021 17:46 UTC

Andy Valencia <vandys@vsta.org> writes:
> Local variables resulted in hateful code which I did not want to
> write. However, binding a name (once) to a value (lambda binding, for
> those in the comp sci world) would sometimes greatly clarify the code.

I'm having trouble understanding the difference between local variables
and what you're calling lambda binding. Your example looks like what
I'd have thought was a normal use of locals. Or do you mean the
distinction is that they are like VALUEs rather than VARIABLEs? The
locals that I'm used to are indeed like VALUEs.

Re: Forth CPU on an FPGA Wanted

<87a6n2aqsd.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 11:16:02 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <87a6n2aqsd.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>
<87y2an69yp.fsf@nightsong.com>
<5dbc35e4-c3f7-43f5-a913-bb3487b2a3aen@googlegroups.com>
<87tulafqvc.fsf@nightsong.com>
<b5ece5ae-c962-4ff2-b52b-ac82c9889d27n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="27618"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1848/ABLtIZ973BwC0imT+Y"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:ZdDndTli1oviheN91+QWqpWbsVY=
sha1:X0TI+BmCEF7NXDB+tF66epLNNC8=
 by: Paul Rubin - Sun, 4 Jul 2021 18:16 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> > Even the Intel CPU in my laptop is not an end goal. The end
>> > goal is to run useful programs.
> "it means the stack processor is no longer the hardware end goal"

The Intel CPU in your laptop was the end goal of the Intel engineers who
made it. The revenue that Intel collected from selling it was the end
goal of Intel management. Running useful programs was your end goal in
buying it. But truthfully, the end goal of quite a lot of other buyers
of high end desktop CPUs and GPUs is to run video games, i.e. for
recreational programs rather than what most us would call useful. That
is perfectly fine, of course. The video game market drives a heck of a
lot of hardware development that the rest of us benefit from.

> It seems YOU are obsessed with knowing the "end goal" of using a stack
> processor, so much so that you don't realize you made the statement.

When someone opens a discussion looking for a solution, it's important
to know their end goal in order to supply helpful responses. See:

https://en.wikipedia.org/wiki/XY_problem
https://xyproblem.info/

>> I think relatively few Forthers these days use Forth for the pure
>> purpose of "getting things done".
> This is just your conjecture with no support.

It is pretty well supported by watching the activity in this newsgroup
for some years, and of seeing discussions of Forth in other places. I
keep hearing about a Nixonian silent majority of professional Forth
users who are invisible on the internet, but that to me seems even less
supported.

I do know that in the wider, vast world of programming, Forth is now
quite obscure. Hardly any programmers choose it over other languages to
accomplish their tasks with. Even in our tiny little niche where there
is interest in Forth, that interest is often because Forth is
interesting rather than because Forth is productive.

Re: Forth CPU on an FPGA Wanted

<871r8eaqf0.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 11:24:03 -0700
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <871r8eaqf0.fsf@nightsong.com>
References: <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="27618"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IQ6LqPspq7LB4OXvXQZAS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:+kiWWQMKIma0oUzkv9aovT0FlPQ=
sha1:Bd7NV/OytN7G6ltTu243cuGgMyI=
 by: Paul Rubin - Sun, 4 Jul 2021 18:24 UTC

Andy Valencia <vandys@vsta.org> writes:
> I miss Jeff. His sentiment resonates with me, and I like the notion of
> classifying by whether something has a name. Local variables resulted in
> hateful code which I did not want to write.

I sometimes imagine a Forth where the parameters to a word can be
referenced like in Unix shells, i.e. automatically bound to $1, $2, etc.
Do you like that, as an alternative to making up names for them?

Re: Forth CPU on an FPGA Wanted

<162542586157.26783.13412479558059319984@media.vsta.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Sun, 04 Jul 2021 12:11:01 -0700
Lines: 15
Message-ID: <162542586157.26783.13412479558059319984@media.vsta.org>
References: <87eeceas5h.fsf@nightsong.com> <sbr7om$13jq$1@gioia.aioe.org> <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> <e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com> <162540469421.19496.4389022644605654323@media.vsta.org>
X-Trace: individual.net 5/7bGcIOy+ZBKDK4qZTx5gaRkqVRBcO3dm6bA/O1dXZRCj96dB
X-Orig-Path: media
Cancel-Lock: sha1:MY6lIIJ5gNCNyI6fHxlcAR9N8dM=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Sun, 4 Jul 2021 19:11 UTC

Paul Rubin <no.email@nospam.invalid> writes:
> I'm having trouble understanding the difference between local variables
> and what you're calling lambda binding.

A lambda binds a name to a value. The name and its value are invariant.
Local variables are writable. You can read and write them. (In one
variation, the name meant "fetch", and you used a prefix to mention
the variable for purposes of assignment.)

The point is I've found a name for an invariant to be more helpful
and clear than any sort of stack frame based read/write semantics.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: Forth CPU on an FPGA Wanted

<87sg0takks.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 13:30:11 -0700
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <87sg0takks.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>
<00208cf0-636e-4569-9e20-bc58391e5584n@googlegroups.com>
<87y2amfrmk.fsf@nightsong.com>
<4daf42c4-8180-4563-a188-0bab004d1910n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c80aaa5ac4acefd62edd4f0655c4a45";
logging-data="19759"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+2d2JucRKNgKTgZrp/jr36"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:EI9iQ5lRvBldfhOhJR1c4e24JMU=
sha1:SdFSKa+N3oqPiee2fPKf5u5AMRo=
 by: Paul Rubin - Sun, 4 Jul 2021 20:30 UTC

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> The issue is not about Forth code nearly as much as it is about you
> shooting your mouth off based on a few examples you have looked at.

You are saying that the examples I've looked at are too few to
generalize from, even though some were written by renowned Forthers.
Maybe you're right: that's why I asked for more examples. Meanwhile I
can only use the information that is available to me.

> I'm just pointing out your short comings which have to do with your
> methods, not Forth.

The methods seem ok to me. They don't produce mathematical certainty,
but few things do. If I get a reasonable Bayesian estimate, that's the
best I can hope for, and I think I have that, based on examples and
comments from other users here. You now spout off that the estimate is
still unfounded, but I don't agree with you and you have given no reason
to take your opinion seriously.

> I've explained the code density issue is not about stack processors,
> but about using Forth and now you wish to start a second debate about
> that.

If you compile the exact same Forth program for two different
processors, and the code for processor A is smaller than the code for
processor B, we would say processor A's code is denser. That difference
comes from the processors, not from using Forth, since it was Forth on
both processors.

> Like I said, you don't use it and have no applications.

I do use Forth some and have posted some Forth programs here, something
I don't think you have done. As for applications: well, I'm an
experienced developer familiar with a lot of languages and tools, and
when I just want to solve a problem, I've (so far) always been able to
find a quicker solution than using Forth. Maybe that says more about
Forth than it does about me, so what point are you trying to make?

There is a similar situation with the GA144, where you and I both spent
months trying to think of good use cases for it. Yes there are things
you can do with it, but there usually turn out to be simpler solutions
using more conventional hardware.

And yet, if you gave some GA144 boards to WWII codebreakers they would
have found it fantastic, since they didn't have any other computers. I
know about your FPGA test program written in Forth. That's great, but
what else did you consider? If you chose Forth because it's what you're
familiar with, maybe you're not such an authority either.

>> > I don't see how you are in a position to evaluate that.
>> Look at Brad Rodriguez's series "Moving Forth".
> That's a non sequitur. Look at pictures of Niagara Falls.

Do you even know how DTC works, bro? It inserts an extra jump or call
instruction into the code field of EVERY Forth word, i.e. it makes the
code bigger (decreases code density) to speed up the address
interpreter. Moving Forth explains this (
http://www.bradrodriguez.com/papers/moving1.htm ):

This costs space: every high-level definition in a Z80 Forth (for
example) is now one byte longer, since a 2-byte address has been
replaced by a 3-byte call. But this is not universally true....

It mentions some exceptions like the Zilog Super 8 where the DTC uses a
1 byte ENTER instruction (saving a byte over a 2-byte PFA field in an
ITC interpreter) but I think you can eliminate the PFA completely, by
complicating the address interpreter even more. I was surprised that
traditional ITC interpreters don't work that way.

> Please stop insisting HDL tools are not understood enough to use.

I've never claimed they are not understood enough for use.

> I don't need to know how a soda can is fabricated to open it and drink
> the contents.

Perhaps people who paid attention to how the cans were fabricated may
have avoided health problems that you exposed yourself to:

https://www.ewg.org/research/bisphenol-toxic-plastics-chemical-canned-food

I'm not much of a beer drinker but on the occasions where I indulge, I
usually get it in bottles rather than cans for that reason.

>> Can you recommend a book at a similar level to the Dragon books that
>> I linked?
>
> Why would I know it exists? I don't need to know any of that to use
> HDL tools.

Shrug, you were a priori more likely to know of such a thing than
someone who even doesn't use the tools, but you're right that it's not
required. Does anyone else here know of such a book?

> The open source synthesis tools have been around for years.

I'd like to see a comparison between them and commercial tools. Maybe
something like that exists somewhere. I do know that most hardware
designers use the commercial tools. This is sort of the opposite of
software development, where most, or at least very substantial, dev work
is done with open source compilers.

That suggests that the commercial HDL tools still contain mysteries,
like software compilers did in the remote past.

Re: Forth CPU on an FPGA Wanted

<sbtg6d$nub$1@gioia.aioe.org>

 copy mid

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

 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: Mon, 5 Jul 2021 09:28:14 +1000
Organization: Aioe.org NNTP Server
Lines: 10
Message-ID: <sbtg6d$nub$1@gioia.aioe.org>
References: <4984e733-6372-43cc-8218-3d1c3d291a58n@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>
<sbpfmq$135j$1@gioia.aioe.org> <2021Jul3.150217@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
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Sun, 4 Jul 2021 23:28 UTC

On 3/07/2021 23:02, Anton Ertl wrote:
>
> And there is no cartoon in Chapter 2 of "Starting C" that says "I hate
> locals". By contrast, in "Starting Forth" we have:
>
> https://www.forth.com/starting-forth/2-stack-manipulation-operators-arithmetic/#ROT

Never gave the cartoon much thought. All I'm seeing in it is an introduction
to ROT to the frustration of the SWAP dragon. Brodie's cartoons are charming
but not conspiratorial.

Re: Forth CPU on an FPGA Wanted

<sbtnou$skg$1@gioia.aioe.org>

 copy mid

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

 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: Mon, 5 Jul 2021 11:37:36 +1000
Organization: Aioe.org NNTP Server
Lines: 20
Message-ID: <sbtnou$skg$1@gioia.aioe.org>
References: <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
<871r8eaqf0.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 - Mon, 5 Jul 2021 01:37 UTC

On 5/07/2021 04:24, Paul Rubin wrote:
> Andy Valencia <vandys@vsta.org> writes:
>> I miss Jeff. His sentiment resonates with me, and I like the notion of
>> classifying by whether something has a name. Local variables resulted in
>> hateful code which I did not want to write.
>
> I sometimes imagine a Forth where the parameters to a word can be
> referenced like in Unix shells, i.e. automatically bound to $1, $2, etc.

Any form of local variable built on top of a stack-based language
represents additional overhead relative to what occurs in a variable-
based language. That one may be able optimize some of the former
away isn't the point. It's inappropriate for the architecture - which
was Jeff's point. If one still insists on using locals in Forth feel
free to do so in the knowledge it's not what a stack-based language
was designed to do. "stack juggling" may be great propaganda but
one that ultimately undermines Forth.

> Do you like that, as an alternative to making up names for them?
>

Re: Forth CPU on an FPGA Wanted

<87o8bh9x8u.fsf@nightsong.com>

 copy mid

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

 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: Sun, 04 Jul 2021 21:54:09 -0700
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <87o8bh9x8u.fsf@nightsong.com>
References: <87eeceas5h.fsf@nightsong.com> <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
<162542586157.26783.13412479558059319984@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="70ed2d6128395fe054128904c756b4ba";
logging-data="19419"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3dSlVpuBJPRptdLvbAiuf"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:Y8G9MpwXERXhF+hc07z/L9cOCgY=
sha1:HhzAK0ZJ8Hrs43n+MrDLfkE1Vv0=
 by: Paul Rubin - Mon, 5 Jul 2021 04:54 UTC

Andy Valencia <vandys@vsta.org> writes:
> A lambda binds a name to a value. The name and its value are invariant.
> Local variables are writable. You can read and write them.

You mean using TO? Of course nothing requires you to do that, and it's
reasonable to say that it's poor style.

> (In one variation, the name meant "fetch", and you used a prefix to
> mention the variable for purposes of assignment.)

I think the current version of ANS locals are like VALUEs which you
write using TO, but you read by just using their names.

The archetypal "lambda" language was Scheme, which also allows
overwriting the values bound by lambda. Using a mutable lambda-bound
cell is the basis for many crappy idioms:

(define (counter)
(let ((n 0))
(lambda ()
(set! n (+ 1 n))
n)))

You can even desugar the define and the let, which are implemented using
lambda:

(define counter2
(lambda ()
((lambda (n)
(lambda ()
(set! n (+ 1 n))
n)) 0)))

> The point is I've found a name for an invariant to be more helpful
> and clear than any sort of stack frame based read/write semantics.

I'd agree that having to overwrite a local is not that common. In
Haskell and in Erlang, it is not even possible, but they end up with
other mechanisms for doing such things.

Re: Forth CPU on an FPGA Wanted

<2daca2ce-d5da-44eb-b785-a66b0f175aecn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a0c:f8d1:: with SMTP id h17mr7262719qvo.21.1625467788663;
Sun, 04 Jul 2021 23:49:48 -0700 (PDT)
X-Received: by 2002:ad4:4945:: with SMTP id o5mr11674361qvy.38.1625467788513;
Sun, 04 Jul 2021 23:49:48 -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: Sun, 4 Jul 2021 23:49:48 -0700 (PDT)
In-Reply-To: <871r8eaqf0.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:3f7a:20d0:4904:7e94:fe27:eea9;
posting-account=V5nGoQoAAAC_P2U0qnxm2kC0s1jNJXJa
NNTP-Posting-Host: 2600:1700:3f7a:20d0:4904:7e94:fe27:eea9
References: <sbr7om$13jq$1@gioia.aioe.org> <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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com> <162540469421.19496.4389022644605654323@media.vsta.org>
<871r8eaqf0.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2daca2ce-d5da-44eb-b785-a66b0f175aecn@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: sdwjac...@gmail.com (S Jack)
Injection-Date: Mon, 05 Jul 2021 06:49:48 +0000
Content-Type: text/plain; charset="UTF-8"
 by: S Jack - Mon, 5 Jul 2021 06:49 UTC

On Sunday, July 4, 2021 at 1:24:04 PM UTC-5, Paul Rubin wrote:
> I sometimes imagine a Forth where the parameters to a word can be
> referenced like in Unix shells, i.e. automatically bound to $1, $2, etc.

Works for me:
$0..$9 values
&0..&9 addresses (of the values)
$X0..$X9 xt's that get compiled
Parameter pointer can be set in memory or anyplace on either stack.
Old parameter pointer saved and restored from return stack allows for
nesting.

: foo set \ parameters set to address passed on data stack
: foo sp@ set \ parameters set on data stack
: foo: create
does> set \ parameters set to data area of defined words
--
me

Re: Forth CPU on an FPGA Wanted

<sbuopo$18d$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!rocksolid2!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Forth CPU on an FPGA Wanted
Date: Mon, 5 Jul 2021 06:01:10 -0500
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <sbuopo$18d$1@dont-email.me>
References: <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
<871r8eaqf0.fsf@nightsong.com> <sbtnou$skg$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 5 Jul 2021 11:01:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0f9cb01edef4ec5805da501b2a59ac73";
logging-data="1293"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xUNmFjs1QxW96Xt6D37YC"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:gs6r7Cvpc6xTRKmQO5uJV6BQ3tI=
In-Reply-To: <sbtnou$skg$1@gioia.aioe.org>
Content-Language: en-US
 by: Krishna Myneni - Mon, 5 Jul 2021 11:01 UTC

On 7/4/21 8:37 PM, dxforth wrote:
> On 5/07/2021 04:24, Paul Rubin wrote:
>> Andy Valencia <vandys@vsta.org> writes:
>>> I miss Jeff.  His sentiment resonates with me, and I like the notion of
>>> classifying by whether something has a name.  Local variables
>>> resulted in
>>> hateful code which I did not want to write.
>>
>> I sometimes imagine a Forth where the parameters to a word can be
>> referenced like in Unix shells, i.e. automatically bound to $1, $2, etc.
>
> Any form of local variable built on top of a stack-based language
> represents additional overhead relative to what occurs in a variable-
> based language.

I'm not sure what you mean by "variable-based language"? Don't you
simply mean, "Any form of local variable built on top of a stack-based
language represents additional overhead relative to what occurs when
passing arguments via a data stack?" I expect this is generally true.

Let's consider an example.

\ Return the number of rows and columns of a generic matrix
\ dim ( a -- n m )

\ Data types "ket", "bra", or "gate" are all represented by complex
\ matrices.

\ Copy ket, bra, or gate: q1 -> q2
: -> ( q1 q2 -- )
2dup >r dim r> dim d= invert Abort" Object size mismatch!"
dup dim * zfloats move ;

Note: A general copy operation between two complex matrices may be
implemented with a check to ensure that the source matrix dimensions are
smaller than the destination, while the copy operation defined above
requires exact matching of the dimensions of the source and destination
matrices in order to be meaningful for the application.

We could write the above copy operator using locals, as follows.

: -> { q1 q2 }
q1 dim q2 dim d= invert Abort" Object size mismatch!"
q1 q2 dup dim * zfloats move ;

It's clearly more effort for someone new to this code to determine the
meaning of the stack-based definition of "->" than for the locals-based
definition. However, "->", is a low-level operator, and, once defined
and tested, we no longer need to be concerned with its definition, and
we may simply use it, e.g.

\ Predefined single and two-qubit states and their adjoints
1 ket |0> z=1 z=0 |0> q!
1 ket |1> z=0 z=1 |1> q!

1 bra <0| |0> adjoint <0| ->
1 bra <1| |1> adjoint <1| ->

....

\ Non-unitary operators P0, P1, ...
1 gate P0 |0> <0| %*% P0 -> \ projection operator |0><0|
1 gate P1 |1> <1| %*% P1 -> \ projection operator |1><1|

....

\ Single qubit operators and gates: I1, ...
1 gate I1 P0 P1 q+ I1 ->

....

\ Two qubit gates: I2, ...
2 gate I2 I1 dup %x% I2 ->

Is the overhead for the locals version of "->" important? Maybe, maybe
not. It depends on the application. If hundreds or thousands of objects
are being copied, the overhead from using locals could certainly become
an issue, and the stack-based definition will likely best the locals
version. It would be illustrative to measure the difference on different
Forth systems.

Note that both versions are re-entrant.

>  That one may be able optimize some of the former
> away isn't the point.  It's inappropriate for the architecture - which
> was Jeff's point.  If one still insists on using locals in Forth feel
> free to do so in the knowledge it's not what a stack-based language
> was designed to do.  "stack juggling" may be great propaganda but
> one that ultimately undermines Forth.
> ...

The notion that use of locals is somehow "inappropriate" in Forth seems
not sensible to me. As Marcel points out, for an extensible language in
which one can implement locals from more basic words, the use of locals
is just a user-defined convenience, and calling it "not Forth" would be
absurd.

I prefer that the Forth standard simply provide sufficient standard
words for implementing locals, rather than dictating a standard locals
specification. However, that ship has sailed. We should trust
programmers to make judicious use of facilities provided by Forth.
Locals are not always the answer.

Krishna

Re: Forth CPU on an FPGA Wanted

<sbv280$1ef7$1@gioia.aioe.org>

 copy mid

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

 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: Mon, 5 Jul 2021 23:42:23 +1000
Organization: Aioe.org NNTP Server
Lines: 41
Message-ID: <sbv280$1ef7$1@gioia.aioe.org>
References: <sbr7om$13jq$1@gioia.aioe.org>
<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>
<e18503e4-a6ec-414a-b280-fb7cb7cb4364n@googlegroups.com>
<162540469421.19496.4389022644605654323@media.vsta.org>
<871r8eaqf0.fsf@nightsong.com> <sbtnou$skg$1@gioia.aioe.org>
<sbuopo$18d$1@dont-email.me>
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: 8bit
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 - Mon, 5 Jul 2021 13:42 UTC

On 5/07/2021 21:01, Krishna Myneni wrote:
> On 7/4/21 8:37 PM, dxforth wrote:
>> On 5/07/2021 04:24, Paul Rubin wrote:
>>> Andy Valencia <vandys@vsta.org> writes:
>>>> I miss Jeff.  His sentiment resonates with me, and I like the notion of
>>>> classifying by whether something has a name.  Local variables
>>>> resulted in
>>>> hateful code which I did not want to write.
>>>
>>> I sometimes imagine a Forth where the parameters to a word can be
>>> referenced like in Unix shells, i.e. automatically bound to $1, $2, etc.
>>
>> Any form of local variable built on top of a stack-based language
>> represents additional overhead relative to what occurs in a variable-
>> based language.
>
> I'm not sure what you mean by "variable-based language"? Don't you
> simply mean, "Any form of local variable built on top of a stack-based
> language represents additional overhead relative to what occurs when
> passing arguments via a data stack?" I expect this is generally true.

By "variable-based" I mean a language designed to use local variables
from the outset - from parameter passing to internal processing.

>>  That one may be able optimize some of the former
>> away isn't the point.  It's inappropriate for the architecture - which
>> was Jeff's point.  If one still insists on using locals in Forth feel
>> free to do so in the knowledge it's not what a stack-based language
>> was designed to do.  "stack juggling" may be great propaganda but
>> one that ultimately undermines Forth.
>> ...
>
> The notion that use of locals is somehow "inappropriate" in Forth seems
> not sensible to me. As Marcel points out, for an extensible language in
> which one can implement locals from more basic words, the use of locals
> is just a user-defined convenience, and calling it "not Forth" would be
> absurd.

It's still Forth because nothing has fundamentally changed. The stack
and its operators are still there. If beauty is simplicity then Forth
has that in spades. What need does it have for a wig and red lipstick.

Re: Forth CPU on an FPGA Wanted

<79e0aad7-d1a8-4923-98cf-67852560cf26n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:e08:: with SMTP id a8mr38121617qti.346.1625904320001;
Sat, 10 Jul 2021 01:05:20 -0700 (PDT)
X-Received: by 2002:a0c:fbd1:: with SMTP id n17mr21516041qvp.19.1625904319651;
Sat, 10 Jul 2021 01:05:19 -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, 10 Jul 2021 01:05:19 -0700 (PDT)
In-Reply-To: <0d42889a-faa0-42e5-b1a5-2694a40cf6dan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c00:c1d:4b00:e005:fa66:60f5:6dce;
posting-account=YjANPgoAAAD2WlZ6AZ4szwtqQkmaybh7
NNTP-Posting-Host: 2001:1c00:c1d:4b00:e005:fa66:60f5:6dce
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: <79e0aad7-d1a8-4923-98cf-67852560cf26n@googlegroups.com>
Subject: Re: Forth CPU on an FPGA Wanted
From: wolf2...@gmail.com (Me Unknown)
Injection-Date: Sat, 10 Jul 2021 08:05:19 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Me Unknown - Sat, 10 Jul 2021 08:05 UTC

On Wednesday, June 30, 2021 at 3:58:38 PM UTC+2, 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

Check this one: https://github.com/samueltardieu/aforth

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor