Forth CPU on an FPGA Wanted

[Christopher Lozinski]

I am looking for a Forth CPU on an FPGA.
I am currently considering the EP32 and EP16.
The EP 16 has gorgeous documentation, very carefully written.
I can buy the IP for the EP32 on Amazon. I bet that is also carefully written.
One buyer reviewed it. A pain to get working, but he did get it to work! They even produced some EP32 chips. That means a ton of engineering went into validation.

There is the J1. A bit too stripped down fo rrme. No interrupts for example. The H1 is interesting. Newer so not many users.

There are some C programmable stack machines. Maybe best to use a chip designed for Forth.

Any advice? My dream would be to buy a board, and flash it, but I fear it will not be so easy. Sadly I am not an electrical engineer.

[James Brakefield]

Look in downloads at https://opencores.org/projects/up_core_list
Last entry is "Sorted by Style-Clone" PDF file
In column H: "stack" or "forth" category

A slightly more current version of these files is at https://github.com/jimbrake/cpu_soft_cores

Enjoy

[Paul Rubin]

Christopher Lozinski <caloz...@gmail.com> writes:
> I am looking for a Forth CPU on an FPGA.

> Any advice? My dream would be to buy a board, and flash it, but I
> fear it will not be so easy. Sadly I am not an electrical engineer.

If you're not an electrical engineer, why do you want a Forth CPU on an
FPGA? What do you plan to do with it? Say you get your cpu in the form
of some FPGA board, maybe even already flashed. How do you use it?
What do you think it do for you, that a software Forth on a conventional
cpu won't?

FPGA's are good for all sorts of things, but being able to to use them
sort of makes you an electrical engineer, just like being able to write
Forth programs makes you a Forth programmer.

If you just want a board to run Forth on, I'd start with either a Linux
based Raspberry Pi running Gforth, or a Raspberry Pi Pico running
Mecrisp, depending on whether you want a high level or low level system.

[James Brakefield]

Not a good answer. Forth community should jump at the chance to
provide a starter FPGA & Forth-firmware solution.
Using FPGAs is like building from nuts, bolts and screws. Very much
in the Forth tradition. FPGAs probably have a harder and longer
learning curve than software development.

[Paul Rubin]

James Brakefield <jim.bra...@ieee.org> writes:
> Not a good answer. Forth community should jump at the chance to
> provide a starter FPGA & Forth-firmware solution.

Well I think there are a bunch already: look on Opencores? What would
you even want a Forth FPGA to do? What would you do with one if you had
it? Have you looked at Philip Koopman's book on stack machines?

> Using FPGAs is like building from nuts, bolts and screws. Very much
> in the Forth tradition.

It seems the opposite to me. Using an FPGA normally means using a
proprietary high-tech toolchain to compile HDL to an undocumented
bitstream format which then gets loaded into a device whose architecture
is substantially mysterious (the routing, not the CLB's).

> FPGAs probably have a harder and longer learning curve than software
> development.

Probably true, but that doesn't seem in the Forth tradition either.
Forth imho is supposed to be built of very simple components whose
workings are very easy to learn, though putting the components together
might take a lot of work. Building a Forth cpu from TTL gates might
qualify. An FPGA is the opposite of that. A serious Verilog compiler
is probably as complicated as GCC. I wouldn't even know where to begin
studying how such a thing works. At least for GCC, the source code is
available and there are tons of compiler books. For HDL, I suspect that
the essential knowledge is locked up inside corporations.

Maybe it would be more interesting to skip FPGA's altogether and make a
completely custom chip, like Chuck Moore did several times. He used
completely Forth design tools (OKAD etc.) that let him lay out
rectangles on the screen 1980s-style, and that was enough to design
simple Forth cpus while bypassing the megabuck CAD vendors. He used
fairly low tech, inexpensive fab processes (the GreenArrays chips are in
180nm) and got quite good chip performance given the fab technology.
But, I think you are asking for much fancier capabilities and the
approach gets more cumbersome.

Still, what is the point? What is gained? Is the idea to have an
exercise in FPGA design (nothing wrong with that), or to develop
something useful? If the former, then fine. If the latter, who would
use it?

I could imagine using an FPGA Forth core as part of a larger FPGA
project, but I would only be doing an FPGA project if I were a hardware
guy, which I'm not. And if I were using a Forth core, it would probably
be a very simple one like the b16. If I needed something fancier I'd
probably just drop in a Risc-V or similar core. Maybe those will even
start appearing as hard macros on cheap FPGA's soon.

[James Brakefield]

I'm not trying to sell anything including Forth
And I'm not a world class authority on any of these fields
Perhaps I'm over zealous about FPGAs?

|> Well I think there are a bunch already: look on Opencores?

This list includes other designs as well as those at opencores.
Opencores is perhaps the first place to look.
For others recommend searching to include "github" term.

|> proprietary high-tech toolchain to compile HDL to an undocumented
|> bitstream format which then gets loaded into a device whose architecture
|> is substantially mysterious (the routing, not the CLB's).

Check out https://symbiflow.github.io/
Personally happy to use vendor's free "webpack" tools
Except Intel/Altera webpack tools don't support latest semiconductor
process nodes

|>A serious Verilog compiler is probably as complicated as GCC.

One does not need to understand the Verilog compiler to use Verilog
to design with FPGAs. It helps to understand how your Verilog gets
mapped into LUTs, FFs, carry chains, block RAM, etc.

|> Maybe it would be more interesting to skip FPGA's altogether and make a
|> completely custom chip

Look into open source ASIC design tools, from all appearances they are adequate.
Think there are fabs that will do a single wafer run or batch several designs
onto a single wafer? Not free.

|> I could imagine using an FPGA Forth core as part of a larger FPGA
|> project, but I would only be doing an FPGA project if I were a hardware
|> guy

A large FPGA project utilizes a dozen or more people with a variety of skills:
Architect, project leads, hardware types especially for debug,
software types for C, RTOS, communications software, integration & test;
other tasks: prototype, PCB design, parts selection ...

|>Maybe those will even start appearing as hard macros on cheap FPGA's soon.

Several FPGA families include hard core microprocessors (ARM, PPC, RISC-V)
and their tool chains. The FPGA vendors also support proprietary soft core RISC
processors with complete tool chains (NIOS-II, MicroBlaze, PicoBlaze).

[Brad Eckert]

On Thursday, June 24, 2021 at 9:44:41 AM UTC-7, caloz...@gmail.com wrote:
> I am looking for a Forth CPU on an FPGA.

There's https://github.com/bradleyeckert/chad which I wrote.
The idea was to integrate the simulator into the Forth (which is built on C99) because cross-compilers
that don't simulate their own targets overly complexify things.
There's a lot you can do without running on an FPGA. I did run it on an Arty7 board.
It would be interesting to port it to a Muse Lab iCESugar-Pro FPGA board, which set me back $70 on AliExpress.
https://www.aliexpress.com/item/1005002270742248.html, $47 for the FPGA module and $13 for a carrier board.

It's not quite ready for prime time since I want to get multitasking and code-on-demand working.
The code-on-demand idea is to load seldom-used code into RAM as needed, execute it, and free the RAM.
That's to let small code RAM support big apps. SPI flash is very roomy.
Will it work? I think so. It's a bit like the old Europay, which loaded tokenized Forth applets
in the age of dial-up MODEMs. It's kind of like manually-managed caching.

The CPU is J1-like. It handles interrupts by executing them only when a RET is encountered.
Interrupt logic loads an interrupt vector into the PC instead of popping the PC from the return stack.
So it's like Forth's multitasking paradigm, with tasks replaced by ISRs and time-critical interrupts replaced by hardware.
This has the advantage that you don't have to disable interrupts in critical sections. Just don't put a RET in there.
It also simplifies verification since asynchronous interrupts require more sophisticated testing.
I like the idea of interrupt chaining, which occurs when multiple interrupts are pending.
It's a lot more deterministic. Just make sure long loops have a RET somewhere, which is
reminiscent of PAUSE.

Anyway, I built it for a real-world ASIC so it's not as simple as I would like it.
That ASIC would ideally have a CPU die and a flash memory die in one package, or external SPI flash.
Either way, the wires are assumed to be accessible with perhaps the proper application of fuming nitric acid.
So, the flash contents are encrypted. A tiny stream cipher decrypts flash on the fly.
Headers, code, and message strings (dot-quote, etc.) are all encrypted.
I'm sure a C-based system could do that, in a strap-rockets-on-a-pig kind of way.

[Ilya Tarasov]

http://fforum.winglion.ru/viewtopic.php?f=3&t=3309

Four different kind of Forth CPU cores in one FPGA.

> Any advice? My dream would be to buy a board, and flash it, but I fear it will not be so easy. Sadly I am not an electrical engineer.

VHDL/Verilog + CAD tools (license from major vendors is free for starting level). 2000 cells in FPGA is enough.

[Bob Edwards]

< My dream would be to buy a board, and flash it, but I fear it will not be so easy. Sadly I am not an electrical engineer >

The NIGE machine fills your requirement, is very well documented and runs fast, I've tried it. https://github.com/Anding/N.I.G.E.-Machine regards, Bob G4BBY

[Matthias Koch]

Hi Christopher,

I enhanced the J1a CPU by James Bowman with fixed two cycles latency interrupt handling, barrel shifters and single cycle multiply, released as Mecrisp-Ice http://mecrisp.sourceforge.net/

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 Also see the classic open source RISC-V implementation PicoRV32.

If this is your first dive into FPGAs, my recommendation is that you start with https://1bitsquared.de/products/icebreaker board, using Lattice iCE40 UP5K FPGA.

Matthias

[Matthias Koch]

> Forth community should jump at the chance to provide a starter FPGA & Forth-firmware solution.

Already done, pick one of the supported boards like Icestick (HX1K) or Icebreaker (UP5K) and flash Mecrisp-Ice (stack processor) or Mecrisp-Quintus (RISC-V processor).

Using Yosys, NextPNR and Icestorm, the FOSS toolchain is rock solid.

[Rick C]

On Friday, June 25, 2021 at 5:30:10 PM UTC-4, Paul Rubin wrote:
> James Brakefield <jim.bra...@ieee.org> writes:
> > Not a good answer. Forth community should jump at the chance to
> > provide a starter FPGA & Forth-firmware solution.
> Well I think there are a bunch already: look on Opencores? What would
> you even want a Forth FPGA to do? What would you do with one if you had
> it? Have you looked at Philip Koopman's book on stack machines?
> > Using FPGAs is like building from nuts, bolts and screws. Very much
> > in the Forth tradition.
> It seems the opposite to me. Using an FPGA normally means using a
> proprietary high-tech toolchain to compile HDL to an undocumented
> bitstream format which then gets loaded into a device whose architecture
> is substantially mysterious (the routing, not the CLB's).

Using a proprietary hardware platform with a CPU, keyboard, display, mass storage, etc., none of which is open source.

It's not a question of using open source tools or not, it's just a question of where you draw the line. Silly people take issue with issues that don't matter. In this case proprietary tools do the job just fine if you simply want to get work done. If you want to make a fuss about it, then use the various open source tools available. They are there if you are a masochist.

> > FPGAs probably have a harder and longer learning curve than software
> > development.
> Probably true, but that doesn't seem in the Forth tradition either.

It's only longer and harder if you have already been trained on CPU software tools. If you start from the FPGA perspective coding for sequential processors is much harder in my opinion. Trying to fake an application into looking like it is running multiple processes is not always so easy, certainly not as easy as actually running every process on its own hardware.

> Forth imho is supposed to be built of very simple components whose
> workings are very easy to learn, though putting the components together
> might take a lot of work. Building a Forth cpu from TTL gates might
> qualify. An FPGA is the opposite of that. A serious Verilog compiler
> is probably as complicated as GCC. I wouldn't even know where to begin
> studying how such a thing works. At least for GCC, the source code is
> available and there are tons of compiler books. For HDL, I suspect that
> the essential knowledge is locked up inside corporations.

Only to those who choose to be blind. HDL design is inherently more simple than coding the processor you are designing. That's a natural fact.

> Maybe it would be more interesting to skip FPGA's altogether and make a
> completely custom chip, like Chuck Moore did several times. He used
> completely Forth design tools (OKAD etc.) that let him lay out
> rectangles on the screen 1980s-style, and that was enough to design
> simple Forth cpus while bypassing the megabuck CAD vendors. He used
> fairly low tech, inexpensive fab processes (the GreenArrays chips are in
> 180nm) and got quite good chip performance given the fab technology.
> But, I think you are asking for much fancier capabilities and the
> approach gets more cumbersome.

Yes, I think you should design a Forth CPU and have the chip made without ever prototyping it in an FPGA. ;)

> Still, what is the point? What is gained? Is the idea to have an
> exercise in FPGA design (nothing wrong with that), or to develop
> something useful? If the former, then fine. If the latter, who would
> use it?
>
> I could imagine using an FPGA Forth core as part of a larger FPGA
> project, but I would only be doing an FPGA project if I were a hardware
> guy, which I'm not. And if I were using a Forth core, it would probably
> be a very simple one like the b16. If I needed something fancier I'd
> probably just drop in a Risc-V or similar core. Maybe those will even
> start appearing as hard macros on cheap FPGA's soon.

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. I was working on another one to do floating point math for an open source project, but got a large contract, so no longer have the time to worry with it. It would have been fun. Turns out you can use the FPGA multipliers as barrel shifters for floating point adds. The multiply/add structures work a charm! Very forthish.

--

Rick C.

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

[Rick C]

I've been looking at designing a Forth CPU oriented FPGA module, but I can't find a common set of features that many people agree on. There are some very inexpensive FPGA boards available. Lychee Tang Nano is one with an LCD interface if I'm recalling the name correctly. The FPGA only has 1k LUTs however. Still, that's not bad for <$10.

--

Rick C.

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

[Paul Rubin]

James Brakefield <jim.bra...@ieee.org> writes:
> |>A serious Verilog compiler is probably as complicated as GCC.
> One does not need to understand the Verilog compiler to use Verilog
> to design with FPGAs. It helps to understand how your Verilog gets
> mapped into LUTs, FFs, carry chains, block RAM, etc.

Well, you still haven't told me what you want from a Forth cpu, or from
Forth itself for that matter. One thing lots (I guess not all) Forthers
value is something I'll call surveyability: the ability for a user to
understand every part of the tool chain. If Verilog is involved that
makes things a lot harder. FOSS helps but it's not decisive: GCC is
FOSS but it's not understandable without enormous effort compared with
understanding a traditional Forth.

> Look into open source ASIC design tools, from all appearances they are
> adequate.

Yes, unlike FPGA tools afaict. That's the point of suggesting ASIC
instead of FPGA.

> Think there are fabs that will do a single wafer run or batch several
> designs onto a single wafer? Not free.

https://www.eenewsanalog.com/news/free-chips-courtesy-google-skywater-efabless

has been around for a while and is free. Entertainingly (I didn't
realize this), you get a RISC-V core on every chip. That actually seems
odd to me, that they put it there instead of just making it available as
a macro that you can put there yourself if you want it.

If you don't require free, commercial MPW fab of small designs seems to
start at about $3k per run (cmp.fr when I looked a few years ago), which
is accessible to a low budget professional or high budget hobby project.

> |> FPGA Forth core as part of a larger FPGA project

> A large FPGA project utilizes a dozen or more people with a variety of
> skills:

I just mean "larger than just a Forth core", not large in absolute
terms.

[dxforth]

On 28/06/2021 13:08, Paul Rubin wrote:
> ...

> FOSS helps but it's not decisive: GCC is
> FOSS but it's not understandable without enormous effort compared with
> understanding a traditional Forth.

As an aside, Forth has become less understandable too. What user wants
to understand the details of how VFX' optimizer or dual-xt implementation
works. That they may need to because other forths work differently is
unfortunate both for them and forth in general.

[James Brakefield]

Not sure of your background?
I employ hardware and software with equal skill.

|>you still haven't told me what you want from a Forth cpu

Not so much a Forth CPU, rather the code density the goes with it.
And have often used direct threaded code when doing low level C or assembler.
Rarely did enough code to need a full Forth environment.

|>Forthers value is something I'll call surveyability: the ability for a user to
|> understand every part of the tool chain.

At one time the VHDL and Verilog compilers would report the numbers and type
of simple gates. The vendor's tools would then map the gates into device
primitives (LUTs, various kinds of flip-flops). The ASIC tools probably do this,
and the result might be EDIF or the VHDL or Verilog equivalent?
I've always understood digital computers as an assembly of flip-flops and
combinatorial logic.

A standard education these days will sequence through solid state physics,
transistors, gates, ALU components, state machines and programmable state machines.

Have never needed to understand in detail the inner workings of a high performance CPU.
Likewise one doesn't need to understand the workings of an optimizing Forth compiler
as long as meaning is preserved.

[Paul Rubin]

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?

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

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

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

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.

[James Brakefield]

On Tuesday, June 29, 2021 at 6:50:55 PM UTC-5, 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

Ugh, Koopman hasn't done anything stack computer related in 30 years!

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

These days the instruction processing is pipelined, and changing the
pipe source (e.g. branch, call, return) is slow. Therefore as much
in-lining of subroutines as practical is favored. Forth derives much of
its code density from deep factoring into short subroutines.

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

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.
Wonder I was first to observe this (Talk on interpreters, March 1982 DECUS
meeting; Address space unification, Feb. 1983 IEEE Computer Open Channel;
Address space unification and Forth, Rochester Forth Conference 1984) ?

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

My knowledge of building ALUs, shifters, multipliers out of gates predates
my knowledge of VHDL and Verilog. There are tools which simplify Boolean
logic. 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.

> the FPGA process is mysterious, and therefore imho unappealing to the
> particular Forth sensibility that calls for understanding things.

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

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>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.

But the GCC maintainers do not preserve the meaning and do not want
to. When you report their breakage, they reject the bug report as
invalid. Examples: gcc bugs 65709, 66804 and 66875.

- 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

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> But the GCC maintainers do not preserve the meaning and do not want
> to. When you report their breakage, they reject the bug report as
> invalid. Examples: gcc bugs 65709, 66804 and 66875.

As far as I can tell, GCC preserves the meaning when the program has a
meaning according to the standard. If the program does something like
trigger UB, then of course it is meaningless, so there is no meaning to
preserve.

[minf...@arcor.de]

Anton Ertl schrieb am Mittwoch, 30. Juni 2021 um 08:50:28 UTC+2:
> Paul Rubin <no.e...@nospam.invalid> writes:
> >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.
> But the GCC maintainers do not preserve the meaning and do not want
> to. When you report their breakage, they reject the bug report as
> invalid. Examples: gcc bugs 65709, 66804 and 66875.
>

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

[none albert]

In article <87pmw3h...@nightsong.com>,

There is a middle ground here. It is no good to violate traditional
assumptions, based on a legalistic interpretation of the specific
formulation of a standard that is currently extant.

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

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> But the GCC maintainers do not preserve the meaning and do not want
>> to. When you report their breakage, they reject the bug report as
>> invalid. Examples: gcc bugs 65709, 66804 and 66875.
>
>As far as I can tell, GCC preserves the meaning when the program has a
>meaning according to the standard.

That would mean that it preserves the meaning of roughly 0% of
production programs.

>If the program does something like
>trigger UB, then of course it is meaningless, so there is no meaning to
>preserve.

The meaning to preserve is the meaning that the earlier gcc version
has implemented. You started by claiming that you understand what a
simple C compiler does, and that gcc preserves the meaning of that.
It does not. It does not even preserve the meaning of earlier gcc
versions.

[none albert]

In article <99bded93-cc59-4311...@googlegroups.com>,

Who says there isn't?

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 is what matters.

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>If this is so important, why are there no Ada-based Forths around?

Why should there be?

[James Brakefield]

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.

[Jurgen Pitaske]

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.

[Jon Nicoll]

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

[minf...@arcor.de]

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.

[Jurgen Pitaske]

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

[Jurgen Pitaske]

RUST to get close to ADA - WHY?

[minf...@arcor.de]

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.

[Alexander Wegel]

Jon Nicoll <jkn...@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.

[Brian Fox]

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.

[dxforth]

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

[Rick C]

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

[Paul Rubin]

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.

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

[Paul Rubin]

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.

[dxforth]

On 3/07/2021 17:30, 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.

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.

[Paul Rubin]

dxforth <dxf...@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.

[Paul Rubin]

James Brakefield <jim.bra...@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.

[Paul Rubin]

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.

[dxforth]

On 3/07/2021 18:43, Paul Rubin wrote:
> dxforth <dxf...@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

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>dxforth <dxf...@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.

[dxforth]

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

[none albert]

In article <87eecf7...@nightsong.com>,

Paul Rubin <no.e...@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.

[Stephen Pelc]

On 3 Jul 2021 at 11:02:46 CEST, "Paul Rubin" <no.e...@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

[Stephen Pelc]

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!

Stephen

[none albert]

In article <87im1r7...@nightsong.com>,

Paul Rubin <no.e...@nospam.invalid> 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.

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.

[Marcel Hendrix]

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

[Anton Ertl]

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

[Matthias Koch]

+ RV32IMC

[Paul Rubin]

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.

[Paul Rubin]

Stephen Pelc <ste...@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.

[Paul Rubin]

Matthias Koch <m.c...@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!

[Rick C]

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

[dxforth]

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.

[Rick C]

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

[Paul Rubin]

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?

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

[Paul Rubin]

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.

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.

[Rick C]

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

[Rick C]

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

[Andy Valencia]

dxforth <dxf...@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

[Paul Rubin]

Andy Valencia <van...@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.

[Paul Rubin]

Rick C <gnuarm.del...@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.

[Paul Rubin]

Andy Valencia <van...@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?

[Andy Valencia]

Paul Rubin <no.e...@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.

[Paul Rubin]

Rick C <gnuarm.del...@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.

[dxforth]

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.

[dxforth]

On 5/07/2021 04:24, Paul Rubin wrote:
> Andy Valencia <van...@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.

[Paul Rubin]

Andy Valencia <van...@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.

[S Jack]

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

[Krishna Myneni]

On 7/4/21 8:37 PM, dxforth wrote:
> On 5/07/2021 04:24, Paul Rubin wrote:
>> Andy Valencia <van...@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

[dxforth]

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

[Me Unknown]

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