Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37348 > unrolled thread

What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth

Back to article view | Back to comp.lang.forth

Contents

  What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth JUERGEN <epldfpga@aol.com> - 2015-03-17 12:47 -0700
    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-17 22:29 +0100
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-18 10:59 +0000
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 12:04 +0100
          Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-18 11:19 +0000
            Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 12:39 +0100
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2015-03-18 08:05 -1000
                Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-18 18:34 +0000
                Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 20:05 +0100
    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-03-17 19:11 -0400
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-19 00:28 -0400
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth rickman <gnuarm@gmail.com> - 2015-03-20 01:00 -0400
    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 11:33 +0100
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-18 22:15 +0100
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-19 07:53 +0100
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth visualforth@rocketmail.com - 2015-03-19 17:17 -0700
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth rickman <gnuarm@gmail.com> - 2015-03-20 01:01 -0400
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-18 18:42 -0400
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Alex McDonald" <blog@rivadpm.com> - 2015-03-18 23:56 +0000
          Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-19 02:46 +0100
            Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Alex McDonald" <blog@rivadpm.com> - 2015-03-19 09:27 +0000
          Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-18 22:21 -0400
            Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Alex McDonald" <blog@rivadpm.com> - 2015-03-19 09:43 +0000
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-20 02:09 -0400
                Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Alex McDonald" <blog@rivadpm.com> - 2015-03-20 15:41 +0000
                  Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-29 16:23 -0400
                    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth rickman <gnuarm@gmail.com> - 2015-03-29 16:43 -0400
                    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Alex McDonald" <blog@rivadpm.com> - 2015-03-29 22:53 +0100
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-19 08:00 +0100
          Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-20 02:09 -0400
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-20 14:43 +0100
        ...Tiny targets Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-03-23 15:26 +0100
          Re: ...Tiny targets Paul Rubin <no.email@nospam.invalid> - 2015-03-23 10:39 -0700
          Re: ...Tiny targets JUERGEN <epldfpga@aol.com> - 2015-03-24 01:18 -0700
            Re: ...Tiny targets Paul Rubin <no.email@nospam.invalid> - 2015-03-24 17:45 -0700
              Re: ...Tiny targets JUERGEN <epldfpga@aol.com> - 2015-03-25 00:08 -0700
                Re: ...Tiny targets Paul Rubin <no.email@nospam.invalid> - 2015-03-25 00:43 -0700
                  Re: ...Tiny targets Gary Bergstrom <forthprgrmr@gmail.com> - 2015-03-25 07:07 -0700
                    Re: ...Tiny targets Paul Rubin <no.email@nospam.invalid> - 2015-03-25 08:06 -0700
                      Re: ...Tiny targets rickman <gnuarm@gmail.com> - 2015-03-25 15:19 -0400
                        Re: ...Tiny targets Paul Rubin <no.email@nospam.invalid> - 2015-03-25 12:39 -0700
                        Re: ...Tiny targets Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-25 20:42 +0100
                          Re: ...Tiny targets rickman <gnuarm@gmail.com> - 2015-03-25 16:41 -0400
                          Re: ...Tiny targets hughaguilar96@gmail.com - 2015-03-25 22:32 -0700
                            Re: ...Tiny targets "Alex McDonald" <blog@rivadpm.com> - 2015-03-26 09:35 +0000
                              Re: ...Tiny targets Ron Aaron <rambamist@gmail.com> - 2015-03-26 14:52 +0200
                              Re: ...Tiny targets rickman <gnuarm@gmail.com> - 2015-03-27 16:12 -0400
                            Re: ...Tiny targets albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-26 13:00 +0000
                          Re: ...Tiny targets anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-26 11:58 +0000
                  Re: ...Tiny targets JUERGEN <epldfpga@aol.com> - 2015-03-25 07:10 -0700
                  Re: ...Tiny targets JUERGEN <epldfpga@aol.com> - 2015-03-25 07:16 -0700
              Re: ...Tiny targets Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-03-27 13:01 +0100
    Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Gary Bergstrom <forthprgrmr@gmail.com> - 2015-03-18 06:45 -0700
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth JUERGEN <epldfpga@aol.com> - 2015-03-18 08:57 -0700
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 20:09 +0100
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth JUERGEN <epldfpga@aol.com> - 2015-03-18 08:59 -0700
      Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth hughaguilar96@gmail.com - 2015-03-20 21:47 -0700
        Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth JUERGEN <epldfpga@aol.com> - 2015-03-21 02:30 -0700
          Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth hughaguilar96@gmail.com - 2015-03-21 17:52 -0700
            Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth JUERGEN <epldfpga@aol.com> - 2015-03-22 01:27 -0700
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth hughaguilar96@gmail.com - 2015-03-22 13:15 -0700
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth hughaguilar96@gmail.com - 2015-03-22 13:47 -0700
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth rickman <gnuarm@gmail.com> - 2015-03-22 18:39 -0400
              Re: What is the minimum Word set you could live with to have a (limping) Beginner's ANS Forth hughaguilar96@gmail.com - 2015-03-22 16:32 -0700
              Re: What is the minimum Word set you could live with to have a(limping) Beginner's ANS Forth "WJ" <w_a_x_man@yahoo.com> - 2015-03-26 06:35 +0000
                Re: What is the minimum Word set you could live with to have a(limping) Beginner's ANS Forth rickman <gnuarm@gmail.com> - 2015-03-27 15:55 -0400
                  Re: What is the minimum Word set you could live with to have a(limping) Beginner's ANS Forth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-28 03:36 -0400
            Re: What is the minimum Word set you could live with to have a(limping) Beginner's ANS Forth "WJ" <w_a_x_man@yahoo.com> - 2015-03-26 06:34 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#37428

on 19/03/2015 01:46:50, Bernd Paysan wrote:
> Alex McDonald wrote:
>> Shifting state has its own problems. A word expects a certain state for
>> the tokens it will execute. There is one workable option; save the state
>> on entry to each word, set the required state, and restore on exit. Needs
>> a stack of states; possibly on the return stack. That would double the
>> size of the stack required, assuming cell-sized states.
>>
>> Either way, the extra overhead is burdensome. It has parallels with shift
>> character encoding issues, and those are neatly solved by (for example)
>> UTF-8. That would suggest a 4 bit encoding somewhat like this (note I
>> haven't checked this for correctness);
>>
>> 0xxx                8 codes
>> 100x 11xx           8 codes
>> 1010 11xx 11xx      16 codes
>> 1011 11xx 11xx 11xx 64 codes
>>
>> It's self aligning; we can always work out instruction boundaries
>> backwards or forwards even though they are variable length. No state is
>> required, and longer sequences can be used for less frequent operations.
> 
> If you want less overhead, adopt protobuf variable length encoding.
> Reduced to 4 bits per symbol, that would be:
> 
> 0xxx                   8 codes
> 1xxx 0xxx             64 codes
> 1xxx 1xxx 0xxx       512 codes
> 1xxx 1xxx 1xxx 0xxx 4096 codes
> 
> The "disadvantge" of protobuf compared to UTF-8 is that the first
> symbol does not denote the entire length of the complete token. But it
> is a denser encoding, so overall, it's a win.
> 
> We could have an ASCII-compatible UTF-protobuf, as well.
> 

That's much denser, although in 4 bit incarnations both suffer from a
high pattern bit overhead.

I'm always struck by the only partially patterned x86 opcodes. My
assembler and disassembler for it is only table driven for small sections
of the opcode space. There are more exceptions that there are rules.

The usefulness of these encodings is in the simple decoding. Doing the
lookup to translate token into address can be done with tables alone. The
self-synchronising attribute of UTF is I suppose not really required,
since our simple opcodes have no address fields or constants or other
niceties that real life requires. Even zero address Forth requires some
way of getting a constant in the instruction set.

[toc] | [prev] | [next] | [standalone]

#37421

On Wed, 18 Mar 2015 19:56:06 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 18/03/2015 22:42:31, "Rod Pemberton" wrote:
>> On Wed, 18 Mar 2015 06:33:12 -0400, Lars Brinkhoff
>> <lars.spam@nocrew.org> wrote:
>>> JUERGEN <epldfpga@aol.com> wrote:

>>>>> But for a project we would like to have a list of words that
>>>>> fit into 4 bits - so 16 words max to be used.
>>>>> Any good suggestions?
>>>
>>> My suggestion might be:
>>>
>>> Definitions:          dodoes exit
>>> Control flow:         0branch
>>> Literals:             (literal)
>>> Memory access:        ! @ c! c@
>>> Aritmetic/logic:      + nand
>>> Return stack:         >r r>
>>>
>>> Of course, c! and c@ may be optional if you're content with cell-sized
>>> characters.  I experimented with removing 0branch, (literal), >r, and
>>> r>, but the resulting system became orders of magnitude slower.
>>>
>>> Add to this some of DUP, SWAP, OVER, DROP, 0<, etc.  Or maybe you need
>>> access to the stack pointers: SP@, SP!, RP@, RP!.
>>
>> As my other post indicates, it's going to be hard to live with only
>> 16 primitive (or low-level) words maximum.
>>
>> So, he might be interested in a shift-state. E.g., perhaps an
>> instruction could be used to shift between two sets of 16 words. That
>> would provide a total of 30 words, not including the shift word in
>> both states/sets.
>>
>
> Shifting state has its own problems. A word expects a certain state
> for the tokens it will execute.

Only when the primitives (low-level words) are executed does the state
need to be correct or correctly switched.

E.g., for a word in the first set you do nothing.  For a word in the
second set, you could switch to the second state, execute a primitive
   from the second set, switch back to the first.  Each instruction in
the second set would be wrapped with the switch words.  Let's say the
zero'th instruction is the switch word.  To execute one instruction
   from the first set (3rd) and one instruction from the second set (4th):

     set1_3rd set1_0th(switch) set2_4th set2_0th(switch)

In pure Forth it would look something like the following if SWAP
is in set1 and >R is in set2:

      SWAP SWITCH >R SWITCH

Since these are primitives, the SWITCH wrapper can be part of
the low-level code for each set2 instruction.

Obviously, you'd attempt to put less frequently used words in the
second set due to the overhead.  The advantage here is there is no
need to decode instructions based on bits as your (snipped) example
would need.  Zero is also easy to detect.  Philip Koopman's or
Anton Ertl's instruction frequencies could be used to help decide
which set is which.


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[toc] | [prev] | [next] | [standalone]

#37429

on 19/03/2015 02:21:41, "Rod Pemberton" wrote:
> On Wed, 18 Mar 2015 19:56:06 -0400, Alex McDonald <blog@rivadpm.com>
> > wrote:
>> on 18/03/2015 22:42:31, "Rod Pemberton" wrote:
> > wrote:
>>> On Wed, 18 Mar 2015 06:33:12 -0400, Lars Brinkhoff
> > wrote:
>>> <lars.spam@nocrew.org> wrote:
> > wrote:
>>>> JUERGEN <epldfpga@aol.com> wrote:
> wrote:
> 
>>>>>> But for a project we would like to have a list of words that
>>>>>> fit into 4 bits - so 16 words max to be used.
>>>>>> Any good suggestions?
>>>>
>>>> My suggestion might be:
>>>>
>>>> Definitions:          dodoes exit
>>>> Control flow:         0branch
>>>> Literals:             (literal)
>>>> Memory access:        ! @ c! c@
>>>> Aritmetic/logic:      + nand
>>>> Return stack:         >r r>
>>>>
>>>> Of course, c! and c@ may be optional if you're content with cell-sized
>>>> characters.  I experimented with removing 0branch, (literal), >r, and
>>>> r>, but the resulting system became orders of magnitude slower.
>>>>
>>>> Add to this some of DUP, SWAP, OVER, DROP, 0<, etc.  Or maybe you need
>>>> access to the stack pointers: SP@, SP!, RP@, RP!.
>>>
>>> As my other post indicates, it's going to be hard to live with only
>>> 16 primitive (or low-level) words maximum.
>>>
>>> So, he might be interested in a shift-state. E.g., perhaps an
>>> instruction could be used to shift between two sets of 16 words. That
>>> would provide a total of 30 words, not including the shift word in
>>> both states/sets.
>>>
>>
>> Shifting state has its own problems. A word expects a certain state
>> for the tokens it will execute.
> 
> Only when the primitives (low-level words) are executed does the state
> need to be correct or correctly switched.
> 

Every word hits bottom at some point, and the state has to be correct.
You either remember the state in a stack, or you use one of your 8
opcodes in both sets to switch in and out on every instruction that is in
the second set.
 
> E.g., for a word in the first set you do nothing.  For a word in the
> second set, you could switch to the second state, execute a primitive
> from the second set, switch back to the first.  Each instruction in
> the second set would be wrapped with the switch words.  Let's say the
> zero'th instruction is the switch word.  To execute one instruction
> from the first set (3rd) and one instruction from the second set
> (4th):
> 
> set1_3rd set1_0th(switch) set2_4th set2_0th(switch)
> 
> In pure Forth it would look something like the following if SWAP
> is in set1 and >R is in set2:
> 
> SWAP SWITCH >R SWITCH

SWITCH needs to be in set 1 and set 2, and now we have a 3 nibble opcode
with only 7 opcodes in the encoding space...

> 
> Since these are primitives, the SWITCH wrapper can be part of
> the low-level code for each set2 instruction.

You've now got a prefix for a 2 nibble opcode; it's no longer shift in
and out.

> 
> Obviously, you'd attempt to put less frequently used words in the
> second set due to the overhead.  The advantage here is there is no
> need to decode instructions based on bits as your (snipped) example
> would need.  

Any encoding that uses regular bit patterns, such as the UTF example, can
be table decoded at exactly the same cost per nibble or byte.


> Zero is also easy to detect.  Philip Koopman's or
> Anton Ertl's instruction frequencies could be used to help decide
> which set is which.
> 
> 
> Rod Pemberton
> 

[toc] | [prev] | [next] | [standalone]

#37458

On Thu, 19 Mar 2015 05:43:57 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 19/03/2015 02:21:41, "Rod Pemberton" wrote:
>> On Wed, 18 Mar 2015 19:56:06 -0400, Alex McDonald <blog@rivadpm.com>
>> > wrote:
>>> on 18/03/2015 22:42:31, "Rod Pemberton" wrote:
>> > wrote:
>>>> On Wed, 18 Mar 2015 06:33:12 -0400, Lars Brinkhoff
>> > wrote:
>>>> <lars.spam@nocrew.org> wrote:
>> > wrote:
>>>>> JUERGEN <epldfpga@aol.com> wrote:
>> wrote:

>>>>>>> But for a project we would like to have a list of words that
>>>>>>> fit into 4 bits - so 16 words max to be used.
>>>>>>> Any good suggestions?
>>>>>
>>>>> My suggestion might be:
>>>>>
>>>>> Definitions:          dodoes exit
>>>>> Control flow:         0branch
>>>>> Literals:             (literal)
>>>>> Memory access:        ! @ c! c@
>>>>> Aritmetic/logic:      + nand
>>>>> Return stack:         >r r>
>>>>>
>>>>> Of course, c! and c@ may be optional if you're content with  
>>>>> cell-sized
>>>>> characters.  I experimented with removing 0branch, (literal), >r, and
>>>>> r>, but the resulting system became orders of magnitude slower.
>>>>>
>>>>> Add to this some of DUP, SWAP, OVER, DROP, 0<, etc.  Or maybe you  
>>>>> need
>>>>> access to the stack pointers: SP@, SP!, RP@, RP!.
>>>>
>>>> As my other post indicates, it's going to be hard to live with only
>>>> 16 primitive (or low-level) words maximum.
>>>>
>>>> So, he might be interested in a shift-state. E.g., perhaps an
>>>> instruction could be used to shift between two sets of 16 words. That
>>>> would provide a total of 30 words, not including the shift word in
>>>> both states/sets.
>>>>
>>>
>>> Shifting state has its own problems. A word expects a certain state
>>> for the tokens it will execute.
>>
>> Only when the primitives (low-level words) are executed does the state
>> need to be correct or correctly switched.
>>
>
> Every word hits bottom at some point, and the state has to be correct.
> You either remember the state in a stack, or you use one of your 8
> opcodes in both sets to switch in and out on every instruction that is in
> the second set.

As stated, it's the latter.

>> E.g., for a word in the first set you do nothing.  For a word in the
>> second set, you could switch to the second state, execute a primitive
>> from the second set, switch back to the first.  Each instruction in
>> the second set would be wrapped with the switch words.  Let's say the
>> zero'th instruction is the switch word.  To execute one instruction
>> from the first set (3rd) and one instruction from the second set
>> (4th):
>>
>> set1_3rd set1_0th(switch) set2_4th set2_0th(switch)
>>
>> In pure Forth it would look something like the following if SWAP
>> is in set1 and >R is in set2:
>>
>> SWAP SWITCH >R SWITCH
>
> SWITCH needs to be in set 1 and set 2, and now we have a 3 nibble
> opcode with only 7 opcodes in the encoding space...
>

Yes, but the second set is expected to be used far less frequently.
E.g., look at my post that lists Koopman's and Ertl's data.
The first 15 or so (from Koopman and Ertl) are found to be much
more common by both.  The second 15 or so (from Ertl) are used far
less frequently.  I.e., with the balance of execution happening
against the first wordset, the increased overhead is probably not
as bad as perceived.  And, if speed is of no concern to the OP,
space probably isn't either.

>> Since these are primitives, the SWITCH wrapper can be part of
>> the low-level code for each set2 instruction.
>
> You've now got a prefix for a 2 nibble opcode; it's no longer
> shift in and out.

...

>> Obviously, you'd attempt to put less frequently used words in the
>> second set due to the overhead.  The advantage here is there is no
>> need to decode instructions based on bits as your (snipped) example
>> would need.
>
> Any encoding that uses regular bit patterns, such as the UTF example,
> can be table decoded at exactly the same cost per nibble or byte.

Is it any easier to implement than detecting one opcode?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#37476

on 20/03/2015 06:09:38, "Rod Pemberton" wrote:
> On Thu, 19 Mar 2015 05:43:57 -0400, Alex McDonald <blog@rivadpm.com>

[snip]

> Yes, but the second set is expected to be used far less frequently.
> E.g., look at my post that lists Koopman's and Ertl's data.
> The first 15 or so (from Koopman and Ertl) are found to be much
> more common by both.  The second 15 or so (from Ertl) are used far
> less frequently.  I.e., with the balance of execution happening
> against the first wordset, the increased overhead is probably not
> as bad as perceived. 

This is a TTC or "token threaded code", which also requires a token for
every word, and that includes user defined words. How do you propose
supporting user defined words in your scheme?

TTCs are lightly covered in
http://www.bradrodriguez.com/papers/moving1.htm.

[snip]

>>
>> Any encoding that uses regular bit patterns, such as the UTF example,
>> can be table decoded at exactly the same cost per nibble or byte.
> 
> Is it any easier to implement than detecting one opcode?

Since it's all done with trivial index table lookups, yes. The only
disadvantge of a UTF type encoding is the encoding overhead for a 4 bit
nibble. Bernd's suggestion of protobuf encoding with 1 bit overhead per
nibble results in a much more compact representation and a reduction in
the decoding overhead since there are fewer nibbles to process. 

[toc] | [prev] | [next] | [standalone]

#37736

On Fri, 20 Mar 2015 11:41:08 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 20/03/2015 06:09:38, "Rod Pemberton" wrote:
>> On Thu, 19 Mar 2015 05:43:57 -0400, Alex McDonald <blog@rivadpm.com>
> [snip]

>> Yes, but the second set is expected to be used far less frequently.
>> E.g., look at my post that lists Koopman's and Ertl's data.
>> The first 15 or so (from Koopman and Ertl) are found to be much
>> more common by both.  The second 15 or so (from Ertl) are used far
>> less frequently.  I.e., with the balance of execution happening
>> against the first wordset, the increased overhead is probably not
>> as bad as perceived.
>
> This is a TTC or "token threaded code", which also requires a token for
> every word, and that includes user defined words. How do you propose
> supporting user defined words in your scheme?

What exactly is token TTC here? ...

Did you mean the Forths used Ertl's data or Koopman's data are TTC? ...
Or, did you mean your mis-perceived understanding of what was said?

We were discusing the minimal set of primitives to be used for Forth.
ITC, DTC, TTC, and STC, is of no concern in regards to primitives.
The primitives (or low-level Forth words) don't constitute the code
which is interpreted by the Forth interpreter, where used.  I.e.,
these primitives may appear to you to be tokens, since there is only
a small quantity of them, but that doesn't make the Forth used TTC
interpreter.  The high-level words are what is interpreted by the
interpreter, as ITC, DTC, and TTC, but there must still be a method
to directly execute compiled assembly or high-level code in a
non-Forth language.  That's were these primitives come in.

>>> Any encoding that uses regular bit patterns, such as the UTF example,
>>> can be table decoded at exactly the same cost per nibble or byte.
>>
>> Is it any easier to implement than detecting one opcode?
>
> Since it's all done with trivial index table lookups, yes. The only
> disadvantge of a UTF type encoding is the encoding overhead for a 4 bit
> nibble. Bernd's suggestion of protobuf encoding with 1 bit overhead per
> nibble results in a much more compact representation and a reduction in
> the decoding overhead since there are fewer nibbles to process.

FYI, a lookup takes far more computation and time than a branch.
Decoding nybbles requires a small routine, even on x86 which
has special instructions which do so.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#37738

On 3/29/2015 4:23 PM, Rod Pemberton wrote:
> On Fri, 20 Mar 2015 11:41:08 -0400, Alex McDonald <blog@rivadpm.com> wrote:
>> on 20/03/2015 06:09:38, "Rod Pemberton" wrote:
>>> On Thu, 19 Mar 2015 05:43:57 -0400, Alex McDonald <blog@rivadpm.com>
>> [snip]
>
>>> Yes, but the second set is expected to be used far less frequently.
>>> E.g., look at my post that lists Koopman's and Ertl's data.
>>> The first 15 or so (from Koopman and Ertl) are found to be much
>>> more common by both.  The second 15 or so (from Ertl) are used far
>>> less frequently.  I.e., with the balance of execution happening
>>> against the first wordset, the increased overhead is probably not
>>> as bad as perceived.
>>
>> This is a TTC or "token threaded code", which also requires a token for
>> every word, and that includes user defined words. How do you propose
>> supporting user defined words in your scheme?
>
> What exactly is token TTC here? ...
>
> Did you mean the Forths used Ertl's data or Koopman's data are TTC? ...
> Or, did you mean your mis-perceived understanding of what was said?

Token threaded code means there is no native instructions or addresses 
for the Forth code, rather a token or ID is used.  Just as Forth is the 
language of a virtual machine, the tokens would be the machine code for 
the virtual machine.


> We were discusing the minimal set of primitives to be used for Forth.

Not sure who "we" includes, but the OP is asking about a virtual Forth 
CPU with 16 instructions which will be the most efficient for 
implementing Forth.  Or maybe I misunderstand him.  His posts tend to 
jump around a bit and can be hard to follow.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#37742

on 29/03/2015 21:23:45, "Rod Pemberton" wrote:


> Decoding nybbles requires a small routine, even on x86 which
> has special instructions which do so.

It does? What are they? 

[toc] | [prev] | [next] | [standalone]

#37426

"Rod Pemberton" <bork@lllljunkqwer.cpm> writes:
> As my other post indicates, it's going to be hard to live with only
> 16 primitive (or low-level) words maximum.

I disagree.  My toy Forth is based on 12 primitives.  It's quite slow,
but will boot, metacompile, and run some tests in under a minute.  And
the OP stated that speed is of no concern.

[toc] | [prev] | [next] | [standalone]

#37459

On Thu, 19 Mar 2015 03:00:02 -0400, Lars Brinkhoff <lars.spam@nocrew.org>
wrote:
> "Rod Pemberton" <bork@lllljunkqwer.cpm> writes:

>> As my other post indicates, it's going to be hard to live with only
>> 16 primitive (or low-level) words maximum.
>
> I disagree.  My toy Forth is based on 12 primitives.  It's quite slow,
> but will boot, metacompile, and run some tests in under a minute.

Well, I'm not familiar with the 9 words you've used, although I did
look at your lbForth when you posted a link some time ago.  You've
done some things far better than most who implement Forth's in other
languages, like C.  In fact, I found a few things to be scary, since
I'm the only other person who seems to have done the same things or
similar things.  I've studied quite a few other Forths coded in C and
no one had used the techniques I've used.  So, yes, I was impressed
with what I saw, but I think you can go much further than you did.

And, I did post links to Mikael Patel's 9 instruction Forth wordset.
He said they produce a very slow Forth.  I also posted a link which
lists the primitives to a bunch of Forths, including another 9 word
set used for bootstrapping MRForth.  So, yes, with three Forths using
9 words, nine is possible, but it's not optimal.  It's also rather
easy to improve or optimize, even if limited to 9 words.

I also posted 15 + 15 from Koopman's and Ertl's data set which should
make an somewhat acceptable Forth in terms of speed, even if only
the first set of 15 are used.

 From the Forth primitives comparison I did, you really need 23 to 63
to be usable.  From my personal Forth, you'll need around 60.

> And the OP stated that speed is of no concern.

I'm being dismissive of that claim.  Nothing is more grating than
slow code.  Even if someone disagrees with that on a rational,
argumentative basis, like I do when I think about this, they usually
find it to be true in reality, like I do in practice.

So, if JUERGEN can simply change from one set of 9 words to a
different set of 9 or 15 words and obtain a 30% or 70% or 120%
increase in speed, I'd think the OP would do so, or at least
test different combinations based on what has been posted.

Koopman and Ertl both already determined which Forth words are
executed the most frequently.  These are the words you want to
spend time on to make them quick.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#37469

If we wanted to delve deeper into the silly territory, we could
combine @ and ! into a single memory-swapping primitive, e.g.

    \ Fetch x2 from a, then store x1 in a.
    XCHG ( x1 a -- x2 )

and then define

    : @   >r 0 r@ xchg dup r> xchg drop ;
    : !   xchg drop ;

Voila, one less primitive.

[toc] | [prev] | [next] | [standalone]

#37586 — ...Tiny targets

Dear c.l.f Forthers around,

after so many theoretical discussions on how a tiny Forth should look like, lets focus on doing something useful !

Lets pick a decent target that is considered too small for a classic, non-tethered, self-contained Forth implementation, and lets try to squeeze the most usefullness out of it.

I would pick the MSP430F2011/MSP430F2012/MSP430F2013, which have no UART, 2 kb of Flash (+1/4 kb if you count the info segments) and 128 Bytes of RAM. That's tiny and a worthy Forth target for small measurement devices. Gary Bergstrom conquered this chip with its nice optimising tethered compiler, so lets see what you can do "inside".

From the outside, I would require that it runs its Forth application until a freestyle serial terminal is attached to the connected, up and running 32768-Hz-crystal, which can be detected as oscillator fault, but this is optional.

Now go on, use your time to type code instead :-) Init, Communications, Query and the Token table is what you perhaps should start with.
Matthias

[toc] | [prev] | [next] | [standalone]

#37595 — Re: ...Tiny targets

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
>2 kb of Flash... and 128 Bytes of RAM. ... Gary Bergstrom conquered
>this chip with its nice optimising tethered compiler

Cool, I had been wondering if something like that existed.  I started
playing around with the idea of writing something like that myself, but
not much past the idea stage.  Do you have a url for Gary Bergstrom's
compiler?

[toc] | [prev] | [next] | [standalone]

#37617 — Re: ...Tiny targets

On Monday, March 23, 2015 at 2:26:33 PM UTC, Matthias Koch wrote:
> Dear c.l.f Forthers around,
> 
> after so many theoretical discussions on how a tiny Forth should look like, lets focus on doing something useful !
> 
> Lets pick a decent target that is considered too small for a classic, non-tethered, self-contained Forth implementation, and lets try to squeeze the most usefullness out of it.
> 
> I would pick the MSP430F2011/MSP430F2012/MSP430F2013, which have no UART, 2 kb of Flash (+1/4 kb if you count the info segments) and 128 Bytes of RAM. That's tiny and a worthy Forth target for small measurement devices. Gary Bergstrom conquered this chip with its nice optimising tethered compiler, so lets see what you can do "inside".
> 
> From the outside, I would require that it runs its Forth application until a freestyle serial terminal is attached to the connected, up and running 32768-Hz-crystal, which can be detected as oscillator fault, but this is optional.
> 
> Now go on, use your time to type code instead :-) Init, Communications, Query and the Token table is what you perhaps should start with.
> Matthias

Matthias, similar to what I was after. Is there a compromise possible? Yes, minimize the resource usage, but rather use the MSP430G2553 - then there is enough headroom for a full version or expansion later. Then the good old Launchpad can be used as you still have to program the chip somehow.
It should be really then be possible to use the smaller chip you suggested as well. 
The measurement would be in both cases Flash and RAM usage.
VFX - 4e4th - eForth and more are running on the MSP430G2553 already, so you could compare performance.

[toc] | [prev] | [next] | [standalone]

#37625 — Re: ...Tiny targets

JUERGEN <epldfpga@aol.com> writes:
>> I would pick the MSP430F2011/MSP430F2012/MSP430F2013
> Matthias, similar to what I was after.... but rather use the
> MSP430G2553 ...  Then the good old Launchpad can be used as you still
> have to program the chip somehow.

Another cpu of interest imho is the ATTiny85 (8k flash, 0.5k ram, 0.5k
eeprom) since it is available on several very small cheap boards such as
this Digispark: http://digistump.com/products/1 This is a cool product
because it's completely assembled and you can just plug it into a
computer with no cable.  It would be awesome to have a Forth environment
that would let you connect one of these things and start using it
immediately.

I'm not that enthused about the original Launchpad these days since its
main attraction is programming through-hole DIP parts, and who really
cares about those any more?  Its made a splash when introduced at
shockingly low cost (4.30 USD) but it's gone up since then.  It's a
considerably larger board than the tiny AVR boards and that limits its
usefulness in portable and wearable applications.  In stationary
applications there's likely to be more power available, so you can use
something like a raspberry pi.

The FRAM launchpads are still interesting because of the unique feature
of FRAM memory.

I guess one other attraction of the low end Launchpad is that the kit
includes a 32 khz xtal (not installed, you have to solder it onto the
board yourself) which is useful if your application wants an RTC.  I
wonder if it's feasible to add that to the small AVR boards.

[toc] | [prev] | [next] | [standalone]

#37632 — Re: ...Tiny targets

On Wednesday, March 25, 2015 at 12:45:53 AM UTC, Paul Rubin wrote:
> JUERGEN <epldfpga@aol.com> writes:
> >> I would pick the MSP430F2011/MSP430F2012/MSP430F2013
> > Matthias, similar to what I was after.... but rather use the
> > MSP430G2553 ...  Then the good old Launchpad can be used as you still
> > have to program the chip somehow.
> 
> Another cpu of interest imho is the ATTiny85 (8k flash, 0.5k ram, 0.5k
> eeprom) since it is available on several very small cheap boards such as
> this Digispark: http://digistump.com/products/1 This is a cool product
> because it's completely assembled and you can just plug it into a
> computer with no cable.  It would be awesome to have a Forth environment
> that would let you connect one of these things and start using it
> immediately.
> 
> I'm not that enthused about the original Launchpad these days since its
> main attraction is programming through-hole DIP parts, and who really
> cares about those any more?  Its made a splash when introduced at
> shockingly low cost (4.30 USD) but it's gone up since then.  It's a
> considerably larger board than the tiny AVR boards and that limits its
> usefulness in portable and wearable applications.  In stationary
> applications there's likely to be more power available, so you can use
> something like a raspberry pi.
> 
> The FRAM launchpads are still interesting because of the unique feature
> of FRAM memory.
> 
> I guess one other attraction of the low end Launchpad is that the kit
> includes a 32 khz xtal (not installed, you have to solder it onto the
> board yourself) which is useful if your application wants an RTC.  I
> wonder if it's feasible to add that to the small AVR boards.

Thanks for the Link. I agree with most of the points about the 430 - except there is probably quite a basis out there now of these launchpads and there are many Forths running on it now. Very small and low cost - but not much IO. But the direct USB interface will make it an additional cheap USB to serial as a first application?

[toc] | [prev] | [next] | [standalone]

#37635 — Re: ...Tiny targets

JUERGEN <epldfpga@aol.com> writes:
> Thanks for the Link. I agree with most of the points about the 430 -
> except there is probably quite a basis out there now of these
> launchpads and there are many Forths running on it now. Very small and
> low cost - but not much IO. But the direct USB interface will make it
> an additional cheap USB to serial as a first application?

Well, Matthias's post is about tethered Forths so resident ones like
4e4th don't count for the purpose.  It's possible Gary Bergstrom's
tethered Forth is 430-specific so that weighs in favor of the 430.  But
the hobby microcontroller movement mostly settled on the AVR, and their
upward path seems to be toward ARM processors.  So the 430, while having
its attractions, never caught on that well.  On the other hand, other
than amForth, I don't think the AVR has gotten much Forth attention yet.

Not sure what you mean about direct USB interface--do you mean the FTDI
chip on the Launchpad board?  The idea I think is to not rely on that.
Do you mean on the Digispark?  There's no USB hardware, it's just
software bit banging, quite a clever feat.  Even smaller than the Tiny85
is the Tiny13 you mentioned in another post.

[toc] | [prev] | [next] | [standalone]

#37636 — Re: ...Tiny targets

On Wednesday, March 25, 2015 at 3:43:59 AM UTC-4, Paul Rubin wrote:
> 
> 
> Well, Matthias's post is about tethered Forths so resident ones like
> 4e4th don't count for the purpose.  It's possible Gary Bergstrom's
> tethered Forth is 430-specific so that weighs in favor of the 430.  But
> the hobby microcontroller movement mostly settled on the AVR, and their
> upward path seems to be toward ARM processors.  So the 430, while having
> its attractions, never caught on that well.  On the other hand, other
> than amForth, I don't think the AVR has gotten much Forth attention yet.

I've not publicly released my compiler.  But it runs on HC08, HC11, HC12, MSP430, and 568XX. Internal use, with comments to the outside world now and then.  I'd like people to look at Rob Chapman's work and build on it.  I did.  But it's too much work to clean up the code for release.  That said, I've used it for 15 years now.

The MSP430 is a nice little part.  The 'G2553 is cheaper than the 'F2013 so that family would be my choice for beginners to play with.  I've embedded a wide variety of the MSP parts into products.

And look at the compilers from MPE and Forth Inc.  They can get you started.
I just bought VFX for the ARM rather than port my system.  I'm getting tired of porting to "new" processors.

Gary

[toc] | [prev] | [next] | [standalone]

#37640 — Re: ...Tiny targets

Gary Bergstrom <forthprgrmr@gmail.com> writes:
> I've not publicly released my compiler.... too much work to clean up
> the code for release. 

Oh well, I didn't realize this.  OK, sounds like this can't be the
starting point.  No prob.

> The MSP430 is a nice little part.  The 'G2553 is cheaper than the
> F2013 so that family would be my choice for beginners to play with.
> I've embedded a wide variety of the MSP parts into products.

Main attraction of the AVR from my perspective is the availability of
tiny little ready-made boards.  There was another thread a while back
about making an MSP board for Forth users, but it fizzled, maybe partly
because the Launchpad already exists.

> And look at the compilers from MPE and Forth Inc.

For professional use, these are terrific.  For personal fooling around
I'd want to stay with FLOSS systems.

[toc] | [prev] | [next] | [standalone]

#37649 — Re: ...Tiny targets

On 3/25/2015 11:06 AM, Paul Rubin wrote:
> Gary Bergstrom <forthprgrmr@gmail.com> writes:
>> I've not publicly released my compiler.... too much work to clean up
>> the code for release.
>
> Oh well, I didn't realize this.  OK, sounds like this can't be the
> starting point.  No prob.
>
>> The MSP430 is a nice little part.  The 'G2553 is cheaper than the
>> F2013 so that family would be my choice for beginners to play with.
>> I've embedded a wide variety of the MSP parts into products.
>
> Main attraction of the AVR from my perspective is the availability of
> tiny little ready-made boards.  There was another thread a while back
> about making an MSP board for Forth users, but it fizzled, maybe partly
> because the Launchpad already exists.
>
>> And look at the compilers from MPE and Forth Inc.
>
> For professional use, these are terrific.  For personal fooling around
> I'd want to stay with FLOSS systems.

What is FLOSS?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web