The blocking time analysis measures the worst case execution time of all
interrupt-locked regions. Currently, the blocking-time tool only
accounts for intruction timings without caching.

Ruby has a perfect method for fast marshaling and unmarshaling of data.
We use it to cache the loading of PML files in a .bin file. This should
improve development speed a lot.

Example usage:
 Foreach execution of irq_entry, the timer_isr function is executed
 exactly once. (E.g. to force an IRQ dispatching table)

 --entry irq_entry --add-flowfact "irq_entry : <> : timer_isr = 1"

There was a general flaw in the state->abb propagation. There were
corner cases, were an ABB was executed not often enough although the
state was visited often enough. So here is the new logic:

1) In general an ABB is executed as often as the system state is
   visited (= sum_of_incoming), BUT
   2) Interrupt Activations (=sum_of_outgoin_irq_edges) substracted, BUT
      3) Interrupt Activations with no resume are added again

There can be loops on the node level of the GCFG IPET, this would lead
to loops (mainly interrupt activation loops) that spin wildy, although
the actual path is not even activating that interrupt-state loop.
Therefore, we introduce a constraint that the frequency of all backedges
combined (B) must be zero, iff the sum of all loop entering edges (E) is
zero:

Loop constraint: B <= BIG_M * E

The timing dump function is weirdly complicated, therefore, we mask it
out to get at least some results.

How did this ever work?

This flag enables the possibility to use gurobi, if it can be found in
the path.

A ConstantProgramPoint can be used within a flow fact of any type to add
a real constant offset to some flowfact. For example, to model that a
timer can activate an alarm every third activation:

   3 * AlarmActivations - C - __const(2) <= 0

The problem with just adding a real constant to the ILP was, that the
flow fact propagation eliminated it and moved the constant to the right
side, where it was related to the entry function (of the transformed
call-graph subtree).

TLDR: We can use flow facts with constants

For old men starring at goats

Since lp_solve has some bugs, for which we need dirty workarounds, I
switched to use gurobi. Although this solver is not free ( :-( ), it at
least works.

The flow that is injected into the nodes body has to be calculated on an
ABB/function level, and not on a per-node level. This had not influence
on the results yet, but now it should be correct.

Not every node adds a flow of 1, but exactly one gcfg entry is taken.

The flowfact transformation (bitcode->machinecode) was broken due to the
changes I made for the GCFG IPET Analysis. This change adapts the flow
fact transformation for this analysis type.

We fix the IRET-return problem, by not propagating all ABB incoming
edges into the microstructure of our ABB. We use a Special order set to
separate (resumes - suspend) into a negative part (neg) and a positive
part (pos).

    (pos - neg) = (resumes - suspend);

Since [pos, neg] are in one SOS1, only one of them can be "active",
Therefore, pos is the number of additional resumes at this block, which
is added to the internal frequency of our ABB.

This new flow fact adds a constraint to the ILP, such that events can
occurs a maximal or at least a minimal time, depending on the total
length of the worst-case execution time.

Whatever, no one will ever read this message. But, probably there were
some bugfixes in it.