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

Groups > comp.arch.embedded > #27034

Re: ARM Cortex Mx vs the rest of the gang

Show all headers | View raw

On 07/11/17 19:15, Don Y wrote:

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

Make a rough estimate during development, then fine tune to fix
edge cases, or where a bit more headroom is needed for individual
tasks. No design is fixed in stone from the start.

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

You seem to be assuming high end systems running at the ragged
edge, which isn't the sort of work done here. Leave that to the mobile,
tablet and workstation / graphics people. You can't even be fluent in
all aspects of computing, let alone the electronics that enables it.

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

Not sure. From a performance point of view, perhaps, but optimisation
can reduce memory footprint, critical for some embedded work.

 >
 > 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"?

I guess you are talking arm?. FIRQ is a leftover from early arm, fwir.
Have you seen amount of tortuous code needed to get interrupts
working properly with Arm7TDMI, for example?. About 2 pages of dense
assembler, from memory. I rejected early arm almost on that basis
alone, but there were other idiosyncracies. They fixed it eventually
with a proper (68K) style vector table, but it took them a long time
:-). Cortex was when Arm finally came of age.

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


It's a case of organisinmg system design, task allocation etc, so
that you get a result that meets spec. Think systems engineering.
If you have limited resources, something has to give, but would
prefer a situation where an fpu operation always runs to completion.
It's the simplest solution and the fewest variables in terms
of  estimating performance.

Interrupting and saving fpu state could be done, but only if all
other avenues have been explored. it's a whole can or worms best
avoided if possible and dependent on the actual fpu in use. It needs
memory to save context, added management code and maybe complex
synchronisation issues. Even if you make it work, May turn out to
be less efficient than run to completion.

Anyway, all kinds of events affect scheduling decisions, even if
indirectly. To make a waiting process ready, for example. Don't see what
the problem is. Perhaps that's the issue: Some always look for
issues, while others assume everything is going to work.

 >
 > 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 don't want fine grained access if possible. I want a black box to
feed data and get a result. Not really interested what happens
under the hood, so long as it meets requirements and is predictable.

 >
 > 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" :>

Simple, both memory and processors were slow in those days and needed
all the help they could get. Modern processors arguably don't need them
for most applications. Do commercial tool chains make use of them ?.
Last time I checked, gcc still didn't know about interrupts, though
some vendors do add extensions.

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

Competitive market perhaps ?. Featureitis between vendors to cater for
widest application and market share. With most work these days, only
use a fraction of the internal arch and throughout. I see that as good,
as there's more freedom to think systems engineering, rather than detail.

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

Perhaps many modern apps don't need it, but don't write apps, so what
do I know ?. It's not only windows and Linux that suffer from bloat
these days.

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

Are we talking about vanilla embedded work here, or big system design ?.

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

Agreed, but much embedded work is not big systems stuff, but at simple
state driven loop or rtos level. Ok, phones etc are all some
flavor of unix, Linux, whatever, but not typical embedded.

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

That's why mainstream os's have loaders and memory management, because
you want maximum flexibity, whereas embedded is usually locked down
to particular need.

I don't get into pc stuff, it's just a tool and I assume that it works,
which it generally does. Same for Linux, but FreeBSD gets more and more
interesting and is rock solid on X86 and Sparc here. After systemd and
other bloat issues, Linux becomes less and less attractive.

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

Been chucking it down all day here today in Oxford, but that's uk
summer weather and as you say, an excuse to catch up with the groups
and get into some back burner ideas. Too many interests and not
enough time, as usual :-)...

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