Planning to write forth for a DSP

[Hannu Vuolasaho]

Hello!

I have VS1005 developer board from VLSI Solution in front of me and I'm
curious if I could write some kind of forth for it.

I'm targeting hobby toy forth which could do something useful. Still
something more elegant than bunch of C function pointers in a struct.

Environment has C compiler, assembler and there is even OS available.

The HW has some nice features like two memories and looping hardware.
Also some parallel execution is provided by the hardware. OS has
dynamical loading and many neat features.

However there isn't that much memory available. 32kWord I, X and Y ram each.

And as usual, googling for forth is rather hard task so getting good
references or ideas isn't really easy.

So far I've thought about only memory configuration and calling
convention. The stacks and other data should go to X memory and
dictionary to Y. When the forth starts, it saves context to C stack
pointer and after that it can run nicely. Two I registers goes to D and
R stack. Somewhere there has to be input buffer an the position of it.

Also I've given some though to build binary image file to run with the
forth system so that the memory wouldn't be an issue but that isn't yet
a really important thing. And it would require some operating system
interfacing.

So what should I read next? What should I think more before I start to
hacking something together and make the grand design mistake?

Hannu Vuolasaho

[Richard Owlett]

On 8/20/2016 12:28 PM, Hannu Vuolasaho wrote:
> Hello!
>
> I have VS1005 developer board from VLSI Solution in front of me
> and I'm curious if I could write some kind of forth for it.
>
> I'm targeting hobby toy forth which could do something useful.
> Still something more elegant than bunch of C function pointers in
> a struct.

I'm not expert in either Forth or DSP, but you might wish to
describe your goals over on comp.dsp .

[rickman]

It might be helpful for dealing with the DSP stuff, but they won't
understand Forth I think. They tend to be high level math and algorithm
types there.

--

Rick C

[Hannu Vuolasaho]

The comp.dsp group is really good source of information. When I was
teenager I read it all the time (and still reading) and learned my math
from there. However my current problem is "How to implement a Forth" and
as Rickman wrote, they think math.

I know here are many people who are implemented different kinds of
forths. I just like to implement one more on a very funny platform and
know some problems before hitting them with almost working system. And
even the chip is DSP, it is also microcontroller. Beefier than AVR and
weaker than ARM.

--
Hannu Vuolasaho

[rickman]

What DSP chip are you considering? Anything "weaker" than an ARM is not
going to be a very powerful DSP. Are you thinking of the Piccolo and
related series? That would be a very nice line to have a Forth
development system for.

--

Rick C

[Paul Rubin]

Hannu Vuolasaho <vuokk...@gmail.com> writes:
> However my current problem is "How to implement a Forth"

There's lots of classic literature on implementing Forth. Brad
Rodriguez has some nice pages to start with:

http://www.bradrodriguez.com/papers/moving1.htm

> And even the chip is DSP, it is also microcontroller. Beefier than AVR
> and weaker than ARM.

Your programs will likely want to use the special capabilities that make
the processor a DSP: zero-overhead loops, MAC from separate X and Y
memory, bit reversal instructions, etc. So you'll need assembly code or
special Forth words to make this stuff happen in your main DSP
algorithms. Forth could be ok for ancillary control code.

[rickman]

Typically DSP is done with a library of subroutines which are optimized
for the various tasks. Inner loops need to be optimized but the rest
can often be conventional programming. So a few DSP words coded in
assembly or calling a separate library should do the trick.

--

Rick C

[Hannu Vuolasaho]

It is audio DSP. Maybe my idea of ARM is stronger than other ARMs. For
me ARM is something which can be found in cell phones. However I know
there are weaker versions like STM32F0.

VS1005 is the chip:
http://www.vlsi.fi/en/products/vs1005.html

And I'm doing this for fun and maybe give some ideas if someone is later
working with similar environment.

--
Hannu Vuolasaho

[Chris Curl]

You might consider building a Forth VM using the C compiler and loading
it with a pre-built Forth dictionary, similar to what I am working on
here ...

https://github.com/CCurl/Forth_C

For reference, when I build it as a 16-bit system, it easily fits in 8K
bytes. And it has more than a few words in it that you wouldn't need in an
embedded implementation.

Just a thought ...

[foxaudio...@gmail.com]

Since you have an Assembler, you could look at Your Forth by Albert Van Der Horst. It provides you with a source code example, albeit Intel, but also running commentary on what it means. Would take some time to translate, but the skeleton is there for you dress up.

https://github.com/tangentstorm/yourforth

BF

[Mikael Nordman]

I have written Flashforth for the pic33 dsp.
It just normal forth that can be used to call and manage dsp routines written in assembly.
Typically the dsp routines are called from a peripheral or timer interrupt.

One challenge is the x y memory management so that dsp routine memory does not clash with the forth allot mechanism.

M

[foxaudio...@gmail.com]

Looking quickly at the document it appears that creating Forth system and Forth
Assembler for this machine would reap some benefits. The architecture is
memory limited and the different memory spaces are distinct. 32bits and 2 16
bit spaces.

Since Forth is a fetch/store machine one could code @,! +! ',' ALLOT etc for
the 32bit code space and code X@ X! X, X+! XALLOT and Y@ Y! Y, Y+! YALLOT for
the 2 data spaces.

This kind of thing was done for segmented memory intel machines with @L !L etc...

The documents even mentioned how to code in C using static allocation to
prevent blowing up stack memory.

Forth let's you decide completely how to use memory.

Creating assembler could be a challenge, this machine optimally can do the
following in one clock:

"When hardware looping and ring buffer capability is added to this, VSDSP
can at its most perform two 16-bit data reads, one 16-bit 16-bit to 32-bit
multiplication (with automatic boundary checking and saturation), one 40-bit
sum (with boundary checking and saturation), two pointer updates with ring
buffer boundary checks, and a loop update and loop end condition check, all of
these in one single clock cycle.

It will take some serious time to replicate all the stuff they have created in
C. It might make sense to create a Forth way to Call C modules while you are
creating this thing.

BF

[Albert van der Horst]

In article <39a98c80-7d90-4281...@googlegroups.com>,

<foxaudio...@gmail.com> wrote:
>On Monday, August 22, 2016 at 11:42:53 PM UTC-4, Chris Curl wrote:
>> On Saturday, August 20, 2016 at 1:28:10 PM UTC-4, Hannu Vuolasaho wrote:
>> > Hello!

>> >=20
>> > I have VS1005 developer board from VLSI Solution in front of me and I'm=
>=20

>> > curious if I could write some kind of forth for it.

>> >=20
>> > I'm targeting hobby toy forth which could do something useful. Still=20

>> > something more elegant than bunch of C function pointers in a struct.

>> >=20

>> > Environment has C compiler, assembler and there is even OS available.

>> >=20
>> > The HW has some nice features like two memories and looping hardware.=
>=20
>> > Also some parallel execution is provided by the hardware. OS has=20

>> > dynamical loading and many neat features.

>> >=20
>> > However there isn't that much memory available. 32kWord I, X and Y ram =
>each.
>> >=20
>> > And as usual, googling for forth is rather hard task so getting good=20

>> > references or ideas isn't really easy.

>> >=20
>> > So far I've thought about only memory configuration and calling=20
>> > convention. The stacks and other data should go to X memory and=20
>> > dictionary to Y. When the forth starts, it saves context to C stack=20
>> > pointer and after that it can run nicely. Two I registers goes to D and=
>=20

>> > R stack. Somewhere there has to be input buffer an the position of it.

>> >=20
>> > Also I've given some though to build binary image file to run with the=
>=20
>> > forth system so that the memory wouldn't be an issue but that isn't yet=
>=20
>> > a really important thing. And it would require some operating system=20
>> > interfacing.
>> >=20
>> > So what should I read next? What should I think more before I start to=
>=20

>> > hacking something together and make the grand design mistake?

>> >=20
>> > Hannu Vuolasaho
>>=20
>> You might consider building a Forth VM using the C compiler and loading=
>=20
>> it with a pre-built Forth dictionary, similar to what I am working on=20
>> here ...
>>=20
>> https://github.com/CCurl/Forth_C
>>=20
>> For reference, when I build it as a 16-bit system, it easily fits in 8K=
>=20
>> bytes. And it has more than a few words in it that you wouldn't need in a=
>n
>> embedded implementation.
>>=20
>> Just a thought ...
>
>Since you have an Assembler, you could look at Your Forth by Albert Van Der=
> Horst. It provides you with a source code example, albeit Intel, but also=
> running commentary on what it means. Would take some time to translate, bu=

>t the skeleton is there for you dress up.
>
>https://github.com/tangentstorm/yourforth

I was on holiday. Anyway for a project like yours I see the following
advantages in yourforth. (Actually I design it with your kind of
project in mind).

1. avoiding c libraries make for a simple build mechamism
just assembling saves time (more than you think).
2. it is assembler yes, but you can't avoid writing + in
assembler anyway.
3. Headers and the lookup mechanism are brutally simple.
4. Nothing is written in assembler for the heck of it, or
for speed obsession. Each assembler word is basic and useful
in more than a single context.
5. Number output is single precision only. An excursion via
double precision for all words (or a duplication) makes
no sense for you.

It is improbable that sophistication present in an
example Forth makes sense for your DSP. You're one step ahead
with yourforth, if you want to add sophistication because
you don't have to delete the sophistication that is there.

If any words missing are important for you, you may find them
in the ciforth source library. (lina wina).

All Forth legacy burdens have been cut. The resulting
ISO Forth incompatiblities will be inconsequential for
you (hopefully).

>
>BF

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst