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

Groups > comp.lang.forth > #41101

Re: Open source CPU+open source toolchain

Show all headers | View raw

On 8/4/2015 11:10 AM, foxaudioresearch@gmail.com wrote:
> On Sunday, August 2, 2015 at 12:06:07 PM UTC-4, rickman wrote:
>> On 8/2/2015 10:55 AM, foxaudioresearch@gmail.com wrote:
>>> On Sunday, August 2, 2015 at 4:46:36 AM UTC-4, mfany...@gmail.com
>>> wrote:
>>>> Ulrich Hoffmann https://github.com/uho already demonstrated
>>>> this like 9 months ago when he used a rudimentary forth that I
>>>> had developed on a simulator and actually made it work in a
>>>> real FPGA environment on a Papilio pro FPGA board. The
>>>> potential to run a small embeddable interactive forth on a FPGA
>>>> is not a new concept but the J1 CPU is an excellent candidate
>>>> for this line of work due to it's minimalistic nature however
>>>> when you ever need things like multitasking then the j1 becomes
>>>> a wee-bit hairy to work with , that's why I stopped development
>>>> on it. You can see the stuff on gitub here
>>>> https://github.com/samawati/j1eforth, great contribution by
>>>> Ulrich Hoffmann by the way and also to James bowman for his j1
>>>> CPU in verilog which is awesome x2 ..
>>>
>>> I read some things about multi-tasking and the J1. It is a thorny
>>> problem however is not the correct solution to add some support
>>> at the CPU level?
>>>
>>> Something like bigger stacks that could be segmented by task
>>> comes to mind. I think the stack rollover is a possible threat
>>> but hey Forth people know how to keep the stack under control (at
>>> least in finished code) :)
>>>
>>> Koopman indicates that you can run real Forth programs with 16
>>> cells per stack.
>>>
>>> Would that solve the multi-tasking problem for a specific maximum
>>> number of tasks?  (ie we would not be running UNIX on the thing,
>>> just some embedded programs)
>>
>> A very straight forward approach to multi-tasking is
>> multi-processors. Every significant problem I have seen in embedded
>> processing is due to a single processor being used to
>> simultaneously run multiple tasks.  If you really require that then
>> select a processor suitable to the job. With the low cost of
>> transistors these days and the small size of stack processors,
>> there is no little for difficult multi-tasking in an FPGA.
>>
>> --
>>
>> Rick
>
> That's a good point and a reasonable solution to the problem. It
> might not fly in specific commercial situations when improving and
> existing product with a big customer base or when the project specs
> are demanding that you keep the costs per unit to a magic low value.
> But I take your point.
>
> It would still be interesting to me to expand the stack space in the
> J1 and use upper bits on the stack pointers as Base pointers to
> create a set of small stacks in the expanded stack space. For a
> finite number of tasks in an embedded project this is just more code,
> no new hardware.  No Verilog experience here, so there is time
> consumer for an old guy!

Yes, that has been done before.  Someone in the c.a.fpga group (iirc) 
build a single processor with an 8 stage pipeline used so each stage of 
the pipe was a separate processor.  The additional logic was minimal and 
use of block RAM for memory made the stacks very efficient with the 
pipeline stage number identifying the processor and selecting the stack 
segment.  The pipelining allowed higher clock speeds which meant each 
processor ran roughly as fast as a single processor without the pipelining.

He was very excited about his design until someone got on his case about 
some feature that was missing which was important for writing "serious" 
code.  I don't recall what that was.

What I took away from the discussion is that we all have different 
expectations of these processors.  I want something simple with high 
visibility that I can understand the nuts and bolts of.  I also want it 
efficient across multiple architectures or easily optimized for them.  I 
don't need any features that allow writing an OS.  For others, they 
don't care much about the underlying CPU, only that it lets them do the 
software things they feel they need which often means lots of memory and 
OS support.

BTW, I see my post earlier ended a bit oddly.  I must have been editing 
it and hit the send before finishing.  I think it was supposed to end, 
"there is no NEED for difficult multi-tasking in an FPGA."

-- 

Rick

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

Thread

Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-29 17:57 -0700
  Re: Open source CPU+open source toolchain mentificium@gmail.com - 2015-07-29 18:36 -0700
    Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-29 19:15 -0700
  Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-07-30 01:40 -0400
    Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-07-30 07:11 -0700
    Re: Open source CPU+open source toolchain Jecel <jecel@merlintec.com> - 2015-07-30 09:39 -0700
    Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:22 -0400
      Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-07-30 20:56 -0500
        Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:05 -0400
          Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-07-31 09:47 -0500
            Re: Open source CPU+open source toolchain "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-31 23:57 -0400
              Re: Open source CPU+open source toolchain anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-01 13:07 +0000
              Re: Open source CPU+open source toolchain "Elizabeth D. Rather" <erather@forth.com> - 2015-08-01 10:37 -0500
  Re: Open source CPU+open source toolchain mfanyikazi@gmail.com - 2015-08-02 01:46 -0700
    Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-02 07:55 -0700
      Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-02 12:06 -0400
        Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-04 08:10 -0700
          Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-04 12:05 -0400
            Re: Open source CPU+open source toolchain foxaudioresearch@gmail.com - 2015-08-04 14:21 -0700
              Re: Open source CPU+open source toolchain rickman <gnuarm@gmail.com> - 2015-08-04 18:24 -0400
      Re: Open source CPU+open source toolchain Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-06 09:12 +0100

csiph-web