Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30744 > unrolled thread
| Started by | pozz <pozzugno@gmail.com> |
|---|---|
| First post | 2021-07-29 18:22 +0200 |
| Last post | 2021-08-05 04:59 -0700 |
| Articles | 3 on this page of 43 — 5 participants |
Back to article view | Back to comp.arch.embedded
Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-07-29 18:22 +0200
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-07-29 19:36 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-02 17:56 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-03 11:43 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 02:28 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 22:14 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:43 -0700
Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-03 11:49 +0200
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 20:17 -0700
Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-04 16:43 +0200
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 11:06 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 12:00 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:54 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 20:00 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 10:50 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 21:50 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:46 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:43 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 06:16 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 18:39 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 01:09 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-06 22:58 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:04 -0700
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:06 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:20 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:26 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:46 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 15:14 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:09 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 08:09 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 19:50 +0300
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:02 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:34 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 21:10 +0300
Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-06 22:55 -0400
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 13:40 +0300
Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-08 18:34 -0400
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 10:50 +0300
Re: Stack analysis tool that really work? Paul Rubin <no.email@nospam.invalid> - 2021-08-09 11:26 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 22:59 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-09 12:04 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:18 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:59 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2021-08-09 12:04 -0700 |
| Message-ID | <seru91$unc$1@dont-email.me> |
| In reply to | #30783 |
On 8/9/2021 12:50 AM, Niklas Holsti wrote:
> If you are not satisfied with Don's approach (extreme over-provision of
> processor power)
It's not necessarily "extreme". I only grossly underestimate the processor's
ability to do the "must do" aspects of the design. This ensures that they
actually *will* get done.
And, what's *left* will likely exceed the needs of what I'd *like* to (also)
get done -- but, as that is (by definition) not a "must do" aspect of the
design, there are no criteria as to HOW MUCH must get done (including
"none" and "all")
In my world, I can defer execution of some tasks, *move* tasks from an
overburdened processor to a less-burdened one, *add* physical processors
to the mix (on demand), etc.
So, trying to match (at design time) the load to the capabilities is
neither necessary nor desireable/economical.
There's no (a priori) "hard limit" on the number/types of applications that
you can run on your PC, is there? Instead, you dynamically review the
performance you are experiencing and adjust your expectations, accordingly.
Maybe kill off some application that isn't *as* useful to you (at the
moment) as some other. Or, defer invoking an application until some
*other* has exceeded its utility.
You could, of course, just buy a bigger/faster PC! Yet, you don't (up
to a point). Because that changes the economics of the solution.
And, because you can "make do" with your current investment just by
more intelligently scheduling its use!
By minimizing the "must do" aspect of the problem, you give yourself
the most flexibility in how you address that/those requirements.
The rest is "free", figuratively speaking.
For example, one of my applications handles telephony. It screens
incoming callers, does speaker identification ("who is calling"),
etc. To train the recognizer, I have it "listen in" on every call
given that it now KNOWS who I am talking with and can extract/update
speech parameters from the additional "training material" that is
present, FOR FREE, in the ongoing conversation. (instead of explicitly
requiring callers to "train" the recognizer in a "training session")
But, there's no reason that this has to happen:
- in real time
- while the conversation is in progress
- anytime "soon"
So, if you *record* the conversation (relatively inexpensive as you
are already moving the audio through the processor), you can pick
some *later* time to run the model update task. Maybe in the middle
of the night when there are less demands (i.e., no one telephoning
you at 3AM!)
And, if something happens to "come up" that is more important than
this activity, you can checkpoint the operation, kill off the process
and let the more important activity have access to those resources.
Yes, it would be a much simpler design if you could just say:
"I *need* the following resources to be able to update the
recognizer models AS THE CONVERSATION WAS HAPPENING". But,
when the conversation was *over*, you'd have all those extra
re$ource$ sitting idle.
Turn "hard" requirements into *soft* ones -- and then shift them,
in time, to periods of lower resource utilization.
[The "hard real-time is hard but soft real-time is HARDER" idiom]
> you could try the hybrid WCET-estimation tools (RapiTime or
> TimeWeaver) which do not need to model the processors, but need to measure
> fine-grained execution times (on the basic-block level). The problem with such
> tools is that they cannot guarantee to produce an upper bound on the WCET, only
> a bound that holds with high probability. And, AIUI, at present that
> probability cannot be computed, and certainly depends on the test suite being
> measured. For example, on whether those tests lead to mispredictions in chains
> of conditional branches.
The equivalent mechanism in my world is monitoring *actual* load.
As it increases, you have a mismatch between needs and capabilities.
So, adjust one, the other, or both!
Shed load (remove processes from the current node)
and/or
Add capacity (*move* process to another node, including bringing
that other node "on-line" to handle the load!)
If you keep in mind the fact that you only have to deal with
the MUST DO tasks, this is a lot easier to wrap your head
around. E.g., eventually, there *will* be a situation where
what you *want* to do exceeds the capabilities that you
have available -- period. So, you have to remember that only
some of those are MUST DOs.
Yeah, it would be nice to have 3000 applications loaded and ready
at a mouse-click... but, that wouldn't be worth the cost of
the system required to support it!
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2021-08-05 13:18 +0300 |
| Message-ID | <in1s7sFbkaoU1@mid.individual.net> |
| In reply to | #30753 |
On 2021-08-04 20:50, Don Y wrote: > On 8/4/2021 10:00 AM, Niklas Holsti wrote: >> On 2021-08-03 12:49, pozz wrote: >>> Il 03/08/2021 02:56, Don Y ha scritto: >>>> On 7/29/2021 9:22 AM, pozz wrote: >>>>> arm gcc and Cortex-Mx MCUs embedded systems. >>>>> >>>>> Is there a compilation-time (static) tool for stack analysis that >>>>> really works? >>>> >>>> What do you mean by "really works"? It's a (potentially) unbounded >>>> problem as the compiler can't know what the inputs will drive the >>>> code to do, in practice. >>> >>> I mean a simple tool that can be instructed, even manually, to >>> produce a good result. >>> >>> -fstack-usage is not usable "by hands". >>> >>> You need at least a call-graph (generated by a tool), fill each >>> branch (function) with a stack usage (generated by the compiler), >>> fill every branch that is not known at compilation time by the tools >>> (call functions by pointers, recursive, and so on). >>> >>> It's surprisingly to me there isn't a single non-expensive tool that >>> helps in this, considering there are a multitude of good free tools >>> for developers. >> >> >> One reason is that for good results, such a tool has to analyze the >> executable code, and therefore must be target-specific, or at least >> have ports to the various targets, increasing the effort to implement >> and maintain the tool. The gnatstack tool gets around that, to some >> extent, by relying on stack-usage and call information from the >> compiler (gcc). > > I am seeing an increasing number of tools relying on intermediate > encodings (e.g., via LLVM) to give more portability to their > application. LLVM IR and other similar program representations are a good "level" for some semantic analyses, such as value analysis (finding possible ranges of variable values) and control-flow analysis. But it is typically too high a level for analysing machine resources such as stack usage and WCET. If one can set up a reliable mapping between the IR entities (variables and control flow) and the machine-level entities (registers, memory locations, branch instructions) the two levels of analysis can support each other. Unfortunately that mapping is defined by the compiler and linker and is usually described only incompletely in the debugging information emitted from the compiler and linker.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2021-08-05 04:59 -0700 |
| Message-ID | <segjri$hre$1@dont-email.me> |
| In reply to | #30760 |
On 8/5/2021 3:18 AM, Niklas Holsti wrote: > On 2021-08-04 20:50, Don Y wrote: >> On 8/4/2021 10:00 AM, Niklas Holsti wrote: >>> On 2021-08-03 12:49, pozz wrote: >>>> Il 03/08/2021 02:56, Don Y ha scritto: >>>>> On 7/29/2021 9:22 AM, pozz wrote: >>>>>> arm gcc and Cortex-Mx MCUs embedded systems. >>>>>> >>>>>> Is there a compilation-time (static) tool for stack analysis that >>>>>> really works? >>>>> >>>>> What do you mean by "really works"? It's a (potentially) unbounded >>>>> problem as the compiler can't know what the inputs will drive the >>>>> code to do, in practice. >>>> >>>> I mean a simple tool that can be instructed, even manually, to >>>> produce a good result. >>>> >>>> -fstack-usage is not usable "by hands". >>>> >>>> You need at least a call-graph (generated by a tool), fill each >>>> branch (function) with a stack usage (generated by the compiler), >>>> fill every branch that is not known at compilation time by the tools >>>> (call functions by pointers, recursive, and so on). >>>> >>>> It's surprisingly to me there isn't a single non-expensive tool that >>>> helps in this, considering there are a multitude of good free tools >>>> for developers. >>> >>> >>> One reason is that for good results, such a tool has to analyze the >>> executable code, and therefore must be target-specific, or at least have >>> ports to the various targets, increasing the effort to implement and >>> maintain the tool. The gnatstack tool gets around that, to some extent, by >>> relying on stack-usage and call information from the compiler (gcc). >> >> I am seeing an increasing number of tools relying on intermediate >> encodings (e.g., via LLVM) to give more portability to their >> application. > > LLVM IR and other similar program representations are a good "level" for some > semantic analyses, such as value analysis (finding possible ranges of variable > values) and control-flow analysis. Yes. I use such tools for automatically determining test coverage conditions. "Look at my code and figure out the inputs necessary to 'go everywhere'". > But it is typically too high a level for > analysing machine resources such as stack usage and WCET. Timing, agreed. But, I suspect there might be a way to add hooks to the analysis that "expose" the current SP to each function -- and then extract that. (I've not thought about it beyond conceptually; the tool WILL visit each variant of function invocation so if it can be coerced to take note of SP then it would simply be a matter of looking for max() -- and, it would be able to tell you *how* it got to that point!) > If one can set up a reliable mapping between the IR entities (variables and > control flow) and the machine-level entities (registers, memory locations, > branch instructions) the two levels of analysis can support each other. > Unfortunately that mapping is defined by the compiler and linker and is usually > described only incompletely in the debugging information emitted from the > compiler and linker.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.arch.embedded
csiph-web