Re: support, T-shirts, etc. (composite reply)
- To: "Myron Plichota" <mplichot@xxxxxxxxx>
- Subject: Re: support, T-shirts, etc. (composite reply)
- From: Rick Collins <rickmanlist@xxxxxxx>
- Date: Thu, 18 Mar 1999 13:21:18 -0500
- Cc: <MISC>
- In-Reply-To: <000201be715c$92561ec0$4fe6c9d0@mplichot.sonic>
Your instruction set is very interesting. I spent a lot of time thinking
about how to implement a hardware forth machine about 10 years ago when
there were not such things as FPGAs. At that time I considered building a
machine from bit slice parts (max speed 10 MHz, board size) and obtaining a
microprogrammable version of the DEC LSI-11 (speed ?, box size). Now I am
an FPGA designer and it would be duck soup to design a machine to implement
the instruction set you have described in a small FPGA.
For what application are you intending on building this processor? What
technology do you plan to use? Were you going to design an ASIC or an FPGA
or just build an HDL model and let others implement the chip?
One suggestion I would make concerning the instruction set. I believe most
programmers would like a relative address mode. I guess that this is not as
important in forth with threaded code. But since you have to write the
primatives with inline code, much of your code would have local references
and could take advantage of position independant code.
Perhaps it would be worthwhile to add a second nibble to the JZ and Call
instructions to describe the address operand. The msb would define absolute
vs. relative address and the remaining three bits would enumerate the
number of nibbles needed to define the address or +/- offset (with sign
extension). This would allow for the vast majority of jumps and calls to
occupy less memory and eliminate the need for padding to word align (in
most cases). It would require an 8 way multiplexor to be added to align the
address.
If you are going for absolute minmum size, then I can see where you would
leave this feature out. But you might want to allow some means to have an
expandable primative instruction set. Although the nano instruction set
could be made to run quite fast, there are limits to register transfer
rates and adding parallel hardware will often speed a processor if needed.
Regarless of my (useful or not) suggestions, I would be happy to contribute
some time to designing an implementation or simulation of the the nanoforth
instruction set in VHDL or on a Xilinx part. I have tools necessary to do
this and time although somewhat limited. I have enough paying work so that
I don't need to worry about where my next meal is coming from. ;-)
I would suggest that the first step in this process would be to layout the
registers needed and the data paths interconnecting them. A good RTL
description with a block diagram would be appropriate.
At 11:27 AM 3/18/99 , you wrote:
>
>-----Original Message-----
>From: M. Simon <msimon@tefbbs.com>
>To: MISC@pisa.rockefeller.edu <MISC@pisa.rockefeller.edu>
>Date: Thursday, March 18, 1999 6:04 AM
>Subject: Re: support, T-shirts, etc. (composite reply)
>
>
>>What is nanoFORTH?
>>
>>Simon
>
>
>nanoFORTH is a core set of 15 stack instructions. The 16th instruction needs
>to be nop for instruction alignment in a packed instruction implementation.
>I am planning a 32-bit design which fetches an octet of 4-bit instructions.
>The attachment summarizes a few of the details.
>
>Myron Plichota
>
>
rickman
"A man who carries a cat by the tail learns something he can learn in no
other way." -- Mark Twain