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.

On Thursday, June 24, 2021 at 11:44:41 AM UTC-5, caloz...@gmail.com wrote:
> 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.

|>> I am looking for a Forth CPU on an FPGA.

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

Christopher Lozinski <calozinski@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.

On Thursday, June 24, 2021 at 2:59:27 PM UTC-5, Paul Rubin wrote:
> 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.

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.

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

On Friday, June 25, 2021 at 4:30:10 PM UTC-5, 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).
> > 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.

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

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.

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.

< 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

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

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

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

On Friday, June 25, 2021 at 4:21:07 PM UTC-4, James Brakefield wrote:
> On Thursday, June 24, 2021 at 2:59:27 PM UTC-5, Paul Rubin wrote:
> > 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..
> 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.

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

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

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.

On Sunday, June 27, 2021 at 10:08:47 PM UTC-5, Paul Rubin wrote:
> 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.

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.

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

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

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

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

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?

In article <87pmw3hl3x.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>anton@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.

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

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

- 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

In article <99bded93-cc59-4311-bb9d-f6e76670556fn@googlegroups.com>,
minf...@arcor.de <minforth@arcor.de> wrote:
>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?

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.

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

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

Why should there be?

- 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