Forth-CPU design

rickman wrote:
> J Thomas wrote:
> > rickman wrote:
> >
> > > Yes, there are few advantages to a Gray code counter.  But one is a
> > > lower power consumption because only one bit changes on each increment.
> > >  Again this is unlikely to be noticed in a real chip given the small
> > > size of the counter.
> >
> > If you're getting your code from offchip, and you need a new address
> > every time you get a new instruction, then the power consumption
> > advantage might add up, right?
> >
> > To my way of thinking this is a braindead way to get code to a
> > processor, but it seems to be standard.
>
> Maybe I misunderstood.  I thought we were discussing addressing a
> hardware stack memory.  A stack can often be just 6 bits or less.  At
> that size the power difference would be virtually unmeasureable.  Off
> chip sequential accesses could be a different story, but then you only
> need a one bit address bus to indicate, up or down and put the counter
> elsewhere.  As long as you are doing custom chips, why not optimize the
> whole thing?

Agreed. I'm saying what you're saying.

J Thomas wrote:
> rickman wrote:
> 
> 
>>Yes, there are few advantages to a Gray code counter.  But one is a
>>lower power consumption because only one bit changes on each increment.
>> Again this is unlikely to be noticed in a real chip given the small
>>size of the counter.
> 
> 
> If you're getting your code from offchip, and you need a new address
> every time you get a new instruction, then the power consumption
> advantage might add up, right?
> 
> To my way of thinking this is a braindead way to get code to a
> processor, but it seems to be standard.

  Generating a new address each time is certainly widespread, but there
are small pockets where this is done better.
  Some game machines have a smarter ALE + Counter scheme, and some
flash devices have Multi Cycle ALE +Clock schemes ( and
Serial flash memories all generates an address, and then streams the data )
  There are sync memories that have limited page-burst sizes, but they
are complex to use efficently.
-jg

rickman schrieb:

> Yes, there are few advantages to a Gray code counter.  But one is a
> lower power consumption because only one bit changes on each increment.

Whereas a binary counter changes two bits on average.
(1 + 1/2 + 1/4 + ....)
This saves you what, 5fW? And that is probably more than offset by more
switching internal signals in an FPGA implementation.

Kolja Sulimma

rickman schrieb:
> J Thomas wrote:
>  At
> that size the power difference would be virtually unmeasureable.  

Ripple carry counter power is independant of counter size.
(Except for clock tree power)

Kolja

Kolja Sulimma wrote:
> rickman schrieb:
> > J Thomas wrote:
> >  At
> > that size the power difference would be virtually unmeasureable.
>
> Ripple carry counter power is independant of counter size.
> (Except for clock tree power)

Good example of a rule of thumb gone bad.

If you think about that you will realize that it can't be true...
otherwise the extra bits must use no power!

Each added bit toggles half as fast as the last.  So the power for a
ripple carry counter is a power series which is asymptotic to two bits
toggling all the time.  That is not the same as independant.  However
your point is valid that once you get past a few bits the added power
for more bits is very small.  The power for a Gray code counter is
pegged at 1 bit toggling.  So the difference is always small.

rickman schrieb:

> Each added bit toggles half as fast as the last.  So the POWER for a
> ripple carry counter is a POWER series 
Hihi, nice wording...

> which is asymptotic to two bits
> toggling all the time.  That is not the same as independant. 
But it is close. Considering the error that power estimation has on sub
100nm CMOS the assumption of constant power is probably within the error
bar starting from the second bit.

Kolja Sulimma

Jecel wrote:
> rickman wrote:
> > [sample code with 8 bit instructions]
> > Any interest in comparing this to one of the proprietary cores such as
> > microBlaze or NIOS2?  I have wanted to see how efficient they would be
> > implementing a Forth, but I have yet to work with one of them yet.
>
> This is an interesting instruction set and seems to make good use of
> the two stacks.
>
> My impression is that neither Microblaze nor NIOS II would do a
> particularly good job of executing Forth since their memory
> instructions seem to be of the simple register+short immediate offset
> type. Contrast that with the ARM (or any CISC) which can use
> pre-decrement and post-increment (or pre-increment and post-decrement)
> to move things to and from the stack.

One of the nice things about an FPGA processor core is that they are
typically expandable.  It should be a simple matter to add hardware
mapped stacks to any of these cores.  It could be memory mapped, or
even mapped to registers.  I think there are three operations on the
stack, read, write, push and pop.  So unless there are some addressing
modes that could be usurped, it might require mapping each stack to two
registers, one for read/write and one for pop/push.

But then I am not sure the best way to implement forth is to simulate
the hardware of a stack machine.  Modern Forth compilers seem to do a
durn good job of mapping the forth functionality to RISC/CISC
processors.  I guess the question is whether I can make a MISC
processor that works as well as a RISC/CISC processor and uses fewer
hardware resources.


> The native code for this particular task, however, would be reasonably
> small and fast for nearly any RISC including the two proprietary cores.
> Just two loads, two stores, an increment, a comparison and a branch
> (the last two are often a single instruction).

Thanks for pointing that out.  The original FPGA that I designed my
Forth core for did not have a vendor supplied RISC core.  But all of
the newer ones do.  To compare to my MISC code the RISC would need to
load the two addresses and a count which would be three more
instructions and I'm not sure how many bytes, at least 6 more for a
total of about 20 bytes.  So my MISC 19 bytes/13 loop clock cycles is
at least as good if not better than the RISC 20 or more bytes if slower
in clock cycles.

 You miss the point .

  You never want to RETURN to a "controlling"/"Calling"
  Word  in NewForth , you can not justify it EVER .
 You NEVER need to RETURN EVER , you can always run
faster and yet the upper level word is still in control
 without ever RETURNING !!!!

  Got it ?   NEVER RETURN ..


 Example :  A hi level word starts the show and has a list
 of 13 Mid-Levels   it will "run' , at the end of the first  , instead
of returning to the main word , I.P. looks at the list of 13
in main word and JUMPS indirect thru that list , to the next
 subroutine .... But w/o cost !! The mechanism is fast ,
it does NOT return to main word .

 That is NOT returning , it is transparently jumping to
next subroutine W/O wasting time Returning ,

  It gets worse as you study the
ARM 4 cores ...The BRA is actually slower for the pipeline
is slow sending the address to the P.C.  !  it takes 3 clocks !

  The problem is people get stuck on a Return stack ,
they just can't see any other way of doin it clean ....
  sorry about that !

 Imagine a CPU that has an external list of addresses
 that is its "program"  .   alias     I.D.C./ IndirectThreadedCode
 Everything in outer RAM is an address .
  No executable code in outer RAM .
  But inside CPU is More RAM that holds  Primatives .
   Those Primatives look like an extension of the  instruction set .
 Boot CPU and it looks for first address from FFFF  .
  After a few Primatives are run from that sequence from outer RAM
 there's a conditional and the Primatives , change the list from
which they are executing .
   This sequence can of course create new lists in outer RAM
as it runs  , and create data .

 Do you see any STACKs ?   any RETURNs ?
 All CPUs today can do this and its faster than their
 own CALL/RETURN .

 Return  STACKS  are slow , hard to address ,  uneeded ....

 NewForth for ARM 920T will be Free OpSys ....

werty wrote:
>  NewForth for ARM 920T will be Free OpSys ....

You've said you're making a forth on an arm core, or
something like that. How does that work? Wouldn't a
forth cpu execute forth instructions natively? Where would
the ARM fit in?

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

werty wrote:
>  You miss the point .
> 
>   You never want to RETURN to a "controlling"/"Calling"
>   Word  in NewForth , you can not justify it EVER .
>  You NEVER need to RETURN EVER , you can always run
> faster and yet the upper level word is still in control
>  without ever RETURNING !!!!
> 
>   Got it ?   NEVER RETURN ..
> 
> 
>  Example :  A hi level word starts the show and has a list
>  of 13 Mid-Levels   it will "run' , at the end of the first  , instead
> of returning to the main word , I.P. looks at the list of 13
> in main word and JUMPS indirect thru that list , to the next
>  subroutine .... But w/o cost !! The mechanism is fast ,
> it does NOT return to main word .
> 
>  That is NOT returning , it is transparently jumping to
> next subroutine W/O wasting time Returning ,
> 
>   It gets worse as you study the
> ARM 4 cores ...The BRA is actually slower for the pipeline
> is slow sending the address to the P.C.  !  it takes 3 clocks !
> 
>   The problem is people get stuck on a Return stack ,
> they just can't see any other way of doin it clean ....
>   sorry about that !
> 
>  Imagine a CPU that has an external list of addresses
>  that is its "program"  .   alias     I.D.C./ IndirectThreadedCode
>  Everything in outer RAM is an address .
>   No executable code in outer RAM .
>   But inside CPU is More RAM that holds  Primatives .
>    Those Primatives look like an extension of the  instruction set .
>  Boot CPU and it looks for first address from FFFF  .
>   After a few Primatives are run from that sequence from outer RAM
>  there's a conditional and the Primatives , change the list from
> which they are executing .
>    This sequence can of course create new lists in outer RAM
> as it runs  , and create data .
> 
>  Do you see any STACKs ?   any RETURNs ?
>  All CPUs today can do this and its faster than their
>  own CALL/RETURN .
> 
>  Return  STACKS  are slow , hard to address ,  uneeded ....
> 
>  NewForth for ARM 920T will be Free OpSys ....
> 

As far as I can see, that all makes sense for a program structured like 
this:

(main routine) :
	do thing1
	do thing2
	do thing3

Avoiding the call and return makes sense - the end of "thing1" can just 
be a jump to the start of "thing2", or even better, "thing2" can simply 
follow on after "thing1".

But if the program is:
(main routine) :
	do thing1
	do thing2
	do thing1
	do thing3

Or if both "thing1" and "thing2" want to call a common routine "thing4", 
you are stuck.  Either you duplicate code (which might be worth doing if 
the code is short, but not if it is long), or you have some sort of 
stack - there is no other way (any other solutions are a stack in disguise).


An ideal compiler arrangement would figure this sort of thing out 
automatically and cut out all the calls and returns when they are not 
necessary, but include them when they are.  I don't know much about 
forth implementations (it's over fifteen years since I looked at forth), 
but I do know of C compilers that do this.