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


Groups > comp.lang.forth > #49565

Re: Forth in VHDL

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Forth in VHDL
Date 2016-07-27 10:34 -0400
Organization A noiseless patient Spider
Message-ID <nnagpn$u95$1@dont-email.me> (permalink)
References (7 earlier) <f7479a82-917b-43da-946f-dbb3e22a07fb@googlegroups.com> <nn67bq$tku$1@dont-email.me> <5rGdnckBa-PfhwrKnZ2dnUU78Y3NnZ2d@supernews.com> <nn8584$nu0$1@dont-email.me> <5tidnYsqXL0S6gXKnZ2dnUU78TPNnZ2d@supernews.com>

Show all headers | View raw


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

Back to comp.lang.forth | 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 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

csiph-web