On 26.1.2016 г. 03:39, Les Cargill wrote:
> Randy Yates wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> [...]
>>> The critical thing is that we continually and habitually overestimate
>>> the size of The Beast Within.
>>
>> Did you mean underestimate?
>>
>
>
> Nope. Generally things are simpler than we think they are.
>

I think I agree with that. Much of my time when programming goes into
forecasting what will be useful in the future and how things are
expected to evolve... Which is not a complex task, it is just one
I try to solve based on insufficient knowledge at the moment.
I must say I have done pretty well last 20+ years though, I have
thrown away very little code and had to rewrite almost nothing
(while almost everything I wrote is still heavily in use in the
DPS environment).
But looking back it looks just bulky, not too complex. Well,
most of it.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Randy Yates wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>> The critical thing is that we continually and habitually overestimate
>> the size of The Beast Within.
>
> Did you mean underestimate?
>


Nope. Generally things are simpler than we think they are.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> [...]
> The critical thing is that we continually and habitually overestimate
> the size of The Beast Within. 

Did you mean underestimate?
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

Tom Gardner wrote:
> On 24/01/16 17:03, Les Cargill wrote:
>> Tom Gardner wrote:
>>> On 23/01/16 04:41, Les Cargill wrote:
>>>> Tom Gardner wrote:
>>>>> On 22/01/16 03:12, Les Cargill wrote:
>>>> <snip>
>>>>>> I just reject the general ... nihilism of most of the discourse on
>>>>>> the
>>>>>> subject.
>>>>>
>>>>> I reject panglossian optimism in favour of realistic objectives.
>>>>>
>>>>
>>>>
>>>> Let me rephrase, Tom. ( how critical is that comma? )
>>>>
>>>> I think (still) after 30 years, that we still have to try. You won't
>>>> get 'em all. Doesn't matter.
>>>>
>>>> The critical thing is that we continually and habitually overestimate
>>>> the size of The Beast Within. If you can hold all the interruptions
>>>> off for...  half a day, half a week, half a month, you can get well
>>>> into the
>>>> belly of it.
>>>>
>>>> it may matter; it may not matter. Here is to those times
>>>> when it does.
>>>
>>> And there we are in violent agreement.
>>>
>>> In particular, we strongly believe the FSM specification
>>> and implementation techniques are extremely valuable and
>>> still offer the best mechanisms for producing reliable
>>> hardware and software. (Of course other techniques are
>>> beneficially applied in addition to those techniques)
>>>
>>> The only difference is the extent to which proof
>>> is practical - but that doesn't *reduce* the benefits,
>>> it merely puts an *upper limit* on them.
>>>
>>>
>>
>> YES! And I am here to testify that there's a ... happy
>> valley where you get much gain for less than overwhelming
>> effort in moving that way.
>
> Yup. And eventually I've occasionally been able to
> force other people to see that too.
>
>
>> The rest is an economic calculation, sadly.
>>
>> In a world where firmware is starting to heat up
>> politically ( the VW mess is merely the opening
>> salvo ) I think it behooves us to gird our loins a bit.
>
> I've been thinking that for decades :(
>
> It will only change when
>    - manufacturers are forced to be responsible for
>      the /consequences/ of misdesign


That will probably be a "meteor event". IOW, no more manufacturers
that are not also humongous insurance companies.

>    - insurance premiums are dependent on properly
>      designed equipment
>
>

But the show business of certification probably means that's nearly
impossible.

>>> (I'm still mildly pleased that when I and another
>>> schoolboy implemented programs for converting from
>>> one 5-channel paper tape format to another, my program
>>> worked first time and his never did. My program
>>> was ~80 words (160 instructions) long and my first
>>> assembler program, his was enormous. I later found
>>> out I had reinvented a simple FSM with two states:
>>> figure-shift and letter-shift.)
>>
>> There you go. Unfortunately, our education system
>> doesn't seem to teach that as much as it does declarative
>> logic; at least not in CS.
>
> Oh, we weren't taught that! It was entirely extra-curricular.

I was  - a little bit - but the dept. chairman was an
applied mathematician with a background in EE.

> Mind you, everybody in my school was taught integration
> and differentiation of polynomials (except 1/x) for external
> exams (O-levels) at 15yo/year10 (yes, one year early).
> Nowadays maths teachers have difficulty believing that.
>

 From what I've seen, even chemistry calculations at
the undergrad level involve calculus ( which is much
easier, IMO), so there's hope.

-- 
Les Cargill

On 24/01/16 17:03, Les Cargill wrote:
> Tom Gardner wrote:
>> On 23/01/16 04:41, Les Cargill wrote:
>>> Tom Gardner wrote:
>>>> On 22/01/16 03:12, Les Cargill wrote:
>>> <snip>
>>>>> I just reject the general ... nihilism of most of the discourse on the
>>>>> subject.
>>>>
>>>> I reject panglossian optimism in favour of realistic objectives.
>>>>
>>>
>>>
>>> Let me rephrase, Tom. ( how critical is that comma? )
>>>
>>> I think (still) after 30 years, that we still have to try. You won't
>>> get 'em all. Doesn't matter.
>>>
>>> The critical thing is that we continually and habitually overestimate
>>> the size of The Beast Within. If you can hold all the interruptions
>>> off for...  half a day, half a week, half a month, you can get well
>>> into the
>>> belly of it.
>>>
>>> it may matter; it may not matter. Here is to those times
>>> when it does.
>>
>> And there we are in violent agreement.
>>
>> In particular, we strongly believe the FSM specification
>> and implementation techniques are extremely valuable and
>> still offer the best mechanisms for producing reliable
>> hardware and software. (Of course other techniques are
>> beneficially applied in addition to those techniques)
>>
>> The only difference is the extent to which proof
>> is practical - but that doesn't *reduce* the benefits,
>> it merely puts an *upper limit* on them.
>>
>>
>
> YES! And I am here to testify that there's a ... happy
> valley where you get much gain for less than overwhelming
> effort in moving that way.

Yup. And eventually I've occasionally been able to
force other people to see that too.


> The rest is an economic calculation, sadly.
>
> In a world where firmware is starting to heat up
> politically ( the VW mess is merely the opening
> salvo ) I think it behooves us to gird our loins a bit.

I've been thinking that for decades :(

It will only change when
   - manufacturers are forced to be responsible for
     the /consequences/ of misdesign
   - insurance premiums are dependent on properly
     designed equipment


>> (I'm still mildly pleased that when I and another
>> schoolboy implemented programs for converting from
>> one 5-channel paper tape format to another, my program
>> worked first time and his never did. My program
>> was ~80 words (160 instructions) long and my first
>> assembler program, his was enormous. I later found
>> out I had reinvented a simple FSM with two states:
>> figure-shift and letter-shift.)
>
> There you go. Unfortunately, our education system
> doesn't seem to teach that as much as it does declarative
> logic; at least not in CS.

Oh, we weren't taught that! It was entirely extra-curricular.
Mind you, everybody in my school was taught integration
and differentiation of polynomials (except 1/x) for external
exams (O-levels) at 15yo/year10 (yes, one year early).
Nowadays maths teachers have difficulty believing that.

Tom Gardner wrote:
> On 23/01/16 04:41, Les Cargill wrote:
>> Tom Gardner wrote:
>>> On 22/01/16 03:12, Les Cargill wrote:
>> <snip>
>>>> I just reject the general ... nihilism of most of the discourse on the
>>>> subject.
>>>
>>> I reject panglossian optimism in favour of realistic objectives.
>>>
>>
>>
>> Let me rephrase, Tom. ( how critical is that comma? )
>>
>> I think (still) after 30 years, that we still have to try. You won't
>> get 'em all. Doesn't matter.
>>
>> The critical thing is that we continually and habitually overestimate
>> the size of The Beast Within. If you can hold all the interruptions
>> off for...  half a day, half a week, half a month, you can get well
>> into the
>> belly of it.
>>
>> it may matter; it may not matter. Here is to those times
>> when it does.
>
> And there we are in violent agreement.
>
> In particular, we strongly believe the FSM specification
> and implementation techniques are extremely valuable and
> still offer the best mechanisms for producing reliable
> hardware and software. (Of course other techniques are
> beneficially applied in addition to those techniques)
>
> The only difference is the extent to which proof
> is practical - but that doesn't *reduce* the benefits,
> it merely puts an *upper limit* on them.
>
>

YES! And I am here to testify that there's a ... happy
valley where you get much gain for less than overwhelming
effort in moving that way.

The rest is an economic calculation, sadly.

In a world where firmware is starting to heat up
politically ( the VW mess is merely the opening
salvo ) I think it behooves us to gird our loins a bit.

> (I'm still mildly pleased that when I and another
> schoolboy implemented programs for converting from
> one 5-channel paper tape format to another, my program
> worked first time and his never did. My program
> was ~80 words (160 instructions) long and my first
> assembler program, his was enormous. I later found
> out I had reinvented a simple FSM with two states:
> figure-shift and letter-shift.)


There you go. Unfortunately, our education system
doesn't seem to teach that as much as it does declarative
logic; at least not in CS.

-- 
Les Cargill

On 23/01/16 04:41, Les Cargill wrote:
> Tom Gardner wrote:
>> On 22/01/16 03:12, Les Cargill wrote:
> <snip>
>>> I just reject the general ... nihilism of most of the discourse on the
>>> subject.
>>
>> I reject panglossian optimism in favour of realistic objectives.
>>
>
>
> Let me rephrase, Tom. ( how critical is that comma? )
>
> I think (still) after 30 years, that we still have to try. You won't
> get 'em all. Doesn't matter.
>
> The critical thing is that we continually and habitually overestimate
> the size of The Beast Within. If you can hold all the interruptions
> off for...  half a day, half a week, half a month, you can get well into the
> belly of it.
>
> it may matter; it may not matter. Here is to those times
> when it does.

And there we are in violent agreement.

In particular, we strongly believe the FSM specification
and implementation techniques are extremely valuable and
still offer the best mechanisms for producing reliable
hardware and software. (Of course other techniques are
beneficially applied in addition to those techniques)

The only difference is the extent to which proof
is practical - but that doesn't *reduce* the benefits,
it merely puts an *upper limit* on them.


(I'm still mildly pleased that when I and another
schoolboy implemented programs for converting from
one 5-channel paper tape format to another, my program
worked first time and his never did. My program
was ~80 words (160 instructions) long and my first
assembler program, his was enormous. I later found
out I had reinvented a simple FSM with two states:
figure-shift and letter-shift.)

Les Cargill <lcargill99@comcast.com> writes:
> Much depends on properly generating the suite of permutations.

Sometimes you can prune the state space with formal or automated
reasoning.

   https://github.com/tomahawkins/improve/wiki/ImProve

might be of interest.  It's a DSL which uses an SMT solver to check the
invariants.  A walkthrough of a simple example is here:

  https://github.com/tomahawkins/improve/wiki/Verification-Primer

The ImProve compiler turns the ImProve input into C, Ada, or Simulink.
I haven't used it but I've played with the related Atom DSL by the same
guy.  It's pretty cool.

Tom Gardner wrote:
> On 22/01/16 03:12, Les Cargill wrote:
<snip>
>> I just reject the general ... nihilism of most of the discourse on the
>> subject.
>
> I reject panglossian optimism in favour of realistic objectives.
>


Let me rephrase, Tom. ( how critical is that comma? )

I think (still) after 30 years, that we still have to try. You won't
get 'em all. Doesn't matter.

The critical thing is that we continually and habitually overestimate
the size of The Beast Within. If you can hold all the interruptions
off for...  half a day, half a week, half a month, you can get well into 
the belly of it.

it may matter; it may not matter. Here is to those times
when it does.

-- 
Les Cargill

Tom Gardner wrote:
> On 22/01/16 03:12, Les Cargill wrote:
>> Tom Gardner wrote:
>>> On 21/01/16 06:29, Les Cargill wrote:
>>>> Randy Yates wrote:
>>>>> Les Cargill <lcargill99@comcast.com> writes:
>>>>>
>>>>>> Randy Yates wrote:
>>>>>>> Les Cargill <lcargill99@comcast.com> writes:
>>>>>>>> [...]
>>>>>>>> Preemptive opens up a lot of disparate and ugly cans of worms. With
>>>>>>>> "run to completion". you can get a lot closer to proving the system
>>>>>>>> correct to within some epsilon ( sometimes a rather large
>>>>>>>> epsilon ).
>>>>>>>
>>>>>>> That sounds bogus. Whether 100 lines of "preemptive" or 100 lines
>>>>>>> of "run to completion," you can have a LOT of bugs.
>>>>>>>
>>>>>>
>>>>>> Of course you can.  But with preemption, you get Heisenbugs of a
>>>>>> certain sort, thread-safe issues, reentrancy and race conditions
>>>>>> of another certain sort.
>>>>>>
>>>>>> Of course, you gain habits in how to avoid these, but still...
>>>>>>
>>>>>> I just really prefer deterministic operation of
>>>>>> systems. And, frankly, I don't understand other people not
>>>>>> preferring that. I fully realize you can't always do that, but
>>>>>> I bet you can get closer than you think you can.
>>>>>>
>>>>>>> I would much, much, MUCH (did I say much?) rather use a
>>>>>>> preemptive OS.
>>>>>>> You can always make it a "run to completion" by placing all tasks
>>>>>>> at the
>>>>>>> same priority and ensuring nothing blocks in the body of each task
>>>>>>> (except at the end, e.g., a yield()).
>>>>>>
>>>>>>
>>>>>> I do, generally, or I make it message passing, or
>>>>>> interlocking state machines with message passing...
>>>>>
>>>>> Well we may be in violent agreement after all.
>>>>
>>>> I am sure we are.
>>>>
>>>>> I've based a few of my
>>>>> threaded projects on the paradigm of doing everything through messages
>>>>> and blocking (for the most part) on a message being available. Works
>>>>> beautifully.
>>>>>
>>>>
>>>> Badda bing, badda boom.
>>>>
>>>>>> Here's the key - it's now possible to reason about these systems in a
>>>>>> proof-like manner. You can enumerate all the states cross events and
>>>>>> check lists of invariants at each transition.
>>>>>
>>>>> What do you mean by "invariants?" This paragraph is Greek to me.
>>>>>
>>>>
>>>> An invariant is something that is always true.
>>>>
>>>> For state machines, you can check sets of true/false tests based
>>>> on state and learn an awful lot about whether the thing works or not.
>>>
>>> There is a large difference between "proof" and "increased
>>> confidence".
>>>
>>> While explicit FSMs are almost /necessary/ for analysis
>>> and *proof*, they aren't /sufficient/ for many real systems.
>>>
>>> The state space explosion rapidly becomes intractable when
>>> all possible sequences of events is considered.
>>>
>>
>> The point is to constrain that space. The actual problem is the driver
>> for any such explosion; we're just managing it.
>>
>> As a practical matter, I have not seen too many problems where state
>> space
>> explosion was a practical limitation.
>>
>> The "all possible sequences of events" thing is slightly red-herring;
>> I've not seen too many cases where it was impossible to control this.
>>
>> Events tend to be pretty orthogonal. If they're not, make 'em
>> orthogonal.
>
> When the events and states are defined by standards bodies
> you don't have that option. Doubly so if the standards are
> rationalisations of what's found in existing manufacturers'
> equipment.
>
> That's the case for telecom and networking standards, and
> I'm sure many other examples.
>
>

You are 100% correct in that - although in the limited case I'm
aware of, the number of events & states are low.

>>> Nonetheless FSMs are highly beneficial and the best known
>>> technique for the reasons you and I have previously agreed.
>>>
>>>
>>>>>> So what if it's big? Sure, you'll make mistakes but if
>>>>>> you keep this as a regression check, I bet it's worth it.
>>>>>> You can get a long way with < 100 states and < 12 events, well,
>>>>>> that's 1200 things. Not impossible at all.
>>>>>
>>>>> Don't get me wrong, I believe any testing is good; very good. But just
>>>>> testing across states and events doesn't give you a lot of coverage,
>>>>> does it?
>>>>
>>>> Sure it does. Done properly, it can reduce error rates
>>>> dramatically. But this is somehow easier if things
>>>> are, more or less,  a state machine.
>>>>
>>>> Again, I think of these things as a fancy regulator clock, with
>>>> complicated escapement mechanisms.
>>>>
>>>> If it's permutation oriented, we're programmers. We know how
>>>> to automate generating permutations. If it's uncomfortable
>>>> running this on the target, hoist it out to a PC program
>>>> and run it against the test vector that way.
>>>>
>>>> You still have to do things like worst-case, stress and illegal
>>>> input tests. And you'll still miss stuff.
>>>>
>>>> I'd rather slip a week doing this than spend months going through
>>>> wreckage. And
>>>> frankly, those approach feels more productive to me.
>>>>
>>>>> What about the order and timing of the events and inputs?
>>>>>
>>>>
>>>> You (nearly) always have to tolerate out of order events.
>>>>
>>>> Timing should be manageable by buffering. And you do what you can
>>>> to count lost events.
>>>>
>>>> If you lose events, it might be worth considering polling, in
>>>> cases ( especially on small, high-speed micros ).
>>>
>>> Those arguments are missing the point.
>>>
>>>
>>
>> I just reject the general ... nihilism of most of the discourse on the
>> subject.
>
> I reject panglossian optimism in favour of realistic objectives.
>

I've done this very thing, so I'm hesitant to call it Panglossian...

Much depends on properly generating the suite of permutations.

-- 
Les Cargill