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

Groups > comp.lang.vhdl > #4400

Re: Forth in VHDL

Cross-posted to 2 groups.

Show all headers | View raw

On 7/24/2016 11:25 PM, Cecil Bayona wrote:
> On 7/24/2016 10:05 PM, rickman wrote:
>> On 7/24/2016 11:01 PM, rickman wrote:
>>> On 7/24/2016 10:29 PM, rickman wrote:
>>>> I wonder how hard it would be to write a Forth in VHDL?  It would
>>>> likely
>>>> be as easy to do in non-synthesizable code as any other language.  It
>>>> might be a bit harder in synthesizable code.  For one, the I/O would
>>>> need to be constructed from scratch based on some hardware interface.
>>>> The non-synthesizable code could just read from a file... I wonder if
>>>> you can read from the console in VHDL?  I've never tried that before.
>>>
>>> I did a little digging and it looks like you *can* do console I/O in
>>> VHDL using the textio package.  So I can't think of anything to stop a
>>> vforth from being written... unless the vforth name has already been
>>> used.
>>
>> Looks like the name vforth has been used before... twice!  Once for a
>> VIC forth and once, more recently for a VAX forth?  Really?  Do people
>> still have VAX computers?  Or is this run on a VAX emulator?  Maybe
>> that's a retro thing?
>>
>> So it looks like nothing stands in the way of writing a Forth in VHDL
>> other than free time... which I seem to have a lot of.  ;)
>>
> But what would you gain? It would be horribly slow and no benefit that I
> can see. Better to use VHDL to create a CPU that runs Forth natively,
> that is why I been working on some of the Forth CPUs that run in FPGAs.
>
> Aside from the above mentioned it would be interesting to create
> hardware that runs Forth natively, not a CPU but a set of hardware that
> runs the code natively.
>
> Are you still recovering?

Recovery is going pretty well, thanks for asking.  I have regained most 
of the muscle strength lost from limping very abnormally for some years. 
  I still have swelling in the operated leg but no one is very concerned 
and it seems to be better the last week or so.  They did an ultrasound 
to rule out DVT so it should just be some more time.

The funny part is that my work no longer requires much of me other than 
pushing paper and staying on top of things.  I accept orders for 
hardware I sell and place the orders with my fabrication house.  When 
they complete testing and ship the boards I send the invoice to the 
customer and pay the fab house.  Lots of profit with very little work. 
In fact, technically I was working during my surgery (waiting for boards 
to be fabbed).  That's the main reason why I have free time.

I was thinking in terms of a Forth interpreter for use as a test bench. 
Currently I write test benches one of three ways.  Either I write ad hoc 
code that generates arbitrary signals based on the requirements of the 
object being tested - or I use another copy of the hardware being tested 
as the tester when it uses a symmetrical interface - or for interfaces 
with well parameterized functionality, I write a text interpreter which 
reads commands from a file to control the testing.

Using a Forth interpreter would allow me to handle any of the above in 
Forth directly reading and writing I/Os to the device under test - or 
connecting inputs and outputs of various modules - or reading commands 
from a file to manipulate interfaces.

You are thinking of speed in terms of something real time.  VHDL 
simulation are nowhere near real time.  But it would be nice to program 
a test bench in something other than VHDL.

As to a "directly executing" Forth CPU, what would that be exactly? 
Hardware is hardware.  To design it requires forming an idea of the 
hardware.  The only hardware I have thought of to execute Forth would be 
the same sort of stack machines I've seen many times and designed 
myself.  Not much new there.  What would a "native" Forth machine look 
like other than a dual stack CPU which is what the Forth virtual machine 
is?

-- 

Rick C

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

Thread

Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 22:29 -0400
  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:01 -0400
    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:05 -0400
      Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 22:25 -0500
        Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 00:08 -0400
          Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 23:57 -0500
            Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:22 -0400
              Re: Forth in VHDL Paul Rubin <no.email@nospam.invalid> - 2016-07-24 22:38 -0700
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:53 -0400
              Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 14:11 -0500
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 17:39 -0400
                Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 18:01 -0500
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 19:40 -0400
                Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-26 11:04 +0100
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 11:13 -0400
                Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:00 +0000
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 12:58 -0400
                Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 09:39 +0000
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 10:01 -0400
                Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-27 22:46 +0100
    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 18:15 -0400

csiph-web