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

Groups > comp.lang.forth > #41110

Re: Open source CPU+open source toolchain

Show all headers | View raw

On 8/4/2015 5:21 PM, foxaudioresearch@gmail.com wrote:
> On Tuesday, August 4, 2015 at 12:05:07 PM UTC-4, rickman wrote:
>> 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
>
> Thank you for the clarification Rick.  I suppose from my perspective
> Forth style round-robin, fast context switching multi-tasking is not
> "difficult" so I am biased. If you have not played with one I
> recommend it.  It's one of those strange cases where practice seems
> to work better than theory would indicate.
>
> I built one for a 68HC11 board many years ago and it allowed me to do
> many cool things on that little chip and was not difficult at all.
>
> And I "completed" (made functional) the multi-tasker (that I paid
> for) for Hs/Forth for DOS and made some applications that some people
> said you could not do with DOS. (multi-terminal/multi-user
> application for example)

Sure, but the tasker is not the hard part of multitasking.  If you have 
a simple set of tasks to do multitasking can be as simple as running 
each task in turn with no worries.  But if the multitasking is more 
complex the whole environment has to be considered.

In fact, I think it was the intertask communications that was the hard 
part even with multiple processors.  I seem to recall it requires an 
instruction to allow manipulation of a semaphore.


> I am thinking, without experience mind you, that a cool little chip
> like J1 could benefit from the same functionality I liked with those
> old systems.
>
> That being said if 5 or 6 little CPUs all fit on the FPGA that the
> project used, then I would seriously have to consider doing it your
> way. But to be honest without that experience in multi-processing I
> probably feel like it is more difficult than a the multi-tasker. Just
> my perception, not reality.

The pipelined multiprocessor design with 8 logical processors was as 
much an easy way to use the hardware as it was a way to provide more 
MIPS.  To use pipelining to make a single processor run faster creates 
pipeline stalls when the execution takes a turn.  The 8 logical 
processors are not pipelined yielding 8 processors with N MIPS each vs. 
1 processor with 8*M minus some factor for the branch stalls.  None of 
this takes much more logic than a single processor, which if a stack 
processor can be very small compared to the fancy RISC type designs.

If you truly need multitasking, giving each task it's own processor can 
work very well.  But it all depends on the tasks.  If 90% of your 
processing is in one task, then this won't help much.

-- 

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