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

Groups > comp.lang.forth > #49421 > unrolled thread

Forth in VHDL

Back to article view | Back to comp.lang.forth

Contents

  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 JUERGEN <epldfpga@aol.com> - 2016-07-25 05:31 -0700
                      Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 05:36 -0700
                        Re: Forth in VHDL Richard Owlett <rowlett@cloud85.net> - 2016-07-25 08:14 -0500
                          Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 07:37 -0700
                          Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 08:01 -0700
                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 JUERGEN <epldfpga@aol.com> - 2016-07-26 09:43 -0700
                      Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-28 09:12 +0100
                        Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 05:04 -0400
                        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-28 07:56 -0700
                          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 13:04 -0400
                          Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-08-02 12:21 +0100
                        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-28 08:02 -0700
      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 18:15 -0400
        Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-28 15:19 -0700
          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-31 18:43 -0400
            Re: Forth in VHDL Paul Rubin <no.email@nospam.invalid> - 2016-07-31 17:10 -0700
    Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 20:08 -0700
      Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 20:33 -0700
        Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 22:58 -0500
          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 00:17 -0400
            Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 10:02 -0700
              Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 14:13 -0400
                Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 14:17 -0400
                Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 15:04 -0700
                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 19:28 -0400
                    Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-25 17:20 -0700
                      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 23:07 -0400
                    Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-26 03:07 -0500
                      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 13:05 -0400
                        Re: Forth in VHDL Brad Eckert <hwfwguy@gmail.com> - 2016-07-26 16:22 -0700
                        Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 03:57 -0500
                          Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 10:34 -0400
                            Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 11:15 -0500
                              Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 12:51 -0400
                                Re: Forth in VHDL Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:12 -0500
                                  Re: Forth in VHDL "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 12:43 -1000
                                    Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 00:40 -0400
                                    Re: Forth in VHDL hughaguilar96@gmail.com - 2016-08-02 22:45 -0700
                                  Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-28 00:39 -0400
    Re: Forth in VHDL wzab01@gmail.com - 2016-07-25 01:48 -0700
    Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 05:57 -0700
      Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-07-25 06:02 -0700
      Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-30 16:40 +0100
        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-08-01 08:58 -0700
      Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-31 17:10 -0400
        Re: Forth in VHDL JUERGEN <epldfpga@aol.com> - 2016-08-01 09:02 -0700
    Re: Forth in VHDL Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-07-29 05:42 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#49490

On Sunday, July 24, 2016 at 9:18:02 PM UTC-7, rickman wrote:
> One clock cycle interrupt response time *always*.  Not sure why Brad 
> says interrupts aren't needed.  I guess he figures you can do anything 
> you want with polling or maybe he would use a wait instruction like the 
> Transputer and the F18A.

That is kind of a broad statement. The last time I designed a CPU, interrupts were a pain to debug because you have to make sure they work anytime.

One time I implemented interrupts by having the hardware doctor the return instruction. If an interrupt was pending, RET would jump to the ISR instead of popping the jump address off the return stack. That worked pretty well (since Forth is so finely factored) and was easy to test.

[toc] | [prev] | [next] | [standalone]

#49494

On 7/25/2016 1:02 PM, Brad Eckert wrote:
> On Sunday, July 24, 2016 at 9:18:02 PM UTC-7, rickman wrote:
>> One clock cycle interrupt response time *always*.  Not sure why Brad
>> says interrupts aren't needed.  I guess he figures you can do anything
>> you want with polling or maybe he would use a wait instruction like the
>> Transputer and the F18A.
>
> That is kind of a broad statement. The last time I designed a CPU, interrupts were a pain to debug because you have to make sure they work anytime.
>
> One time I implemented interrupts by having the hardware doctor the return instruction. If an interrupt was pending, RET would jump to the ISR instead of popping the jump address off the return stack. That worked pretty well (since Forth is so finely factored) and was easy to test.

What exactly would make an interrupt hard to verify?  The CPUs I design 
are rather simple with one clock cycle per instruction.  The interrupt 
acknowledge is just another instruction that is executed in place of the 
instruction which was being fetched.  Not at all hard to verify.

I don't think it is needed to test every possible IRQ with each 
instruction last or next executed.  No more than it is needed to test 
every instruction preceding and following every other instruction.  Each 
instruction stands alone other than the specified changes to the CPU 
state such as flags, stack and memory which influence the operation of 
instructions, but are easy to test without regard to the instruction 
which controlled them.

So how did you get by without interrupts in your CPU design?  Was it a 
matter of only tasking the CPU with a single process at a time using a 
wait or using a polling loop to monitor several things which need to be 
controlled?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49495

On 7/25/2016 2:13 PM, rickman wrote:
> On 7/25/2016 1:02 PM, Brad Eckert wrote:
>> On Sunday, July 24, 2016 at 9:18:02 PM UTC-7, rickman wrote:
>>> One clock cycle interrupt response time *always*.  Not sure why Brad
>>> says interrupts aren't needed.  I guess he figures you can do anything
>>> you want with polling or maybe he would use a wait instruction like the
>>> Transputer and the F18A.
>>
>> That is kind of a broad statement. The last time I designed a CPU,
>> interrupts were a pain to debug because you have to make sure they
>> work anytime.
>>
>> One time I implemented interrupts by having the hardware doctor the
>> return instruction. If an interrupt was pending, RET would jump to the
>> ISR instead of popping the jump address off the return stack. That
>> worked pretty well (since Forth is so finely factored) and was easy to
>> test.
>
> What exactly would make an interrupt hard to verify?  The CPUs I design
> are rather simple with one clock cycle per instruction.  The interrupt
> acknowledge is just another instruction that is executed in place of the
> instruction which was being fetched.  Not at all hard to verify.
>
> I don't think it is needed to test every possible IRQ with each
> instruction last or next executed.  No more than it is needed to test
> every instruction preceding and following every other instruction.  Each
> instruction stands alone other than the specified changes to the CPU
> state such as flags, stack and memory which influence the operation of
> instructions, but are easy to test without regard to the instruction
> which controlled them.
>
> So how did you get by without interrupts in your CPU design?  Was it a
> matter of only tasking the CPU with a single process at a time using a
> wait or using a polling loop to monitor several things which need to be
> controlled?

I see comp.arch.vhdl was not included in the reply to list.  Shame, I 
cross-posted to see what cross-pollination we might find.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49500

On Monday, July 25, 2016 at 11:13:23 AM UTC-7, rickman wrote:
> 
> What exactly would make an interrupt hard to verify?  The CPUs I design 
> are rather simple with one clock cycle per instruction.  The interrupt 
> acknowledge is just another instruction that is executed in place of the 
> instruction which was being fetched.  Not at all hard to verify.

I guess it depends on the CPU. I also needed to stop the CPU for an arbitrary number of cycles while external memory did its thing. I ended up having to hit the CPU with randomly placed interrupts and various wait states to see where it was breaking.

The RET trick worked well for sampling a CODEC. No need to save scratchpad registers like A and carry.

> 
> So how did you get by without interrupts in your CPU design?  Was it a 
> matter of only tasking the CPU with a single process at a time using a 
> wait or using a polling loop to monitor several things which need to be 
> controlled?

The Forth cooperative multitasker. I posted it here a few years ago. I just made sure the task loop ran faster than the allowed polling latency. That can be checked in simulation.

[toc] | [prev] | [next] | [standalone]

#49504

On 7/25/2016 6:04 PM, Brad Eckert wrote:
> On Monday, July 25, 2016 at 11:13:23 AM UTC-7, rickman wrote:
>>
>> What exactly would make an interrupt hard to verify?  The CPUs I design
>> are rather simple with one clock cycle per instruction.  The interrupt
>> acknowledge is just another instruction that is executed in place of the
>> instruction which was being fetched.  Not at all hard to verify.
>
> I guess it depends on the CPU. I also needed to stop the CPU for an arbitrary number of cycles while external memory did its thing. I ended up having to hit the CPU with randomly placed interrupts and various wait states to see where it was breaking.
>
> The RET trick worked well for sampling a CODEC. No need to save scratchpad registers like A and carry.

 From what you wrote before I think you are saying that the return 
instruction would conditionally either execute the return or do a branch 
to the ISR if the interrupt was pending.  Did it also save context or 
was that up to the ISR?  I think James Bowman just didn't have any 
context other than the PC to save.  My CPU has several flags and of 
course the interrupt control.  I am starting to learn the flags are not 
really needed, the Forth way, simplify.  Maybe the interrupts aren't 
needed either.  I put them in mainly because at the time I was designing 
a CPU based on what I had seen others do.  How many CPUs don't have 
interrupts?  I think the Propeller is the only one I've seen.


>> So how did you get by without interrupts in your CPU design?  Was it a
>> matter of only tasking the CPU with a single process at a time using a
>> wait or using a polling loop to monitor several things which need to be
>> controlled?
>
> The Forth cooperative multitasker. I posted it here a few years ago. I just made sure the task loop ran faster than the allowed polling latency. That can be checked in simulation.

Yeah, if the CPU runs fast enough that works ok, except for priority 
issues.  If you have a slow item in the list and a higher priority item 
needs handling, you also have to get out of the low priority item fast 
enough to handle the high priority item.  I find this pretty complex in 
some systems.  But if your needs are simple enough, why use complicated 
hardware?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49506

On Monday, July 25, 2016 at 4:29:00 PM UTC-7, rickman wrote:
> On 7/25/2016 6:04 PM, Brad Eckert wrote:
>> The RET trick worked well for sampling a CODEC. No need to save
>> scratchpad registers like A and carry.
> 
>  From what you wrote before I think you are saying that the return 
> instruction would conditionally either execute the return or do a branch 
> to the ISR if the interrupt was pending.  Did it also save context or 
> was that up to the ISR?  

The ISR would have saved context, although there wasn't much to save. I used an A register, like colorForth, and !A and !A+ use that for the address so they only pop one cell off the stack. The neat thing about servicing the ISR at RET boundaries is that A and any flags are free to be trashed. You don't have to save/restore them. A scratchpad register or two is nice to have in a stack machine.

> 
>>> So how did you get by without interrupts in your CPU design?  Was it a
>>> matter of only tasking the CPU with a single process at a time using a
>>> wait or using a polling loop to monitor several things which need to be
>>> controlled?
>>
>> The Forth cooperative multitasker. I posted it here a few years ago.
>> I just made sure the task loop ran faster than the allowed polling
>> latency. That can be checked in simulation.
> 
> Yeah, if the CPU runs fast enough that works ok, except for priority 
> issues.  If you have a slow item in the list and a higher priority item 
> needs handling, you also have to get out of the low priority item fast 
> enough to handle the high priority item.  I find this pretty complex in 
> some systems.  But if your needs are simple enough, why use complicated 
> hardware?
> 

Forth has historically gotten a lot of mileage out of a tight cooperative multitasker. There's a lot to be said for the judicious use of PAUSE for tuning the system and for only switching context at points where you decide. PAUSE gives up control to the next task, causing a trip around the task queue. Lower priority tasks do less processing between PAUSEs. 

The same idea also applies to the RET-modifying interrupt. You're yielding to the interrupt at safe times, when there is no need to save temporary registers. Typical Forth uses an ISR to do high speed stuff and then wakes up a task that performs the less time-critical clean-up. Pushing this idea down to hardware, VHDL/Verlog-defined hardware performs high speed stuff and requests an interrupt for cleanup.

[toc] | [prev] | [next] | [standalone]

#49513

On 7/25/2016 8:20 PM, Brad Eckert wrote:
> On Monday, July 25, 2016 at 4:29:00 PM UTC-7, rickman wrote:
>> On 7/25/2016 6:04 PM, Brad Eckert wrote:
>>> The RET trick worked well for sampling a CODEC. No need to save
>>> scratchpad registers like A and carry.
>>
>>  From what you wrote before I think you are saying that the return
>> instruction would conditionally either execute the return or do a branch
>> to the ISR if the interrupt was pending.  Did it also save context or
>> was that up to the ISR?
>
> The ISR would have saved context, although there wasn't much to save. I used an A register, like colorForth, and !A and !A+ use that for the address so they only pop one cell off the stack. The neat thing about servicing the ISR at RET boundaries is that A and any flags are free to be trashed. You don't have to save/restore them. A scratchpad register or two is nice to have in a stack machine.

I don't follow.  How does a return boundary preclude the need to deal 
with context?  Are you saying the calling routing is required to save 
all context?  Isn't that usually done in the subroutine to save having 
to deal with context that won't be disrupted?  Only the subroutine knows 
what that will be.


>>>> So how did you get by without interrupts in your CPU design?  Was it a
>>>> matter of only tasking the CPU with a single process at a time using a
>>>> wait or using a polling loop to monitor several things which need to be
>>>> controlled?
>>>
>>> The Forth cooperative multitasker. I posted it here a few years ago.
>>> I just made sure the task loop ran faster than the allowed polling
>>> latency. That can be checked in simulation.
>>
>> Yeah, if the CPU runs fast enough that works ok, except for priority
>> issues.  If you have a slow item in the list and a higher priority item
>> needs handling, you also have to get out of the low priority item fast
>> enough to handle the high priority item.  I find this pretty complex in
>> some systems.  But if your needs are simple enough, why use complicated
>> hardware?
>>
>
> Forth has historically gotten a lot of mileage out of a tight cooperative multitasker. There's a lot to be said for the judicious use of PAUSE for tuning the system and for only switching context at points where you decide. PAUSE gives up control to the next task, causing a trip around the task queue. Lower priority tasks do less processing between PAUSEs.

I don't follow this too well either, but I won't ask you to explain it. 
I am used to thinking of interrupts dealing with hardware that requires 
tight deadlines.  I think the multitasker you are describing will work 
for looser situations where response times can be much longer.


> The same idea also applies to the RET-modifying interrupt. You're yielding to the interrupt at safe times, when there is no need to save temporary registers. Typical Forth uses an ISR to do high speed stuff and then wakes up a task that performs the less time-critical clean-up. Pushing this idea down to hardware, VHDL/Verlog-defined hardware performs high speed stuff and requests an interrupt for cleanup.

I think you are saying to remove all the hard deadline functions from 
the processor and do them in hardware.  That's not always possible.  I 
have a design in production using a 3 kLUT FPGA which is some 85% full. 
If more logic is needed it would be tough to add it, which is not 
uncommon.  In fact, one of my options for an expansion is to add a very 
small processor core to do the lower speed stuff.  But then the 
processor will be left with a lot of higher speed stuff in hardware to 
interface to which must be dealt with on a short deadline.

I wouldn't mind redesigning this unit with a larger FPGA, but all the 
newer stuff is in BGA packaging with fine pitch.  That means the PCB 
will get more expensive.
-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49523

rickman <gnuarm@gmail.com> wrote:
> 
> Yeah, if the CPU runs fast enough that works ok, except for priority
> issues.  If you have a slow item in the list and a higher priority
> item needs handling, you also have to get out of the low priority
> item fast enough to handle the high priority item.  I find this
> pretty complex in some systems.  But if your needs are simple
> enough, why use complicated hardware?

I've never found that interrupt priorities woked very well for me.  It
seems better to do whatever you need to do urgently in the ISR and
kick a task to do the bulk of the work.  I guess if you're controlling
something that really needs accurate timing (bit-banging a serial
port? high-speed stepper motor control?) you might still need
priorities, but in practice there can only be one high- priority
interrupt anyway.  ARM has always had FIQ, which is nice.

Andrew.

[toc] | [prev] | [next] | [standalone]

#49542

On 7/26/2016 4:07 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>>
>> Yeah, if the CPU runs fast enough that works ok, except for priority
>> issues.  If you have a slow item in the list and a higher priority
>> item needs handling, you also have to get out of the low priority
>> item fast enough to handle the high priority item.  I find this
>> pretty complex in some systems.  But if your needs are simple
>> enough, why use complicated hardware?
>
> I've never found that interrupt priorities woked very well for me.  It
> seems better to do whatever you need to do urgently in the ISR and
> kick a task to do the bulk of the work.  I guess if you're controlling
> something that really needs accurate timing (bit-banging a serial
> port? high-speed stepper motor control?) you might still need
> priorities, but in practice there can only be one high- priority
> interrupt anyway.  ARM has always had FIQ, which is nice.

Priority is a ranking, not just high or low.  The point is that the 
slower interrupts can be interrupted to process a higher priority 
interrupt if that higher priority task is quick enough to not present a 
problem for the lower priority interrupt.  If you have more than two 
such interrupts the issues can get very sticky very quickly, but that is 
not to say it is automatically unmanageable.  Much depends on the details.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49548

On Tuesday, July 26, 2016 at 10:05:11 AM UTC-7, rickman wrote:
> On 7/26/2016 4:07 AM, Andrew Haley wrote:
> > rickman <gnuarm@gmail.com> wrote:
> >>
> >> Yeah, if the CPU runs fast enough that works ok, except for priority
> >> issues.  If you have a slow item in the list and a higher priority
> >> item needs handling, you also have to get out of the low priority
> >> item fast enough to handle the high priority item.  I find this
> >> pretty complex in some systems.  But if your needs are simple
> >> enough, why use complicated hardware?
> >
> > I've never found that interrupt priorities woked very well for me.  It
> > seems better to do whatever you need to do urgently in the ISR and
> > kick a task to do the bulk of the work.  I guess if you're controlling
> > something that really needs accurate timing (bit-banging a serial
> > port? high-speed stepper motor control?) you might still need
> > priorities, but in practice there can only be one high- priority
> > interrupt anyway.  ARM has always had FIQ, which is nice.
> 
> Priority is a ranking, not just high or low.  The point is that the 
> slower interrupts can be interrupted to process a higher priority 
> interrupt if that higher priority task is quick enough to not present a 
> problem for the lower priority interrupt.  If you have more than two 
> such interrupts the issues can get very sticky very quickly, but that is 
> not to say it is automatically unmanageable.  Much depends on the details.
> 
One trick that I like to use with slow interrupts is to re-enable lower priority interrupts once the time critical part of the ISR is finished. Some 8051 code, for example:

    MOV A, #LOW(ADC0_compute)
    PUSH ACC
    MOV A, #HIGH(ADC0_compute)
    PUSH ACC
    RETI  ;Jump to clean-up code, re-enabling interrupts

This comes in handy in cases where a high priority interrupt has some non-time-critical work to do.

[toc] | [prev] | [next] | [standalone]

#49552

rickman <gnuarm@gmail.com> wrote:
> On 7/26/2016 4:07 AM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>>
>>> Yeah, if the CPU runs fast enough that works ok, except for priority
>>> issues.  If you have a slow item in the list and a higher priority
>>> item needs handling, you also have to get out of the low priority
>>> item fast enough to handle the high priority item.  I find this
>>> pretty complex in some systems.  But if your needs are simple
>>> enough, why use complicated hardware?
>>
>> I've never found that interrupt priorities woked very well for me.  It
>> seems better to do whatever you need to do urgently in the ISR and
>> kick a task to do the bulk of the work.  I guess if you're controlling
>> something that really needs accurate timing (bit-banging a serial
>> port? high-speed stepper motor control?) you might still need
>> priorities, but in practice there can only be one high-priority
>> interrupt anyway.  ARM has always had FIQ, which is nice.
> 
> Priority is a ranking, not just high or low.

Eh?  What is a ranking, if not from high to low?  

> The point is that the slower interrupts can be interrupted to
> process a higher priority interrupt if that higher priority task is
> quick enough to not present a problem for the lower priority
> interrupt.  If you have more than two such interrupts the issues can
> get very sticky very quickly, but that is not to say it is
> automatically unmanageable.  Much depends on the details.

Sure, I know how it's supposed to work, of course.  It's just that
when you have several levels of interrupt priority it's extremely hard
to program in such a way that you can guarantee that everything
happens in time, and in practice I've a found it easier not to bother.

Also, interrupts take time and space: when you have nested interrupts
every one of them has to save some context and that really costs,
especially when you don't know what needs to be saved.  If you have a
super-fast interrupt mechanism with its own set of registers you can
do the work for a few instructions and return, barely spilling
anything.  Sure, you have to sacrifice priority to get that to work,
but the whole mechanism has far less overhead.

Andrew.

[toc] | [prev] | [next] | [standalone]

#49565

On 7/27/2016 4:57 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/26/2016 4:07 AM, Andrew Haley wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>>
>>>> Yeah, if the CPU runs fast enough that works ok, except for priority
>>>> issues.  If you have a slow item in the list and a higher priority
>>>> item needs handling, you also have to get out of the low priority
>>>> item fast enough to handle the high priority item.  I find this
>>>> pretty complex in some systems.  But if your needs are simple
>>>> enough, why use complicated hardware?
>>>
>>> I've never found that interrupt priorities woked very well for me.  It
>>> seems better to do whatever you need to do urgently in the ISR and
>>> kick a task to do the bulk of the work.  I guess if you're controlling
>>> something that really needs accurate timing (bit-banging a serial
>>> port? high-speed stepper motor control?) you might still need
>>> priorities, but in practice there can only be one high-priority
>>> interrupt anyway.  ARM has always had FIQ, which is nice.
>>
>> Priority is a ranking, not just high or low.
>
> Eh?  What is a ranking, if not from high to low?

I mean it is not binary.  More like colors than a bit.


>> The point is that the slower interrupts can be interrupted to
>> process a higher priority interrupt if that higher priority task is
>> quick enough to not present a problem for the lower priority
>> interrupt.  If you have more than two such interrupts the issues can
>> get very sticky very quickly, but that is not to say it is
>> automatically unmanageable.  Much depends on the details.
>
> Sure, I know how it's supposed to work, of course.  It's just that
> when you have several levels of interrupt priority it's extremely hard
> to program in such a way that you can guarantee that everything
> happens in time, and in practice I've a found it easier not to bother.

That only depends on the details of your timings, requirements vs. code. 
  The priority only determines who can interrupt whom.  This does not 
automagically fix timing problems.


> Also, interrupts take time and space: when you have nested interrupts
> every one of them has to save some context and that really costs,
> especially when you don't know what needs to be saved.

Why would an interrupt routine not know what context needed to be saved? 
  If it uses five registers, it needs to save those five registers.


> If you have a
> super-fast interrupt mechanism with its own set of registers you can
> do the work for a few instructions and return, barely spilling
> anything.  Sure, you have to sacrifice priority to get that to work,
> but the whole mechanism has far less overhead.

Not sure what you mean about "sacrifice priority".  I think you are 
suggesting a single interrupt priority, but that doesn't follow.  If you 
have a second set of registers, you can have a third, fourth, etc. or 
have other priority interrupts which reuse the main registers and do 
need to save/restore context.  But on stack machines very little context 
needs to be saved, often just the return address or possible a status 
word.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49571

rickman <gnuarm@gmail.com> wrote:
> On 7/27/2016 4:57 AM, Andrew Haley wrote:

>> Sure, I know how it's supposed to work, of course.  It's just that
>> when you have several levels of interrupt priority it's extremely hard
>> to program in such a way that you can guarantee that everything
>> happens in time, and in practice I've a found it easier not to bother.
> 
> That only depends on the details of your timings, requirements
> vs. code.  The priority only determines who can interrupt whom.
> This does not automagically fix timing problems.

Of course.  We both know that.  What is your point?

>> Also, interrupts take time and space: when you have nested interrupts
>> every one of them has to save some context and that really costs,
>> especially when you don't know what needs to be saved.
> 
> Why would an interrupt routine not know what context needed to be saved? 
>  If it uses five registers, it needs to save those five registers.

Of course, but you don't know that those five registers are live at
the time.  So you push them anyway.

Instead (in a conventional register-based CPU) you can do this:

IRQ
  -> push registers
  while some interrupt is active
     handle one interrupt
  -> pop registers
IRET

So the worst case space usage is one set of registers pushed onto the
stack.  But this only works if the interrupt routines are small and
fast.

I have a lovely memory of a system with nasty interrupt code for
handling of serial inputs and which made the serial port a high-
priority interrupt, so high-speed serial data caused data acquisition
to lose data.  And, of course, the priorities were hard wired.

>> If you have a super-fast interrupt mechanism with its own set of
>> registers you can do the work for a few instructions and return,
>> barely spilling anything.  Sure, you have to sacrifice priority to
>> get that to work, but the whole mechanism has far less overhead.
> 
> Not sure what you mean about "sacrifice priority".  I think you are
> suggesting a single interrupt priority, but that doesn't follow.  If
> you have a second set of registers, you can have a third, fourth,
> etc. or have other priority interrupts which reuse the main
> registers and do need to save/restore context.

If you had that, sure.  That would be super.  But it's a lot of
silicon, and (sod's law) there will always be more interrupts than
sets of registers.

Andrew.

[toc] | [prev] | [next] | [standalone]

#49574

On 7/27/2016 12:15 PM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/27/2016 4:57 AM, Andrew Haley wrote:
>
>>> Sure, I know how it's supposed to work, of course.  It's just that
>>> when you have several levels of interrupt priority it's extremely hard
>>> to program in such a way that you can guarantee that everything
>>> happens in time, and in practice I've a found it easier not to bother.
>>
>> That only depends on the details of your timings, requirements
>> vs. code.  The priority only determines who can interrupt whom.
>> This does not automagically fix timing problems.
>
> Of course.  We both know that.  What is your point?

That *is* my point.  You are talking about interrupt priority in the 
context of timing; to different things.  It won't solve all your timing 
problems, but it is a method that can help.


>>> Also, interrupts take time and space: when you have nested interrupts
>>> every one of them has to save some context and that really costs,
>>> especially when you don't know what needs to be saved.
>>
>> Why would an interrupt routine not know what context needed to be saved?
>>  If it uses five registers, it needs to save those five registers.
>
> Of course, but you don't know that those five registers are live at
> the time.  So you push them anyway.
>
> Instead (in a conventional register-based CPU) you can do this:
>
> IRQ
>   -> push registers
>   while some interrupt is active
>      handle one interrupt
>   -> pop registers
> IRET
>
> So the worst case space usage is one set of registers pushed onto the
> stack.  But this only works if the interrupt routines are small and
> fast.
>
> I have a lovely memory of a system with nasty interrupt code for
> handling of serial inputs and which made the serial port a high-
> priority interrupt, so high-speed serial data caused data acquisition
> to lose data.  And, of course, the priorities were hard wired.

I'm not clear on where you are going with this.  What is the alternative 
to interrupt priorities?  You discuss various problems of using 
interrupts.  So?  Every design approach has issues and tradeoffs, not to 
mention poor implementations.


>>> If you have a super-fast interrupt mechanism with its own set of
>>> registers you can do the work for a few instructions and return,
>>> barely spilling anything.  Sure, you have to sacrifice priority to
>>> get that to work, but the whole mechanism has far less overhead.
>>
>> Not sure what you mean about "sacrifice priority".  I think you are
>> suggesting a single interrupt priority, but that doesn't follow.  If
>> you have a second set of registers, you can have a third, fourth,
>> etc. or have other priority interrupts which reuse the main
>> registers and do need to save/restore context.
>
> If you had that, sure.  That would be super.  But it's a lot of
> silicon, and (sod's law) there will always be more interrupts than
> sets of registers.

Really?  Every interrupt you have in your system is too high a priority 
and speed to allow registers to be pushed?  Then you are using the wrong 
tool for the job.  Instead of a CPU, you should be using an FPGA. 
That's my opinion anyway.  Only use a CPU if an FPGA (the simpler 
solution) won't do the job.  No need for messy interrupts and 
interleaved code that is hugely prone to error.  Just assign a processor 
specific to the task and Bob's your uncle.  Why bit bang a UART when you 
can code up a UART that DMAs directly to memory?  We don't need no 
stinkin' CPUs.

I designed a test fixture in an FPGA that receives commands via UART, 
controls the test functions and reports results, very possibly in less 
code than it would take in a CPU.  It now sits in the factory being used 
by them to test boards I sell, allowing me to sit at home and just 
collect the revenue.  :)

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49586

rickman <gnuarm@gmail.com> wrote:
> On 7/27/2016 12:15 PM, Andrew Haley wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> On 7/27/2016 4:57 AM, Andrew Haley wrote:
>>
>> I have a lovely memory of a system with nasty interrupt code for
>> handling of serial inputs and which made the serial port a high-
>> priority interrupt, so high-speed serial data caused data acquisition
>> to lose data.  And, of course, the priorities were hard wired.
> 
> I'm not clear on where you are going with this.  What is the
> alternative to interrupt priorities?  You discuss various problems
> of using interrupts.  So?  Every design approach has issues and
> tradeoffs, not to mention poor implementations.

I think I already said: one approach is to kick stuff out of the
interrupt routine and execute it in a handler task, only doing what is
really necessary in interrupt context.  If every interrupt routine is
small and fast you may well hit timing requirements without needing to
pre-empt "low priority" interrupts with "high priority" ones.  And
sure, that is not always true.  But it's a good starting point.

>> If you had that, sure.  That would be super.  But it's a lot of
>> silicon, and (sod's law) there will always be more interrupts than
>> sets of registers.
> 
> Really?  Every interrupt you have in your system is too high a
> priority and speed to allow registers to be pushed?

No.  That would be silly.  It does not follow from anything that I
wrote, either.

Andrew.

[toc] | [prev] | [next] | [standalone]

#49588

On 7/27/16 11:12 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/27/2016 12:15 PM, Andrew Haley wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>> On 7/27/2016 4:57 AM, Andrew Haley wrote:
>>>
>>> I have a lovely memory of a system with nasty interrupt code for
>>> handling of serial inputs and which made the serial port a high-
>>> priority interrupt, so high-speed serial data caused data acquisition
>>> to lose data.  And, of course, the priorities were hard wired.
>>
>> I'm not clear on where you are going with this.  What is the
>> alternative to interrupt priorities?  You discuss various problems
>> of using interrupts.  So?  Every design approach has issues and
>> tradeoffs, not to mention poor implementations.
>
> I think I already said: one approach is to kick stuff out of the
> interrupt routine and execute it in a handler task, only doing what is
> really necessary in interrupt context.  If every interrupt routine is
> small and fast you may well hit timing requirements without needing to
> pre-empt "low priority" interrupts with "high priority" ones.  And
> sure, that is not always true.  But it's a good starting point.
>
>>> If you had that, sure.  That would be super.  But it's a lot of
>>> silicon, and (sod's law) there will always be more interrupts than
>>> sets of registers.
>>
>> Really?  Every interrupt you have in your system is too high a
>> priority and speed to allow registers to be pushed?
>
> No.  That would be silly.  It does not follow from anything that I
> wrote, either.

I agree with Andrew, an interrupt routine should do only the absolute 
minimum, time-critical actions (if any), and wake up the handler task to 
do the rest. For example, in a data acquisition situation, the interrupt 
code can read a sample and stick it in a circular queue that task-level 
code is managing (say, to do scaling, unit conversion, and storage in a 
database). Many, many interrupt routines I've written and seen are no 
more than 2 or 3 instructions. You don't even need to save registers 
that you aren't actually going to use, which may be one or even none, 
depending on the processor and what you have to do.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#49599

On 7/27/2016 6:43 PM, Elizabeth D. Rather wrote:
>
> I agree with Andrew, an interrupt routine should do only the absolute
> minimum, time-critical actions (if any), and wake up the handler task to
> do the rest.

I think that goes without saying.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49755

On Wednesday, July 27, 2016 at 3:44:01 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/27/16 11:12 AM, Andrew Haley wrote:
> > I think I already said: one approach is to kick stuff out of the
> > interrupt routine and execute it in a handler task, only doing what is
> > really necessary in interrupt context.  If every interrupt routine is
> > small and fast you may well hit timing requirements without needing to
> > pre-empt "low priority" interrupts with "high priority" ones.  And
> > sure, that is not always true.  But it's a good starting point.

> I agree with Andrew, an interrupt routine should do only the absolute 
> minimum, time-critical actions (if any), and wake up the handler task to 
> do the rest. 

Andrew Haley is an employee of Forth Inc. --- that is why Elizabeth Rather appointed him to the Forth-200x committee --- now she is agreeing with him to help boost his expert status.

The guy says that ISRs should be small and fast. Really??? Well, yeah --- nobody is arguing that they should be big and slow.

> For example, in a data acquisition situation, the interrupt 
> code can read a sample and stick it in a circular queue that task-level 
> code is managing (say, to do scaling, unit conversion, and storage in a 
> database). Many, many interrupt routines I've written and seen are no 
> more than 2 or 3 instructions. 

Elizabeth Rather is lying. There are no ISRs that are only 2 or 3 instructions long. She heard somewhere that ISRs are supposed to be small, so she claims that hers are super-duper small.

This reminds me of when I went to Sportsmans' Warehouse to look at rifles. I first looked at a .22-magnum and the salesman told me he owned that very model and it was super accurate. Then about 10 minutes later I looked at a .270 and the same salesman told me that he owned that very model also (what a coincidence!), and that he got a 1/2 inch group at 200 yards with it. Really??? That is 1/4 of a minute!!! Most out-of-the-box rifles get 2 or 3 minutes of precision, but with some expensive gunsmithing work done they can get 1 minute of angle.

Elizabeth Rather is just a glib sales-person who lies every time that she opens her stupid mouth. ANS-Forth is just a marketing gimmick from Forth Inc. that has no technical merit whatsoever. Forth-200x is more of the same. Nobody will ever take Forth seriously so long as Forth Inc. is involved in the standards process --- Forth Inc. is the reason why Forth failed --- if Forth is going to succeed, Forth Inc. has to be jettisoned.

BTW: The following is one of the funnier examples of Elizabeth Rather writing short and fast functions. LOL! This is taken directly from the SwiftForth-v2 source-code:

ICODE ALIGNED ( a -- a )
   RET END-CODE                     \ aligned is noop, no alignment
enforced

ICODE ALIGN ( -- )
   RET END-CODE                     \ align is noop, no alignment
enforced

I was informed recently that Elizabeth Rather can't be blamed for the low-quality of SwiftForth because SwiftForth was actually written by Rick van Norman. Whatever! He was just another employee of Forth Inc., no different than Andrew Haley. Everything that comes out of Forth Inc. is crap, including ANS-Forth and Forth-200x.

[toc] | [prev] | [next] | [standalone]

#49598

On 7/27/2016 5:12 PM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/27/2016 12:15 PM, Andrew Haley wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>> On 7/27/2016 4:57 AM, Andrew Haley wrote:
>>>
>>> I have a lovely memory of a system with nasty interrupt code for
>>> handling of serial inputs and which made the serial port a high-
>>> priority interrupt, so high-speed serial data caused data acquisition
>>> to lose data.  And, of course, the priorities were hard wired.
>>
>> I'm not clear on where you are going with this.  What is the
>> alternative to interrupt priorities?  You discuss various problems
>> of using interrupts.  So?  Every design approach has issues and
>> tradeoffs, not to mention poor implementations.
>
> I think I already said: one approach is to kick stuff out of the
> interrupt routine and execute it in a handler task, only doing what is
> really necessary in interrupt context.  If every interrupt routine is
> small and fast you may well hit timing requirements without needing to
> pre-empt "low priority" interrupts with "high priority" ones.  And
> sure, that is not always true.  But it's a good starting point.

I'm not sure why you say that.  ISRs are *always* trimmed to the minimum 
required, at least in my designs.

This is going on too long.  We are both saying essentially the same 
thing, the solution needs to fit the problem.


>>> If you had that, sure.  That would be super.  But it's a lot of
>>> silicon, and (sod's law) there will always be more interrupts than
>>> sets of registers.
>>
>> Really?  Every interrupt you have in your system is too high a
>> priority and speed to allow registers to be pushed?
>
> No.  That would be silly.  It does not follow from anything that I
> wrote, either.

It comes from your complaint that some interrupts won't have dedicated 
register sets.  If those interrupts have time to save/restore registers 
then they don't need dedicated hardware.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49459

W dniu poniedziałek, 25 lipca 2016 04:29:28 UTC+2 użytkownik rickman napisał:
> 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.
> 
> -- 
> 
> Rick C

A few days ago I have prepared a port of James Bowman's J1 to VHDL. My fork of his github repository is available at https://github.com/wzab/swapforth
There is also yet another port (started in 2013 by Richard James Howe) at https://github.com/howerj/forth-cpu

In my port I tried to keep the code as similar to the original as possible to allow easy maintaining in case of further development of the original J1B.
My version is equipped with the GHDL testbench, which can be controlled from the Linux pseudotty. (My aim was to allow testing of Forth routines with VHDL blocks for FPGA in GHDL based environment. The Forth CPU is supposed to be used as an initialization/debugging controller for systems based on relatively simple FPGAs)

Unfortunately, the simulation in GHDL is much slower than the simulation of original code in Verilator, however it is possible to work interactively.

I have equipped the testbench with the functionality which dumps the RAM to the file after accessing certain IO port. So it is possible to skip the long loading of swapforth.fs at the begining of simulation and start with all words already defined.

I have tested the ported version in synthesis (only on Cyclone V at the moment) and it works correctly.

With best regards,
Wojtek

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web