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

Groups > comp.lang.forth > #21830

Re: Forth Implemented on a MISC Processor

Show all headers | View raw

On 4/22/2013 5:08 PM, Brad Eckert wrote:
> On Monday, April 22, 2013 1:05:57 PM UTC-7, rickman wrote:
>>
>> Different applications have different requirements.  That is why I
>> designed my own.  At the time there were none out there that would fit
>> my FPGA and do what I wanted it to do.  I bet the RTX2000 soft core is a
>> lot larger than 500 LUTs.
>>
> Well, MPE is a software company that already had good Forth and C compilers for the RTX. In theory, RTX fans orphaned by Harris may want to use it to support legacy code or for other reasons.
>
> You, on the other hand, are starting with no pre-existing software tools and no customer base. That's some nice freedom. What I would do is leave gaps in the instruction set so you can add application-specific instructions as needs arise, and keep it simple.

If only it *were* that simple.  The 9 bit version of the stack oriented 
design has lots of spare opcodes.  The register and hybrid designs I'm 
looking at use a lot more opcode space so 9 bits get used up very fast. 
  I haven't fleshed out the hybrid opcodes yet, I may be trying to 
design a 12 bit opcode in 9 bits!


> Your stacks are in LUT RAM, which is easy because those are async read. If implemented an RTX, you would use block RAM for the stacks and they are sync read which means you have to pipeline things in order to read data a cycle before the instruction that needs it executes. Either that or fake async read by using clocking tricks.

LUT RAM has that advantage, but with stacks, the sync nature doesn't get 
in the way since the read of the stack is done at the end of the 
instruction (just like the write) and the TOS pointer is defined, so the 
stack RAM output is always defined at the start of the next instruction. 
  It is the data RAM that is awkward.  A write is fine happening at the 
end of the instruction, but a ready has to happen in the middle.  I've 
considered a couple of approaches.  One is to use the dual port and 
clock the reads on the opposite edge so they happen in the middle of the 
cycle.  The other is to use the address at the *input* to the address 
register (TopOfReturnStack) as the address to the block RAM and always 
do the read.  If you don't need it, so what?  A little energy 
inefficient, but who's counting Joules here?


> I've wondered if you could just lump data and stacks together in one block RAM and encode the ISA such that these pre-reads are trivial to decode.

That is what I am looking at for the register and hybrid approaches. 
This does get into timing issues.  For an indirect access you need to 
read the address from a register, read memory and then write a 
register... three clock edges!  Even playing the opposite edge game this 
is two clock cycles.

I had been using a single block RAM for the two stacks in the stack 
design, one port each.  I hadn't thought about combining this with the 
main memory, but that is a thought.


> BTW, if you want a cross compiler, I started one a while back but can give it to you to play with. It's much cleaner than the other cross compilers that I've written in the last 20 years.

Sold!  What does it run under?  My experience is with Win32Forth. 
rickman dot 2013 at arius dot com.  Shoot me an email or something.

-- 

Rick

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-18 18:24 -0400
  Re: Forth Implemented on a MISC Processor Brad Eckert <hwfwguy@gmail.com> - 2013-04-19 12:28 -0700
    Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-19 15:55 -0400
      Re: Forth Implemented on a MISC Processor Brad Eckert <hwfwguy@gmail.com> - 2013-04-22 09:18 -0700
        Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-22 16:05 -0400
          Re: Forth Implemented on a MISC Processor Brad Eckert <hwfwguy@gmail.com> - 2013-04-22 14:08 -0700
            Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-22 17:52 -0400
  Re: Forth Implemented on a MISC Processor Jecel <jecel@merlintec.com> - 2013-04-19 15:24 -0700
    Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-20 01:02 -0400
  Re: Forth Implemented on a MISC Processor Paul Rubin <no.email@nospam.invalid> - 2013-04-19 21:37 -0700
    Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-20 16:20 -0400
      Re: Forth Implemented on a MISC Processor Paul Rubin <no.email@nospam.invalid> - 2013-04-20 14:21 -0700
        Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-20 18:03 -0400
          Re: Forth Implemented on a MISC Processor Paul Rubin <no.email@nospam.invalid> - 2013-04-21 17:07 -0700
            Re: Forth Implemented on a MISC Processor Brad Eckert <hwfwguy@gmail.com> - 2013-04-22 12:05 -0700
            Re: Forth Implemented on a MISC Processor rickman <gnuarm@gmail.com> - 2013-04-22 16:19 -0400

csiph-web