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

Groups > comp.arch.embedded > #27031

Re: ARM Cortex Mx vs the rest of the gang

Show all headers | View raw

On 07/10/17 23:03, Don Y wrote:

 >
 > Using the FPU *is* complicated in a multithreaded world! :>

Yes, so you have to tightly define how it is accessed for best
results.

 >
 > You want to artificially LOWER the timeliness constraints of TASK_A
 > because the FPU is busy -- even if the VERY FIRST opcode that TASK_A
 > fetches (after it RESUMES execution) might not be a floating point
 > instruction?

If you have contention for a resource, somone has to wait.
Who waits depends on task priorities, fpu state may have
to be saved, but so what ?. There various ways to provide
fair access, but if the design is so critically constrained by timing
issues, then the design is wrong and needs more resources. Ok, we
have all had to deal with that, but it shouldn't happen these days.

 >
 > How do you model this in your system design? Do you profile the
 > frequency of floating point operations in each task and try to
 > predict the likelihood of one thread (task) starting a floating point
 > operation in the instant before a reschedule() event to be followed
 > by another thread (task) that happens to need to execute a floating
 > point operation AT SOME POINT (possibly hours from now)? Does the
 > deferred task (thread) ever regain its DESERVED priority (timeliness)?
 > Or, once "demoted", does it remain that way -- hoping its peers
 > similarly get demoted (by pure chance) so that its RELATIVE priority
 > is reclaimed?
 >
 > You're making a coarse-grained scheduling decision whereas the
 > trap approach just has the appearance of an opcode "taking longer"
 > to execute "in user space".

Sorry, that doesn't make sense.

 >
 >> Other solutions might include encapsulating the fpu within it's own
 >> task, with or without input queue, then use messaging to talk to it ?
 >
 > You can treat the FPU as a "device" -- like a UART, disk drive,
 > NIC, etc. -- and impose sharing (through locks/mutexes) on it.
 > But, this promotes the sharing to a very visible level and forces
 > the developer (and all tasks) to consider the extent of FPU usage
 > in each case where the device is "open()-ed" -- so you can push
 > commands/messages at it.

If you use messaging ipc, the fpu is always ready for data, assuming
the queue is properly sized. If you want to make it priority aware,
just include that with the request, along with a the pid of the
requester. All the fpu internal complexity is hidden from the requester,
which doesn't need to know. While this might not be ideal for an fpu,
a task based model is a great way to encapsulate complexity.

 >
 > Imagine if every ISR preserved and restored the ENTIRE processor state
 > "just to make things simple". Would you consider THAT to be "sound
 > engineering"? :>
 >

 From a practical, keep the code simple point of view and
assuming there are no performance issues, that's the way I might do
it, but even the ancient 68000 had selective register save
instructions. Have used them at times in interrupt handlers, but it
requires poking around in the entrails and asm macros if you
typically write interrupt handlers in C.  Modern cpu's are orders of
magnitude faster, a king's ransome of riches in terms of throughput
and hardware options,  which allows a much more high level view of
the overall design. Ok, for a few apps like image processing and
compression etc, more care might be needed but they are the
exceptions for embedded work, afaics.

We are thankfully, past the stage where it was necessary to hand
optimise all the low level stuff to make systems work and the added
complexity is not good for reliability, nor maintenance. It's rarely
properly documented, so the poor soul who replaces you will have no idea
why the design decisions were made. Good design is not just about the
hardware and code, but the whole project infrastructure and the needs
surrounding it.

This is a bit tl:dr isn't it ?, but you do cover a lot of ground at
once :-)...

Chris

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

ARM Cortex Mx vs the rest of the gang Klaus Kragelund <klauskvik@hotmail.com> - 2017-05-30 05:11 -0700
  ARM Cortex Mx vs the rest of the gang klaus.kragelund@gmail.com - 2017-05-30 05:48 -0700
    Re: ARM Cortex Mx vs the rest of the gang Uwe Bonnes <bon@hertz.tu-darmstadt.de> - 2017-05-30 14:32 +0000
      Re: ARM Cortex Mx vs the rest of the gang Tim Wescott <seemywebsite@myfooter.really> - 2017-05-30 22:07 -0500
        Re: ARM Cortex Mx vs the rest of the gang rickman <gnuarm@gmail.com> - 2017-05-30 23:57 -0400
          Re: ARM Cortex Mx vs the rest of the gang David Brown <david.brown@hesbynett.no> - 2017-05-31 12:08 +0200
            Re: ARM Cortex Mx vs the rest of the gang rickman <gnuarm@gmail.com> - 2017-05-31 09:11 -0400
              Re: ARM Cortex Mx vs the rest of the gang Tim Wescott <seemywebsite@myfooter.really> - 2017-06-01 15:17 -0500
                Re: ARM Cortex Mx vs the rest of the gang rickman <gnuarm@gmail.com> - 2017-06-01 16:27 -0400
                Re: ARM Cortex Mx vs the rest of the gang rickman <gnuarm@gmail.com> - 2017-06-01 16:30 -0400
            Re: ARM Cortex Mx vs the rest of the gang Tim Wescott <seemywebsite@myfooter.really> - 2017-06-01 15:17 -0500
  Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-05-30 07:31 -0700
    Re: ARM Cortex Mx vs the rest of the gang Klaus Kragelund <klauskvik@hotmail.com> - 2017-05-30 08:07 -0700
      Re: ARM Cortex Mx vs the rest of the gang George Neuner <gneuner2@comcast.net> - 2017-05-31 00:38 -0400
      Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-05-30 22:14 -0700
  Re: ARM Cortex Mx vs the rest of the gang rickman <gnuarm@gmail.com> - 2017-05-30 10:53 -0400
  Re: ARM Cortex Mx vs the rest of the gang StateMachineCOM <statemachineguru@gmail.com> - 2017-06-07 12:58 -0700
    Re: ARM Cortex Mx vs the rest of the gang Klaus Kragelund <klauskvik@hotmail.com> - 2017-06-07 13:27 -0700
    Re: ARM Cortex Mx vs the rest of the gang Jack <jack4747@gmail.com> - 2017-06-07 23:24 -0700
      Re: ARM Cortex Mx vs the rest of the gang StateMachineCOM <statemachineguru@gmail.com> - 2017-06-12 07:21 -0700
        Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-12 17:57 +0300
          Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-06-12 10:10 -0700
            Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-12 22:06 +0300
              Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-06-12 12:19 -0700
                Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-12 23:04 +0300
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-06-12 14:34 -0700
                Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-13 02:44 +0300
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-06-12 17:31 -0700
        Re: ARM Cortex Mx vs the rest of the gang Jack <jack4747@gmail.com> - 2017-06-12 08:04 -0700
        Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-06-12 09:54 -0700
          Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-10 13:30 +0000
            Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-07-10 16:03 -0700
              Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-11 16:24 +0000
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-07-11 12:15 -0700
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-11 23:16 +0000
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-07-12 11:44 -0700
                Re: ARM Cortex Mx vs the rest of the gang George Neuner <gneuner2@comcast.net> - 2017-07-12 17:46 -0400
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-07-12 18:12 -0700
                Re: ARM Cortex Mx vs the rest of the gang Anders.Montonen@kapsi.spam.stop.fi.invalid - 2017-07-13 11:42 +0000
                Re: ARM Cortex Mx vs the rest of the gang Don Y <blockedofcourse@foo.invalid> - 2017-07-13 21:38 -0700
                Re: ARM Cortex Mx vs the rest of the gang David Brown <david.brown@hesbynett.no> - 2017-07-13 23:31 +0200
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-14 15:27 +0000
                Re: ARM Cortex Mx vs the rest of the gang David Brown <david.brown@hesbynett.no> - 2017-07-14 17:38 +0200
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-14 16:03 +0000
                Re: ARM Cortex Mx vs the rest of the gang David Brown <david.brown@hesbynett.no> - 2017-07-14 20:20 +0200
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-14 18:59 +0000
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-14 17:17 +0000
                Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-07-15 00:45 +0300
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-14 23:00 +0000
                Re: ARM Cortex Mx vs the rest of the gang Dimiter_Popoff <dp@tgi-sci.com> - 2017-07-15 04:04 +0300
                Re: ARM Cortex Mx vs the rest of the gang Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-16 16:58 +0000
                Re: ARM Cortex Mx vs the rest of the gang Richard Damon <Richard@Damon-Family.org> - 2017-07-14 20:05 -0400
                Re: ARM Cortex Mx vs the rest of the gang Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-07-15 11:53 +0300
                Re: ARM Cortex Mx vs the rest of the gang David Brown <david.brown@hesbynett.no> - 2017-07-15 12:05 +0200
                Re: ARM Cortex Mx vs the rest of the gang Anders.Montonen@kapsi.spam.stop.fi.invalid - 2017-07-20 11:11 +0000
                Re: ARM Cortex Mx vs the rest of the gang Anders.Montonen@kapsi.spam.stop.fi.invalid - 2017-07-20 10:29 +0000
        Re: ARM Cortex Mx vs the rest of the gang "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-06-14 09:54 +0200

csiph-web