Forth-CPU design

hi
sorry, this is corrected

/.s=q /.q.r ; get 1st pointer to q
/.q.r /.q.r ; copied 3 16 bit words to r
/=q.r /.s=q ; save address for write over and get other address
/.q.s /.q.s ; get other 3 16 bit words to s
/.q.s /=q.s ; and save q on s
/.r=q /.s.r ; restore 1st address
/.s.q /.s.q ; overwrite 3 16 bit words
/.s.q /.r=q ; restore 2nd pointer in q (correction)
/.r.q /.r.q ; overwrite 2nd set
/.r.q /=p.p ; and a nop (possible faster pipeline)

cheers

In comp.lang.forth jacko <jackokring@gmail.com> wrote:

> just wondering if grey code (1 bit change) addressed stack memory
> might be useful for cutting down carry chain logic for pre-post
> dec/inc addressing??

If it's just adders you want to avoud, I've seen linear feedback shift
regsiters used for this: very small and cheap.

Andrew.

jacko wrote:
> hi
>
> just wondering if grey code (1 bit change) addressed stack memory might
> be useful for cutting down carry chain logic for pre-post dec/inc
> addressing??

Why bother?  On FPGAs carry chain logic is free, fast and the easy
path.  I guess you are thinking custom chip, eh?  Even then is it a
real issue for the stack counter to be binary?  How large will this be,
4 bits, 6 bits, 8 bits?

  CALL .
 This because CALL is too slow .
  New Forths jump indirect at worst and
 at best ( Chucks NS4000 ) dont pay any price at all , they JUMP
 direct to next executable !!!

  There is no way to salvage the function "CALL" It is a bad idea .
 Why return when thats not what you want to do ?

 BTW NewForth has to simulate a fast "executable to excuatble"
 cause ARM is slow in all branches  .
 NF does next best thing , Indirect jump  directly to next executable .

 There is no faster way .
_____________________________________________________________


Jecel wrote:

> If you are going to compile Forth then CALL is probably the first
> instruction you want to optimize and I didn't even see it or an
> equivalent in your list.........................

. And in general it
> isn't very good to allow the stack to get very deep with temporary
> values when programming stack machines.
   [[[[[[[[  STACKS are trouble , use modern programming pls ]]]]]]

> -- Jecel

werty wrote:
> CALL .
>  This because CALL is too slow .
>   New Forths jump indirect at worst and
>  at best ( Chucks NS4000 ) dont pay any price at all , they JUMP
>  direct to next executable !!!

If by NS4000 you mean the Novix NC4016 then it is exactly an example of
what I was talking about - subroutine call is the most optimized
instruction with its opcode taking up a single bit.

http://www.ece.cmu.edu/~koopman/stack_computers/sec4_4.html

There are several kinds of Forth implementations, but at least Chuck
Moore's recent efforts seem to favor the subroutine threaded model.
Even for models where you don't need an actual call instruction the
equivalent functionality is included in the kernel (you need to save
stuff to the return stack at some point). With subroutine threading it
is indeed a great idea to replace tail calls with jumps.

>   There is no way to salvage the function "CALL" It is a bad idea .
>  Why return when thats not what you want to do ?

Sometimes it isn't what you want to do, but sometimes it is.

>  BTW NewForth has to simulate a fast "executable to excuatble"
>  cause ARM is slow in all branches  .
>  NF does next best thing , Indirect jump  directly to next executable .
>
>  There is no faster way .

What is fast or not depends on the processor architecture and even more
on the implementation of the memory hierarchy.

-- Jecel

jacko wrote:
> hi
> 
> just wondering if grey code (1 bit change) addressed stack memory might
> be useful for cutting down carry chain logic for pre-post dec/inc
> addressing??

Gray codes are useful for reading data, but they need extra hardware for 
counting and addressing. (If course, Gray-code addressing is no 
different from any other scrambling of the address lines too a memory 
chip. Page accesses aside, the memory doesn't care. It can make a ROM 
difficult to reverse engineer, particularly id the data lines are 
scrambled too.)

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

rickman wrote:
> jacko wrote:

> > just wondering if grey code (1 bit change) addressed stack memory might
> > be useful for cutting down carry chain logic for pre-post dec/inc
> > addressing??
>
> Why bother?  On FPGAs carry chain logic is free, fast and the easy
> path.  I guess you are thinking custom chip, eh?

I wasn't sure I understood the question. Is it to reduce the worst-case
speed for the increment? A traditional carry-type grey code implement
has a worst case just as bad as binary, but it sounds like he's
thinking about dedicating the space for a faster method.

But likely I misunderstood. Why would he need the increment to be fast
when something else would surely be slower anyway? And I'd expect a
binary increment to take less space.

J Thomas wrote:
> rickman wrote:
> > jacko wrote:
>
> > > just wondering if grey code (1 bit change) addressed stack memory might
> > > be useful for cutting down carry chain logic for pre-post dec/inc
> > > addressing??
> >
> > Why bother?  On FPGAs carry chain logic is free, fast and the easy
> > path.  I guess you are thinking custom chip, eh?
>
> I wasn't sure I understood the question. Is it to reduce the worst-case
> speed for the increment? A traditional carry-type grey code implement
> has a worst case just as bad as binary, but it sounds like he's
> thinking about dedicating the space for a faster method.
>
> But likely I misunderstood. Why would he need the increment to be fast
> when something else would surely be slower anyway? And I'd expect a
> binary increment to take less space.

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.

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.

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?