Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26761
| 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 14:34 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <ohn15t$rhv$1@dont-email.me> (permalink) |
| References | (4 earlier) <ohm9t1$gte$1@dont-email.me> <ohmho1$1u4$1@dont-email.me> <ohmofq$rke$1@dont-email.me> <ohmpac$usi$1@dont-email.me> <ohmrt4$8v7$1@dont-email.me> |
On 6/12/2017 1:04 PM, Dimiter_Popoff wrote:
> On 12.6.2017 г. 22:19, Don Y wrote:
>> On 6/12/2017 12:06 PM, Dimiter_Popoff wrote:
>>> On 12.6.2017 г. 20:10, Don Y wrote:
>>>>> ....
>>>>
>>>> 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.
>>>
>>> I am not so sure how useful this would be, basically software knows
>>> which registers have been used and which not, it is up to it to save
>>> just what needs to be saved and restore it when needed only.
>>
>> You're not thinking with HLL's in mind -- where a *tool* creates the
>> software
>> (how does the tool tell you, concisely, which registers it used?)
>
> Of course not, although HLL-s should be pretty good at knowing what to
> push/pull. But I certainly consider a language broken if it creates a
> need for hardware not needed when using other languages.
Yes, but the language doesn't know when a context switch is going to be
triggered that swaps out *all* of the processor state!
context switch
restore state of task M
----
do something
alter register Q
task M
do something
alter register P
----
preserve state of task M
context switch
restore state of task N
----
use register Y
alter register Q
task N
...
When preserving the state of task M, *only* the saved state of registers
Q and P needs to be updated as they are the only registers that have been
altered in that portion of task M's execution. The other 873 registers
haven't been altered so the "preserved copies" of their state needn't
be updated.
The problem with traditional architectures is that there is no easy
way of the "context switch" routine knowing what has been altered
since the state for *that* task was most recently preserved.
The hack I proposed would be "reset" as the last step in the context switch
so that any alterations of the register file's contents would be individually
flagged. I.e., at the time of the task switch at the end of task M, the
CPU will have "noticed" that ONLY registers Q & P have been updated
(update can be as simple as noting ANY write to the register *or* as clever
as noting any write that alters the specific contents of *that* register
so overwriting a value of '27' with another '27' would NOT flag the register
as "altered").
So, when the context switch went to "preserve state of task M", it would
execute this magical "PUSH <vector>" command and move only those altered
register contents back into the TCB.
[It's not really a "PUSH" as it needs to put each register in a specific
place relative to some "frame" -- i.e., the TCB -- which could be carefully
arranged to be ToS relative]
>> And, even if you know which registers were used, you don't know which were
>> used SINCE THE LAST CONTEXT SWITCH!
>
> Well and if they are not changed what, you have to mark stack frames
> somehow to know what exactly did you save so you can restore etc.;
> then even if you switch task once per ms the time to save/restore
> all registers is negligible (32 longwords get written to cache on a
> 400 MHz 32 bit processor within 80 ns...).
Yes, but its obvious that the number of cores and the number (and size)
of registers in those cores will only keep increasing as the memory
interface becomes more of a "performance issue". Cache tries to handwave
around this problem -- more buffering doesn't always come without costs
(e.g., having to flush the cache)
N cores means N times the hammering on the memory interface due to
task switches.
> OTOH if it is just an interrupt handler it will know what registers
> it uses and would save just them - and will modify them so there is
> no need to know whether they were changed or not.
Yes -- in that case, the developer knows what he's "touched" in the
ISR (if written in ASM) and would only bother preserving and restoring
those things that he was about to "taint".
E.g., there are ARM's that have a "FIRQ (Fast IRQ)" capability that essentially
preserves minimal state for extremely low latency IRQ's.
>>> It could be some help but not enough to justify the extra silicon &
>>> complexity
>>> I believe.
>>
>> The silicon is trivial: each load of a register (or register in a register
>> file) forces a corresponding bit to be set in a collection of flags.
>>
>> Then, a new "PUSH <vector>" opcode simply uses that "collection of
>> flags" as
>> the <vector>.
>
> This sounds simple enough indeed, push the register list along with
> the list descriptor, then use it to restore the list. But you will
> still have to calculate the length you allocated to save the list
> and this variable length might complicate the scheduler enough to
> cancel the benefits if not worse... hard to say by just hypothesizing.
The CPU vendor knows how many registers he has in the core.
So, if he knows that registers 1, 2 and 12 need to be saved
(by this magical "PUSH <vector>" instruction, he could save
r1 to WORKSPACE+1, r2 to WORKSPACE+2 and r12 to WORKSPACE+12
where WORKSPACE is a particular register/address.
I.e., the 99k implemented all registers in main memory. So, when
you accessed r1, you were really accessing the contents of memory
at WORKSPACE_POINTER+(1*register_size). Shifting r1 left resulted
in a read of that memory location into the CPU, a left ship in the
ALU and a write *back* to that location of the updated datum.
Imagine, instead, caching all of those operations in an internal
register file (gee, what a novel idea! :> ) and, only flushing
the contents of ALTERED registers back into main memory (at locations
relative to the WORKSPACE_POINTER) when a task switch was needed.
[I.e., on the 99k, to do a context switch, you just changed one
register -- the workspace pointer -- as the context was already *in*
memory!]
>> If you had to "manually" examine the flags (bits) in that vector and
>> conditionally save/restore registers, the overhead of doing so wouldn't
>> offset the cost of just unconditionally performing the save/restore.
>>
>> In essence, this is what I do with my handling of the FPU context (see
>> other
>> post). I assume the FPU registers are NOT used and let the processor
>> (in the NS32k example) tell me when a floating point instruction is invoked
>> (the FPU is an optional component in the early NS32k systems; if it is NOT
>> present, the opcodes are implemented by traps to user-supplied emulation
>> functions) by invoking a TRAP handler.
>
> I am even more cheeky than that on power for DPS. A task _must_ have
> declared it will use the FPU if it will use it, this means it gets its
> FPU context preserved, entirely. All 32 FP regs + fpscr etc. thing.
> If not, the task just won't know what the state of the FPU is; I can
> make it trap (a bit in the MCR) or leave it unknown (not sure which
> I do, trying to use the FPU when not explicitly enabled is a programming
> error). Quite often when I need the FPU for just a function and do not
> know whether the calling task will have the FPU enabled or not at
> the beginning the function saves the FPU on/off state, switches
> it "on", does its job then restores the former state.
I did this in my first implementation. But, that meant having a handler
for those cases where someone screwed up the configuration of the task
and forgot to indicate that it needed the FPU. Runtime might not see
a task run that portion of its code so you might not see a "crash and burn"
(until thorough testing).
So, if you have to handle the case where the task hasn't been configured
to use the FPU and it *does*, then why not let that handler just "handle
the FPU's usage" without forcing the developer to make that configuration
choice?
You can create "FCB's" (FPU Control Blocks) to store FPU state and reference
them *from* each task's TCB (so they are a part of that task's "state").
This also lets the FPU-handler keep a pointer to the FCB into which the
current FPU's hardware should be (eventually) saved -- *if* that need arises.
If the current task executes a FP opcode before the FPU state has been
preserved, then the old task's FPU state can be saved the TCB for the
current task lets you chase down the FCB for the current task so it's
previous FPU state can be restored before the floating point operation is
allowed to continue (restart).
Its damn near impossible to come up with a winning strategy without an
understanding of the application and the deployment environment. Where
are the *effective* resource shortages?
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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