J1 forth processor in FPGA - possibility of interactive work

[Jecel]

Rickman,

I'm not sure what he meant by "interactively define new words and
execute them". Someone else, maybe in the Forth group, wanted to do
something like that where the basic instruction set could be extended by
compiling Forth.

You are overthinking things. What he meant was that he wanted a native J1
Forth system instead of the cross Forth system most projects were using.
So you would connect a terminal to the FPGA board and would see an "Ok"
prompt and then you could define new words by typing ": name ...." on
the terminal. You would also be able to try simple expressions like
"3 4 + ." and see immediately what they do.

With cross development you type in your program in some editor on your
PC, run the compiler and get a bunch of bits to be loaded into the FPGA
board. You turn on the FPGA board and see if it worked or not. If not,
you got back to the editor on your PC and start the whole cycle again.
This works, but it is not how Forth was meant to be used.

-- Jecel

 

[rickman]

On 6/13/2016 12:52 PM, Jecel wrote:

Rickman,

I'm not sure what he meant by "interactively define new words and
execute them". Someone else, maybe in the Forth group, wanted to do
something like that where the basic instruction set could be extended by
compiling Forth.

You are overthinking things. What he meant was that he wanted a native J1
Forth system instead of the cross Forth system most projects were using.
So you would connect a terminal to the FPGA board and would see an "Ok"
prompt and then you could define new words by typing ": name ...." on
the terminal. You would also be able to try simple expressions like
"3 4 + ." and see immediately what they do.

With cross development you type in your program in some editor on your
PC, run the compiler and get a bunch of bits to be loaded into the FPGA
board. You turn on the FPGA board and see if it worked or not. If not,
you got back to the editor on your PC and start the whole cycle again.
This works, but it is not how Forth was meant to be used.

A target hosted Forth has it's advantages, but I still type my source
into an editor on the PC and compile by downloading to the target rather
than loading into a Forth crosscompiler which downloads it for me. Not
sure there is a huge advantage either way. They seem pretty similar to
me including the need to hit the reset button when I screw up bad enough.

You make it sound like the edit, compile, test loop is somehow much less
useful when using a PC. I got rid of my ADM-3A a long time ago.

--

Rick C

 

[Jecel]

On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:

You make it sound like the edit, compile, test loop is somehow much less
useful when using a PC. I got rid of my ADM-3A a long time ago.

Compare developing a game in Basic on a Commodore 64 with creating the
same game on a PC, using a Basic-to-6502 compiler and downloading it to
the C64 to see if it works. Development is faster in the first option
while the resulting game will be faster in the second option.

What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

-- Jecel

 

[rickman]

On 6/14/2016 3:52 PM, Jecel wrote:

On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:
You make it sound like the edit, compile, test loop is somehow much less
useful when using a PC. I got rid of my ADM-3A a long time ago.

Compare developing a game in Basic on a Commodore 64 with creating the
same game on a PC, using a Basic-to-6502 compiler and downloading it to
the C64 to see if it works. Development is faster in the first option
while the resulting game will be faster in the second option.

That is not at all clear to me. Your example seems to be compiling
native on one type of PC vs. cross compiling on another and transferring
the executable. I don't expect to have anything like mass storage on
the target system, so the two options I have are using the PC for
program storage or using the PC to cross compile. I can download at
nearly 1 Mbps today using the ubiquitous USB serial ports. I don't
perceive any difference in time of loading an executable vs. loading the
program source. Compile times are very fast as well.

What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You still have the loop, you think it is faster the way you are
describing, but I use the same command line for testing. I just use the
PC as an editor.

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

That's fine if the J1 has facilities for the full development process.
I can't remember the last time I used a target that was even close to
being able to support a full development system other than the Raspberry
Pi. What sort of J1 hardware are you looking at?

--

Rick C

 

[Jecel]

On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:

What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You still have the loop, you think it is faster the way you are
describing, but I use the same command line for testing. I just use the
PC as an editor.

"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

That's fine if the J1 has facilities for the full development process.
I can't remember the last time I used a target that was even close to
being able to support a full development system other than the Raspberry
Pi. What sort of J1 hardware are you looking at?

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

-- Jecel

 

[rickman]

On 6/15/2016 5:43 PM, Jecel wrote:

On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:
What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You still have the loop, you think it is faster the way you are
describing, but I use the same command line for testing. I just use the
PC as an editor.

"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

There's the problem. I'm using Forth. I didn't know we were talking
about BASIC.

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

That's fine if the J1 has facilities for the full development process.
I can't remember the last time I used a target that was even close to
being able to support a full development system other than the Raspberry
Pi. What sort of J1 hardware are you looking at?

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

I don't recall the limitation, but I would expect it to be on the order
of many KB. Mecrisp is not so large and in fact, I'm pretty sure it has
been ported to the J1. I seem to recall this was done using an open
source package (the only one I've ever heard of) that compiles to a bit
stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth
to this target making the entire effort open source. I can't recall for
sure, but I'm pretty sure the hardware is also open source.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

64 kB of on target flash is not of much value for storing source. You
have virtually no tools for printing, copying, backup, etc. I use a PC
for all that.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

You mean an FPGA board? The rPi has a higher end ARM processor.

--

Rick C

 

[Jecel]

On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:

On 6/15/2016 5:43 PM, Jecel wrote:
"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

There's the problem. I'm using Forth. I didn't know we were talking
about BASIC.

So we type

MADD @ 4 / 1 + .

instead. The point is that I don't have to first put that expression
in a colon definition, compile it, and then send it to the target
board to see the result.

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

I don't recall the limitation, but I would expect it to be on the order
of many KB.

Let me check:

http://excamera.com/files/j1.pdf

"All target addresses - for call, jump and conditional branch
- are 13-bit. This limits code size to 8K words, or 16K bytes."

Data uses 15 bit byte addresses, but the top half of the memory
map is reserved for I/O. So was have 16KB in all to play with.

Mecrisp is not so large and in fact, I'm pretty sure it has
been ported to the J1. I seem to recall this was done using an open
source package (the only one I've ever heard of) that compiles to a bit
stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth
to this target making the entire effort open source. I can't recall for
sure, but I'm pretty sure the hardware is also open source.

Ok, so the answer to the original question is "yes"? Good. I've had some
nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
Forth that can be used interactively. Not only is token threading
really compact, but it can also be used on Harvard architecture chips
like the Atmel AVR8.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

64 kB of on target flash is not of much value for storing source. You
have virtually no tools for printing, copying, backup, etc. I use a PC
for all that.

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

You mean an FPGA board? The rPi has a higher end ARM processor.

The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
the case for some FPGA boards. And those with chips like Zynq have
FPGAs and ARMs.

What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

-- Jecel

 

[rickman]

On 6/16/2016 1:57 PM, Jecel wrote:

On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:
On 6/15/2016 5:43 PM, Jecel wrote:
"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

There's the problem. I'm using Forth. I didn't know we were talking
about BASIC.



So we type

MADD @ 4 / 1 + .

instead. The point is that I don't have to first put that expression
in a colon definition, compile it, and then send it to the target
board to see the result.

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

I don't recall the limitation, but I would expect it to be on the order
of many KB.

Let me check:

http://excamera.com/files/j1.pdf

"All target addresses - for call, jump and conditional branch
- are 13-bit. This limits code size to 8K words, or 16K bytes."

Data uses 15 bit byte addresses, but the top half of the memory
map is reserved for I/O. So was have 16KB in all to play with.

Mecrisp is not so large and in fact, I'm pretty sure it has
been ported to the J1. I seem to recall this was done using an open
source package (the only one I've ever heard of) that compiles to a bit
stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth
to this target making the entire effort open source. I can't recall for
sure, but I'm pretty sure the hardware is also open source.

Ok, so the answer to the original question is "yes"? Good. I've had some
nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
Forth that can be used interactively. Not only is token threading
really compact, but it can also be used on Harvard architecture chips
like the Atmel AVR8.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

64 kB of on target flash is not of much value for storing source. You
have virtually no tools for printing, copying, backup, etc. I use a PC
for all that.

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

I have no idea what you are trying to say with this. Lots of things
were done in the early days of programming including using toggle
switches to enter programs. I don't wish to duplicate any of that.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

You mean an FPGA board? The rPi has a higher end ARM processor.

The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
the case for some FPGA boards. And those with chips like Zynq have
FPGAs and ARMs.

What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

I don't know what you are trying to say here. You mentioned your
"SiliconSqueak" which I assume is a processor design. You seem to be
talking about running it on an rPi which doesn't make sense. Were you
just using the rPi as a point of comparison?

--

Rick C

 

[GaborSzakacs]

Jecel wrote:

[snip]

What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

-- Jecel

Many low-end FPGA boards are out there, but in general the peripherals
are richer on the boards with a larger FPGA. For a bare-bones starter
board with VGA and USB and PMOD, you could look at:

https://www.nandland.com/goboard/introduction.html

However the ICE40 on that board is not very large for playing with
embedded processors.

If you can live with HDMI instead of VGA, then possibly the Scarab
MiniSpartan6+ would be a possibility. Just be aware that the
SDRAM on that board is single-data-rate and won't work with the
built-in hard memory control block of the Spartan-6.

https://www.scarabhardware.com/minispartan6/

--
Gabor

 

[David Wade]

On 16/06/2016 22:39, GaborSzakacs wrote:

Jecel wrote:

[snip]


What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

-- Jecel

Many low-end FPGA boards are out there, but in general the peripherals
are richer on the boards with a larger FPGA. For a bare-bones starter
board with VGA and USB and PMOD, you could look at:

https://www.nandland.com/goboard/introduction.html

However the ICE40 on that board is not very large for playing with
embedded processors.

If you can live with HDMI instead of VGA, then possibly the Scarab
MiniSpartan6+ would be a possibility. Just be aware that the
SDRAM on that board is single-data-rate and won't work with the
built-in hard memory control block of the Spartan-6.

https://www.scarabhardware.com/minispartan6/

I have used one of these

http://www.ebay.com/itm/251192875961

for a very small system

Dave
G4UGM

 

[Jecel]

Rickman,

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

I have no idea what you are trying to say with this. Lots of things
were done in the early days of programming including using toggle
switches to enter programs. I don't wish to duplicate any of that.

I am saying some programming environments are pretty small and some embedded
processors are getting large enough that the two can meet. Sure, small can
mean primitive and awkward but not necessarily. I find stuff build around
Eclipse pretty unusable so consider the GB of disk and RAM that they need
a waste.

I don't know what you are trying to say here. You mentioned your
"SiliconSqueak" which I assume is a processor design. You seem to be
talking about running it on an rPi which doesn't make sense. Were you
just using the rPi as a point of comparison?

Sorry about the confusion. SiliconSqueak is indeed my own processor and
I was talking about implementing it on low end FPGA boards (Gabor and
Dave Wade have just suggested some nice options in this thread) and
comparing their resources with those available on the Raspberry Pi.

The Squeak virtual machine (both the original interpreter and the new
Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
foundation's efforts to make Scratch more usable. This means you can
either run some software on the Pi with these VMs or on an FPGA board
with my processor. That makes comparing the two options interesting,
though an FPGA board costing around $100 might have less resources
than a Pi board costing $5.

-- Jecel

 

[Cecil Bayona]

On 5/13/2011 7:34 AM, wzab wrote:

Hi,

I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
I'd like to use it to implement simple non-time critical control and
debugging layer
in my FPGA based DSP system.
However to accomplish it I need to add possibility of interactive work
via console
connected either by UART or by JTAG.
Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
with possibility to interactively define new words and execute them?
--
TIA & Regards,
WZab

Its king of a round way to what you want, but the following is
interesting and might accomplish what you wish.

The ep16 CPU contains within it's zip file the following;

weForth - a Windows version of eForth used to create a development system.
Meta compiler - for the ep16 but easily modified for other stack machines
eForth source - not in assembler but in Forth primitives be
meta-compile into the target CPU
Documentation - not just for the CPU, and more importantly for the software.

This package will result in a copy of eForth that would be resident in
the target CPU

I am working with the ep32 which comes with the same software to learn
VHDL, my next target is the ep16, followed by the J1, when I get there I
will be modifying the target compiler to generate J1 primitives and in
so doing ending with a copy of eForth that resides inside the J1. You
can wait until I get there or you can Download the code for the ep16 and
modify it yourself.

Theoretically the J1 has many new instructions built in without changing
the FPGA code, you would have to add the extra instructions that are
already there but nor used to the metacompiler software, it looks like
it's a relatively simple task.

Have fun going Forth.

--
Cecil - k5nwa

 

[rickman]

On 6/17/2016 1:37 PM, Jecel wrote:

Rickman,

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

I have no idea what you are trying to say with this. Lots of things
were done in the early days of programming including using toggle
switches to enter programs. I don't wish to duplicate any of that.

I am saying some programming environments are pretty small and some embedded
processors are getting large enough that the two can meet. Sure, small can
mean primitive and awkward but not necessarily. I find stuff build around
Eclipse pretty unusable so consider the GB of disk and RAM that they need
a waste.

I have no idea why you are bringing Eclipse into a Forth discussion.

Programming from a PC is the easiest way to work unless your target is
heavy enough to support an operating system. So in the Raspberry Pi I
program directly on the target. Any embedded board, even with an on
board Forth compiler, the PC gets used as the host for most development
work while debugging is on the target. I load the code which is one
command and takes maybe a second. I test a few words or word from the
command line until I find a bug and make changes. I forget the stuff
just loaded, load the new code and in less than 5 seconds I'm back to
debugging. Hardly an onerous cycle. In fact, I barely know I'm working
from my laptop on a remote target until I get the target locked up and
have to walk to the other room to push the reset.

I don't know what you are trying to say here. You mentioned your
"SiliconSqueak" which I assume is a processor design. You seem to be
talking about running it on an rPi which doesn't make sense. Were you
just using the rPi as a point of comparison?

Sorry about the confusion. SiliconSqueak is indeed my own processor and
I was talking about implementing it on low end FPGA boards (Gabor and
Dave Wade have just suggested some nice options in this thread) and
comparing their resources with those available on the Raspberry Pi.

I haven't spent much time looking at FPGA boards. I build products with
FPGA but they are seldom on boards that would support other than fairly
primitive processors that are doing simple control functions. My
current product does not have a processor, but the FPGA is maxed out.
The FPGA is also obsolete and eventually the board will need to be
redesigned. When this happens the code will need to be ported and some
of the slow speed stuff might be better in a soft CPU.

The Squeak virtual machine (both the original interpreter and the new
Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
foundation's efforts to make Scratch more usable. This means you can
either run some software on the Pi with these VMs or on an FPGA board
with my processor. That makes comparing the two options interesting,
though an FPGA board costing around $100 might have less resources
than a Pi board costing $5.

If I thought anyone was interested and could find a software guy to team
up with, I would produce an FPGA board which connected to the fast
interfaces on a CPU like the rPi or maybe a BeagleBone and use the
resources on the processor board as a low cost I/O processor for the
FPGA. That reminds me of the array processor I used to work on that had
a compute head on one board and the entire rest of the two rack cabinets
(including two 68010 processors) were support to get data in and out of
the compute head.

--

Rick C

 

[Jecel]

Rick,

sorry that I am not addressing the rest of your post, but I think we
have both said all there is to be said about the subject and won't
reach an agreement.

If I thought anyone was interested and could find a software guy to team
up with, I would produce an FPGA board which connected to the fast
interfaces on a CPU like the rPi or maybe a BeagleBone and use the
resources on the processor board as a low cost I/O processor for the
FPGA. That reminds me of the array processor I used to work on that had
a compute head on one board and the entire rest of the two rack cabinets
(including two 68010 processors) were support to get data in and out of
the compute head.

While perhaps not using the fast interfaces, there are FPGA expansions
for the boards you mentioned:

http://www.bugblat.com/products/pif/

http://valentfx.com/logi-pi/

http://valentfx.com/logi-bone/

The way to have the fastest possible interface between the FPGA and
the processor is to use a chip like the Xilinx Zynq, which includes
two ARM cores. There are many variations of the Zed board with this
chip:

http://zedboard.org/

The one most like what you were describing is probably the Parallella
board, which is essentially a Zed board in a Raspberry Pi form factor
plus an Epiphany chip with 16 (or 64) floating pointer processors:

https://www.parallella.org/

-- Jecel

 

[Matthias Koch]

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

I don't recall the limitation, but I would expect it to be on the order
of many KB. Mecrisp is not so large and in fact, I'm pretty sure it has
been ported to the J1. I seem to recall this was done using an open
source package (the only one I've ever heard of) that compiles to a bit
stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth
to this target making the entire effort open source. I can't recall for
sure, but I'm pretty sure the hardware is also open source.

Exactly, Swapforth by James Bowman and my descendant Mecrisp-Ice with
optimisations run happily in HX1K FPGAs, Icestick and Nandland Go are supported.

If you wish to add more opcodes to the CPU or need gates for something else,
you should go for the HX8K breakout board instead.

Matthias

 

[Cecil Bayona]

On 5/13/2011 7:34 AM, wzab wrote:

Hi,

I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
I'd like to use it to implement simple non-time critical control and
debugging layer
in my FPGA based DSP system.
However to accomplish it I need to add possibility of interactive work
via console
connected either by UART or by JTAG.
Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
with possibility to interactively define new words and execute them?
--
TIA & Regards,
WZab

I have the ep8080, the ep16, and ep32 cores now working along with a
resident version of eForth in each of those CPUs, the next CPU will be
the J1 but first I will need to take a slight detour.

I will continue working on the ep32 core for a while as a learning
vehicle to learn VHDL, so after some minor upgrades such as adding an
additional address register, and additional instructions, when I feel
comfortable with VHDL I will proceed to the J1 CPU.

The first step will be to create a J1 Meta-compiler so I can create a J1
version of eForth that resides in the J1 CPU. If by then you do not have
a resident Forth compiler you might be interested in the J1 native
version of eForth. Once that is working with the existing J1 CPU Verilog
code, I will proceed to create a version of the J1 in VHDL.

If you are interested let me know and I can do the above in a slightly
different order, but no matter what I will need to learn VHDL first as
the J1 is written in Verilog for a different FPGA than the ones I have so.

Maybe all the above is not necessary as there is a native eForth
implementation available that I just found. Along with it is code to
implement a serial port so the J1 can talk to the outside world.

< https://github.com/samawati/j1eforth >

--
Cecil - k5nwa