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

Groups > comp.arch.embedded > #27032

Re: ARM Cortex Mx vs the rest of the gang

Show all headers | View raw

On 7/11/2017 9:24 AM, Chris wrote:
> 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.

Or, design a strategy that will *adapt* to the needs of the application
without having to make that decision /a priori/.

>  > 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.

Of course.  But the "when" becomes a driving factor.  You design
the system based on the intrinsic priorities of the "actors"
competing for those resources.  You don't decide that "its hard"
to give an actor his just due and, thus, rejiggle the "priorities"
to fit something more convenient.

> Who waits depends on task priorities, fpu state may have
> to be saved, but so what ?. 

But it may *not* "have to be saved".  You're assuming the task to be
assuming control of the processor *does* need the FPU and WILL need it
"presently" -- so save the state NOW instead of deferring the
act until it PROVES to be necessary (said "proof" being indicated
by the execution of a floating point operation).

The state of the FPU is *big* in most processors.  With multicore
chips, that's multiplied by the number of cores.  THE MEMORY BANDWIDTH
IS FIXED (and shared by *all* cores).  Why move temporally distant
data through that pipe if you don't NEED to do so?

> 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.

Why do compilers worry so much about optimization?  We *surely*
shouldn't NEED the effective resource gain that these options
provide, right?

Unconditionally saving and restoring the FPU's state is akin to
unconditionally saving the entire state of the CPU for each
interrupt -- why invent things like FIRQ (which costs real silicon)
if these constraints "shouldn't happen these days"?

Why optimize away:
        foo += number;
        foo -= number;
SURELY we can afford a pair of integer (?) operations!  :>

>  > 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.

You are using the current state of the FPU (busy) to effectively
make a scheduling decision -- without knowledge of whether or not
the task that SHOULD be executing, next (based on the scheduling
criteria selected AT DESIGN TIME) will actually need the FPU *or*
will need it "in this next period of execution" (avoiding the term
"time slice" because preemptive schedulers tend not to be driven
strictly by "time").  *OR*, even "shortly".

When will the *deferred* highest priority task get his next opportunity
to run?  If you jigger with the priorities, then he's no longer
the most eligible to run (you may, in fact, have introduced a deadlock
that the *design* had implicitly avoided in its assignment of "priority").

[I assume you understand that "priority" in the sense used in scheduling
is NOT a "small integer used to artificially impose order on competing
actors"]

>  >> 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.

If you want finer-grained access to the FPU, then you have to be willing
to save and restore the contexts of the individual clients on a transactional
basis.  I.e., either load the FPU context of the IPC being serviced *now*,
run the opcode and then save the context as you're passing the results
to the client.  Or, leave the most recently loaded context *in* the FPU
until you examine the next incoming IPC to determine *if* there is a
need to swap out the context currently residing therein.

Your other arguments advocate unconditionally loading and saving the
*current* client's FPU context on each IPC -- regardless of recent past
history of that resource.  My argument is to leave whatever context
happens to be *in* the FPU there -- in the hope that the next request
MIGHT be from the same client; only swap contexts when you KNOW the
new client is a different entity than the last and, therefore, avoid
the overhead of a save-restore PER IPC.

>  > 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.

Ask yourself:  why did the vendor include these instructions in the
processor's design?  Why did they complicate the silicon, and the
programming model.  Surely, the developer has adequate resources
to blindly save the entire state; why provide provisions to save
only part of it?  "It shouldn't happen these days"  :>

Why would an MCU vendor add silicon and programming complexity
to a design to support this sort of treatment of the FPU?
Why waste an engineer's time documenting it:
<http://infocenter.arm.com/help/topic/com.arm.doc.dai0298a/DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf>
Surely, the developer shouldn't need to tune an application
(OS) to this extent, these days! (?)

> 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.

Modern APPLICATIONS are orders of magnitude more complex!   And,
you don't always use features to gain performance but, also, to
gain reliability, etc.

If I, the developer, KNOW that a particular task/process/thread
doesn't use the FPU, why wouldn't I want to take advantage of a mechanism
that tells me *if* an attempt is made to use the FPU (by THAT task)?
And, if so notified, wouldn't I want to *do* something about it?

If I, the developer, KNOW that my task's memory references are
constrained to the region [LOW,HIGH] -- because some other task
accesses the adjoining memory above/below that region -- wouldn't
I want to take advantage of a mechanism that tells me *if* an
attempt is made to access memory outside that region?

If I, the developer, KNOW that my task should NEVER be accessing a
particular file, device, etc. wouldn't I want to take advantage
of a mechanism that tells me *if* it tries to do so?

Or, tries to WRITE to program memory (CODE)?

Or, tries to grow the stack beyond the limits determined at design time?

Or, tries to "hog" the CPU?

etc.

> 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.

The opposite is true.  Why do we see increasingly complex OS's in use?
Ans:  because you can design the mechanisms to detect and protect
against UNRELIABLE program operation *once* and leverage that across
applications and application domains.

Why do we see HLL's in use?  Ans:  it makes it easier for developers to
code larger programs *reliably*.  (Why "larger"?  Because applications
are getting orders of magnitude more complex).

> It's rarely
> properly documented, so the poor soul who replaces you will have no idea
> why the design decisions were made.

If the poor soul is competent to design an operating system, then he
SHOULD be skilled enough in his art to understand the ideas that are
frequently exploited in operating system designs.  If not, he shouldn't
be tinkering with the OS's implementation.

(You wouldn't want someone who doesn't have a deep understanding of
floating point issues to be writing a floating point emulation library,
would you?)

The developer (writing the *application*) need not be concerned about
the minutiae of how context switches are performed.  Do you have to
understand how a multilevel page table is implemented (and traversed
at runtime) in order to use demand-paged virtual memory?  OTOH,
you *would* if you were charged with maintaining that part of the
codebase!

> Good design is not just about the
> hardware and code, but the whole project infrastructure and the needs
> surrounding it.

Good design is fitting the design *to* the application "most effectively"
(which are squishy words that the developer defines).  If every project
could be handled with a PIC and 2KB of RAM, there'd be no need for
MMU's, FPU's, RTOS's, HLL's, SMP, IPC/RPC, etc.

Thankfully, (cuz that would be a world of pretty BORING applications)
that's not the case.  And, as applications ("projects") get larger,
they quickly grow to a point where they are "complex" (complex:  too
large to fit in one mind) and have to rely on the efforts of many.
Anything that can be done to be a productivity/reliability/performance
multiplier "by purchasing a few more gates on a die" almost always
has a net positive return.

Imagine if the authors of every application running on your PC had
to cooperate to ensure they were all LINKED at non-competing memory
addresses (because there was no relative addressing mode, segments,
virtual memory, etc.).  Instead, the silicon -- and then the OS -- can
assume the burden of providing these mechanisms so the developers
need not be concerned with them.

[I'd wager most PC developers are clueless as to what happens under
the hood when their application is launched.  And, I suspect there
is a boatload of documentation available for them *if* they decided
they had a genuine need to know -- at whatever level of detail they
deemed appropriate!]

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

IME, most non-trivial engineering decisions are hard to summarize in
a page (or ten :> ) or less.

Time to take advantage of 12 hours of rain to do some digging...

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