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


Groups > comp.arch.embedded > #26757

Re: ARM Cortex Mx vs the rest of the gang

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: ARM Cortex Mx vs the rest of the gang
Date 2017-06-12 10:10 -0700
Organization A noiseless patient Spider
Message-ID <ohmho1$1u4$1@dont-email.me> (permalink)
References <2d89fa87-7ca9-4078-b5b7-50ec44c63d43@googlegroups.com> <a2fd718f-9551-462b-8e7d-e324c171a17a@googlegroups.com> <4b6f7bfe-0a96-47eb-8530-e780f8d73b49@googlegroups.com> <8d5c9936-d0fd-4f7c-88d8-7dcd7c16c20b@googlegroups.com> <ohm9t1$gte$1@dont-email.me>

Show all headers | View raw


On 6/12/2017 7:57 AM, Dimiter_Popoff wrote:
> On 12.6.2017 г. 17:21, StateMachineCOM wrote:
>> I said that "... the FPU integration in the Cortex-M4F/M7 is horrible",
>> because it adds tons of overhead and a lot of headache for the
>> system-level software.
>
>> The problem is that the ARM Vector Floating-Point (VFP) coprocessor
>> comes with a big context of 32 32-bit registers (S0-S31). These
>> registers need to be saved and restored as part of every context switch,
>> just like the CPU registers.
>
> They have to be saved during every context switch if the OS is broken.
> What stops it from saving the FPU context only for tasks which use
> the FPU? It is a single bit of information in the task descriptor.

Exactly.

> Then what stops the programmer from declaring the FPU is in use or
> not within a task? Normally what is done for this purpose is
> - enable FPU for tha task, saving the state the previous FPU_in_use bit
> state,
> - do the FPU work,
> - restore the previous state of the FPU_in_use bit.
> Obviously for tasks which use the FPU intensively this needs not
> be done, one just leaves the FPU_in_use on.
>
>> .. ARM has come up with some hardware
>> optimizations called "lazy stacking and context switching" (see ARM
>> AppNote 298 at
>> http://infocenter.arm.com/help/topic/com.arm.doc.dai0298a/DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf
>>
>> ).
>
> I once had a look at that only to confirm my suspicion that it is just
> piling problems over existing problems. Things like this are done
> by software, or rather software is written such that there is no
> need for that sort of thing.
>
>> Anyway, does it have to be that hard? Apparently not. For example the
>> Renesas RX CPU comes also with single precision FPU, which is much
>> better integrated with the CPU and does not have its own register
>> context. Compared to the ARM VFP it is a pleasure to work with.
>
> Not having a separate FPU register set is a disadvantage, not an
> advantage (now if the FPU is a useless 32 bit one having it at all
> is a disadvantage but this is another matter :-).

Exactly.  As memory is now the bottleneck in most designs, any program
state (e.g., floating point values) that have to be saved OUTSIDE the
CPU (even in normal operation, ignoring context switches) take a hit
in terms of performance.  Esp when you're dealing with "big" data types
(64, 80, 128b).

[Guttag clearly missed the boat on that call wrt the 99K.  Cute/clever
idea but he failed to see the growing disparity in the CPU/memory
"impedance mismatch".  But, context switches were a piece of cake!  :>]

> Nothing prevents software from using what it wants and from saving
> only what has to be saved; often having an entire FPU and saving its
> entire context in addition to that of the integer unit makes things more
> efficient, sometimes a lot more efficient (e.g. implementing a FIR
> on a plain FPU where data dependencies do not allow you to do it
> at a speed more than speed/(pipeline length), you just need many
> registers).

Ideally, register-rich processors would implement a set of internal flags
that would be set each time a register was loaded.  And, a "save state"
opcode that acted similar to the 09's PUSH "vector" saving only those
registers that have been "altered".  Then, letting the programmer
clear this "flag register" as it reloaded the preserved state for
the new task.

[An even more flexible/conditional scheme would allow traps for each
register but the overhead of servicing the trap FOR EACH REGISTER
would far outweigh the cost of unconditionally restoring ALL state]

> The e500 cores from freescale were never popular with me exactly
> because they had the integer and FP register sets in one, just 32
> registers in total. Not a good idea on a load/store machine.

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