byron

I'm back after doing some reading (thanks Elizabeth) and some coding.
I've been thinking about what features should core wordset should
exhibit and wanted to get some input on the matter.

In my original post I wrote:

After some further thought I realize that there needs to be a balance
between minimalism and efficiency. So I've thought up a few rules of
thumb that may be helpful in developing core wordsets:

1. In every major grouping of words (arithmetic, logical, stack, etc.)
there is one word that can be used to derive most of the others in that
group. That word should be in the core wordset.

An example is in the logical group, all basic logic functions can be
derived from NAND. So NAND should be implemented in the core wordset.

2. If a word can be factored, consider putting the factors into the core
wordset. Continuing with NAND, it can be factored into AND and INVERT.
So a consideration should be made into implement the two more basic
words, though NAND can in fact implement both of the other two.

3. If the underlaying hardware implements a word's function natively,
consider recoding the word to use the native function. Three examples
from different groups (and their derivable word in parenthesis):
+ (-), BRANCH (?BRANCH), OR (NAND). While each of these words are
derivable from other words, they can be efficiently recoded to use the
native functionality.

4. Definitely consider recoding a word natively when there is a bunch of
complexity implementing with derived words. There is a fragment in a
c.l.f discussion named "What is Minimum Assembly Coded Words set in
Forth?" from 11 years ago where I believe Bernd Paysan shows how to
implement a right shift using only a NAND and =0. It literally tested
each bit in the original word and set the bit one bit position down if
the original bit was set. Painful but doable.

One question I have is if you have to implement multibyte operations by
hand (+,-, comparisons) is it better to use big endian or little endian
representation in memory? I found that ANS is neutral on the issue and
that either representation is compliant.

BAJ

elizabeth d rather

You're on the right track, but there's no point in restricting yourself
unnecessarily. No point in writing more words twice than is necessary;
some of these words are easier to do in code than high level anyway,
particularly since you say you're very familiar with PIC code.

Following is a rough list of the low-level code primitives we do in code:

* Structure words (run-time for DO, LOOP, IF, etc.)
* CREATE run-time
* 15 data stack primitives
* 9 R-stack primitives (including I & J)
* Logic: AND OR XOR INVERT
* 11 Arithmetic primitives (including some optimizations like 1+ and 2*
which have native instruction support)
* Misc: ALIGNED LSHIFT RSHIFT
* 12 comparison operators
* 5 memory access words (@ ! etc.)
* EXECUTE

On an 8051 these comprise about 1K (not counting heads, of course, since
we keep heads in the host). We've evolved this standard set over many
years, so doing the list for a new processor is pretty automatic.

There are some more code words in our systems, including support for the
multitasker, clock, I/O, etc., but I'm not including them as you're
asking about kernel stuff.

That really depends on the instruction set for the processor and the
"culture" using that processor (that is, what do most PIC programmers
do?). This is why ANS is neutral on the issue. Strive for whatever
makes the code cleanest.

Also, take care to allocate your registers in such a way as to make your
code simple and clean. Pick registers to use for S and R (stack
pointers), write a few primitives, and see if a different choice would
simplify.

Cheers,
Elizabeth


--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

mikael nordman

I really recommend for you to switch to the PIC 18Fxxxx series.

It is much better suited for hosting a forth VM for a incrementeal
programming style.

It features selfprogramming flash in 64 byte blocks, and the
program memory can easily be read via a pointer register.
It has three ram pointer registers and a readable and writable 16 bit
wide, 31 cells deep, HW return stack.
Also you get enough memory (ram 1.5 - 4 kbytes, flash 16 -128 kbytes,
eeprom 256 - 1024 bytes ).

The 18F also comes in convienient DIP packages with the nice PIC
peripherals.

I have also looked at the PIC24 series but it has a flash block erase
size of 1536 bytes which is not convinient for incremental writes. You
would need to waste 1536 bytes of ram for holding data during the flash
erase procedure.

Mikael
--
http://www.kolumbus.fi/oh2aun - FlashForth

byron

I'm back after doing some reading (thanks Elizabeth) and some coding.
I've been thinking about what features should core wordset should
exhibit and wanted to get some input on the matter.

In my original post I wrote:

After some further thought I realize that there needs to be a balance
between minimalism and efficiency. So I've thought up a few rules of
thumb that may be helpful in developing core wordsets:

1. In every major grouping of words (arithmetic, logical, stack, etc.)
there is one word that can be used to derive most of the others in that
group. That word should be in the core wordset.

An example is in the logical group, all basic logic functions can be
derived from NAND. So NAND should be implemented in the core wordset.

2. If a word can be factored, consider putting the factors into the core
wordset. Continuing with NAND, it can be factored into AND and INVERT.
So a consideration should be made into implement the two more basic
words, though NAND can in fact implement both of the other two.

3. If the underlaying hardware implements a word's function natively,
consider recoding the word to use the native function. Three examples
from different groups (and their derivable word in parenthesis):
+ (-), BRANCH (?BRANCH), OR (NAND). While each of these words are
derivable from other words, they can be efficiently recoded to use the
native functionality.

4. Definitely consider recoding a word natively when there is a bunch of
complexity implementing with derived words. There is a fragment in a
c.l.f discussion named "What is Minimum Assembly Coded Words set in
Forth?" from 11 years ago where I believe Bernd Paysan shows how to
implement a right shift using only a NAND and =0. It literally tested
each bit in the original word and set the bit one bit position down if
the original bit was set. Painful but doable.

One question I have is if you have to implement multibyte operations by
hand (+,-, comparisons) is it better to use big endian or little endian
representation in memory? I found that ANS is neutral on the issue and
that either representation is compliant.

BAJ

elizabeth d rather

You're on the right track, but there's no point in restricting yourself
unnecessarily. No point in writing more words twice than is necessary;
some of these words are easier to do in code than high level anyway,
particularly since you say you're very familiar with PIC code.

Following is a rough list of the low-level code primitives we do in code:

* Structure words (run-time for DO, LOOP, IF, etc.)
* CREATE run-time
* 15 data stack primitives
* 9 R-stack primitives (including I & J)
* Logic: AND OR XOR INVERT
* 11 Arithmetic primitives (including some optimizations like 1+ and 2*
which have native instruction support)
* Misc: ALIGNED LSHIFT RSHIFT
* 12 comparison operators
* 5 memory access words (@ ! etc.)
* EXECUTE

On an 8051 these comprise about 1K (not counting heads, of course, since
we keep heads in the host). We've evolved this standard set over many
years, so doing the list for a new processor is pretty automatic.

There are some more code words in our systems, including support for the
multitasker, clock, I/O, etc., but I'm not including them as you're
asking about kernel stuff.

That really depends on the instruction set for the processor and the
"culture" using that processor (that is, what do most PIC programmers
do?). This is why ANS is neutral on the issue. Strive for whatever
makes the code cleanest.

Also, take care to allocate your registers in such a way as to make your
code simple and clean. Pick registers to use for S and R (stack
pointers), write a few primitives, and see if a different choice would
simplify.

Cheers,
Elizabeth


--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

byron

I'll get there eventually. I literally have a double handful of 16F
parts and a virtually completely development system for them set up.

I think Elizabeth has convinced me that incremental programming is
orthogonal to other issues.


The 16F parts are the same.


Now that has some utility in terms of coding literals. My plan in to
inline literal insertion instead of threading it as a call because since
I'm planning on doing a STC with the hardware PIC 16F stack (which isn't
addressible), I can't read the return address off the stack.

All very cool features. Like I said eventually I'll get there.

Enough is always a relative term. These are microcontrollers, so it's
very likely you're looking at single taking projects anyway.

The one thing that looks possible in the 18F arena is a completely self
hosted forth. With that much flash/ram it should be possible to actually
keep the dictionary and headers onboard.

Which is great for prototyping and hobby work. Another advantage that
the 18F family has is hardware USB and CAN interfaces on some parts. No
16F part carries either.

Ouch! One cheap trick is to attach a SPI/I2C serial FRAM and use it as a
holding area. FRAMS have virtually unlimited read/write life, can be
serially clocked up to 5 Mhz, is byte addressible, and when coupled with a
hardware SPI/I2C interfaces is pretty fast. So one could use it as a
holding area for flash blocks that are being updated and it'll only cost
you 3 I/O pins and possibly your syncronous serial interface.

Incremental developed Forth for the 16F family is a project I should
have tackled 10 years ago. But until recently I only had a dim awareness
of what Forth was all about. There are a ton of better chip families to
do embedded Forth development on. But I feel compelled to leave some
type of mark on PIC 16F Forth development before moving on into those
arenas.

BAJ

mikael nordman

I really recommend for you to switch to the PIC 18Fxxxx series.

It is much better suited for hosting a forth VM for a incrementeal
programming style.

It features selfprogramming flash in 64 byte blocks, and the
program memory can easily be read via a pointer register.
It has three ram pointer registers and a readable and writable 16 bit
wide, 31 cells deep, HW return stack.
Also you get enough memory (ram 1.5 - 4 kbytes, flash 16 -128 kbytes,
eeprom 256 - 1024 bytes ).

The 18F also comes in convienient DIP packages with the nice PIC
peripherals.

I have also looked at the PIC24 series but it has a flash block erase
size of 1536 bytes which is not convinient for incremental writes. You
would need to waste 1536 bytes of ram for holding data during the flash
erase procedure.

Mikael
--
http://www.kolumbus.fi/oh2aun - FlashForth

byron

Elizabeth,

I think (I'll know once I've done some implementation), that there's
some utility is getting a quick win when moving to a new system. We all
agree that a minimally coded kernel will have serious efficiency issues.
But that same minimally coded kernel facilitates getting a forth system
migrated quickly.

The higher level Forth words only needs to be written once. It then
instantly migrates. Consider PLUS and MINUS, which are both
implementable with the other core word:

: PLUS 0 SWAP - - ;
: MINUS INVERT 1 + + ;

Slower than a CODE implementation? Of course. But once it's written and
stuck in a file, you know they work.

So one can code the small subset, drop the rest of the high level kernel
in place and have a working, albeit slow, system. Then one recodes a
larger set incrementally, while mainting a working (but getting faster)
system as you go along.

You are correct that in this instance I know PIC code very well. But if
I were moving to a new chip architecture that I didn't know well, it
would be nice to only have a code a small subset to get migration going
and some testing on the target done.


Wow! That is quite a daunting set to tackle.


And absolutely necessary for a professional outfit like Forth Inc. It
has a completely different view for one hobby guy who really just wants
to noodle with new architectures.

The PIC is strictly a 8 bit machine. There is absolutely no standard in
terms of multibute numeric representations. IIRC I implemented by 16 bit
numbers as big endian primarily for readability in the simulator. Just
off the cuff little endian would be a win because both addition and
subtraction need to work on the LSB first.


The one optimization I plan from the jump is to keep the TOS in a
register. Since the PIC only has a single index register, it's important
to make the TOS (for the data stack) directly addressible.

Thanks,

BAJ

mikael nordman

I spent last winter doing just that. The result is FlashForth.
You can find it at www.kolumbus.fi/oh2aun

Always nice to leave a mark, :-)
I was considering doing a self hosted PIC forth a few years back, but
really the PIC18F made it possible. There are other better chips, but
for hobbyists the PICs are quite optimal.

Mikael

byron

I'll get there eventually. I literally have a double handful of 16F
parts and a virtually completely development system for them set up.

I think Elizabeth has convinced me that incremental programming is
orthogonal to other issues.


The 16F parts are the same.


Now that has some utility in terms of coding literals. My plan in to
inline literal insertion instead of threading it as a call because since
I'm planning on doing a STC with the hardware PIC 16F stack (which isn't
addressible), I can't read the return address off the stack.

All very cool features. Like I said eventually I'll get there.

Enough is always a relative term. These are microcontrollers, so it's
very likely you're looking at single taking projects anyway.

The one thing that looks possible in the 18F arena is a completely self
hosted forth. With that much flash/ram it should be possible to actually
keep the dictionary and headers onboard.

Which is great for prototyping and hobby work. Another advantage that
the 18F family has is hardware USB and CAN interfaces on some parts. No
16F part carries either.

Ouch! One cheap trick is to attach a SPI/I2C serial FRAM and use it as a
holding area. FRAMS have virtually unlimited read/write life, can be
serially clocked up to 5 Mhz, is byte addressible, and when coupled with a
hardware SPI/I2C interfaces is pretty fast. So one could use it as a
holding area for flash blocks that are being updated and it'll only cost
you 3 I/O pins and possibly your syncronous serial interface.

Incremental developed Forth for the 16F family is a project I should
have tackled 10 years ago. But until recently I only had a dim awareness
of what Forth was all about. There are a ton of better chip families to
do embedded Forth development on. But I feel compelled to leave some
type of mark on PIC 16F Forth development before moving on into those
arenas.

BAJ