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

Groups > comp.arch.embedded > #26537 > unrolled thread

[OT] I got a JOB!!!

Back to article view | Back to comp.arch.embedded

Contents

  [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 13:49 -0500
    Re: [OT] I got a JOB!!! Steve Wilson <no@spam.com> - 2017-05-16 19:04 +0000
    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 12:14 -0700
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-16 14:41 -0500
        Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 14:01 -0700
          Re: [OT] I got a JOB!!! mike <ham789@netzero.net> - 2017-05-16 14:42 -0700
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 17:09 -0500
            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 16:42 -0700
          Re: [OT] I got a JOB!!! Clifford Heath <clifford.heath@gmail.com> - 2017-05-17 09:00 +1000
    Re: [OT] I got a JOB!!! eric.jacobsen@ieee.org - 2017-05-16 20:17 +0000
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-16 15:24 -0500
        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-16 22:05 +0100
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 17:11 -0500
            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-16 23:51 +0100
              Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-16 18:32 -0500
                Re: [OT] I got a JOB!!! Clifford Heath <clifford.heath@gmail.com> - 2017-05-17 09:41 +1000
                  Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:35 +0100
                    Re: [OT] I got a JOB!!! Clifford Heath <no.spam@please.net> - 2017-05-17 19:03 +1000
                      Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:31 +0100
                        Re: [OT] I got a JOB!!! Clifford Heath <no.spam@please.net> - 2017-05-17 23:07 +1000
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:41 +0100
                  Re: [OT] I got a JOB!!! Paul <paul@pcserviceselectronics.co.uk> - 2017-05-17 10:10 +0100
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:34 +0100
                      Re: [OT] I got a JOB!!! Paul <paul@pcserviceselectronics.co.uk> - 2017-05-17 15:59 +0100
                        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:04 +0100
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:02 +0100
              Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 17:56 -0700
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 09:42 +0100
                  Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 16:57 +0800
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 10:32 +0100
                      Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 18:12 +0800
                        Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 03:54 -0700
                          Re: [OT] I got a JOB!!! Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 21:57 +0800
                            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 09:36 -0700
                          Re: [OT] I got a JOB!!! Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-05-17 18:07 +0300
                            Re: [OT] I got a JOB!!! Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 10:44 -0500
                            Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 09:47 -0700
                              Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 10:18 -0700
                              Re: [OT] I got a JOB!!! Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-05-17 20:25 +0300
                                Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 12:01 -0700
                      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-17 10:25 -0500
                        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:22 +0100
                          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:36 -0500
                            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:45 +0100
                    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-17 03:42 -0700
    Re: [OT] I got a JOB!!! "billbowden" <bperryb@bowdenshobbycircuits.info> - 2017-05-16 15:04 -0700
      Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-16 15:30 -0700
    Re: [OT] I got a JOB!!! Martin Riddle <martin_ridd@verizon.net> - 2017-05-16 20:02 -0400
    Re: [OT] I got a JOB!!! krw@notreal.com - 2017-05-16 20:40 -0400
    Re: [OT] I got a JOB!!! Randy Yates <randyy@garnerundergroundinc.com> - 2017-05-17 09:12 -0400
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-17 10:02 -0500
        Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:11 +0100
          Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:21 -0500
            Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:36 +0100
              Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 12:43 -0500
                Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:55 +0100
                  Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 18:57 +0100
                  Re: [OT] I got a JOB!!! Tim Wescott <seemywebsite@myfooter.really> - 2017-05-17 13:28 -0500
                    Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-17 20:08 +0100
    Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-17 21:30 -0700
      Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-18 00:03 -0500
      Re: [OT] I got a JOB!!! Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-18 08:18 +0100
        Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-18 22:56 -0700
          Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 14:31 +0300
            Re: [OT] I got a JOB!!! Tim Wescott <tim@seemywebsite.really> - 2017-05-19 10:39 -0500
              Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 23:02 +0300
                Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-19 13:12 -0700
                  Re: [OT] I got a JOB!!! dplatt@coop.radagast.org (Dave Platt) - 2017-05-19 15:00 -0700
                    Re: [OT] I got a JOB!!! Don Y <blockedofcourse@foo.invalid> - 2017-05-19 16:05 -0700
                Re: [OT] I got a JOB!!! boB K7IQ <boB@everett.wa> - 2017-05-21 01:46 -0700
                  Re: [OT] I got a JOB!!! Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-21 17:31 +0300
                    Re: [OT] I got a JOB!!! John S <Sophi.2@invalid.org> - 2017-05-21 13:31 -0500
                    Re: [OT] I got a JOB!!! krw@notreal.com - 2017-05-21 16:47 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#26584

On Wed, 17 May 2017 10:32:59 +0100, Tom Gardner wrote:

> On 17/05/17 09:57, Reinhardt Behm wrote:
>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>
>>> On 17/05/17 01:56, Don Y wrote:
>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>> The other dysfunctional aspect of unit tests is that,
>>>>> while they are very useful when making incremental improvements
>>>>> during design, they can be a real impediment in a few months/years
>>>>> time. The problem is that over time people forget which tests
>>>>> demonstrate required properties, and which are merely ensuring
>>>>> behaviour of implementation artifacts. At that point people are
>>>>> afraid to make changes that break tests, even if the tests are
>>>>> unimportant. At that point the codebase has become ossified.
>>>>
>>>> But that's true any time you (attempt to) nail down an aspect of a
>>>> design.  Moreso if you don't provide a rationale for WHY the
>>>> requirement (whether it be from a spec or a test) was imposed.
>>>
>>> Of course. Nonetheless, it happens - and zealots sometimes refuse to
>>> admit it.
>>
>> Therefor any good development process demands that requirements
>> (high-level,
>> or low-level) must be traceable to system requirements or must be
>> marked as design decisions. Then you have the WHY.
>> A test can not be the source of a requirement. A test should also be
>> traceable to sys-reqs.
>> And hopefully the sys-reqs are good.
> 
> We are in violent agreement.
> 
> But my point is about the XP/Agile/TDD/Unit Test zealots that overstate
> the benefits of those techniques and ignore their dysfunctional aspects.

That's kind of the definition of a zealot.

Something that Reinhardt -- and I think maybe you -- are missing, is that 
part of the reason for agile is that requirements don't remain static.  
As soon as people see a something working, the requirements change -- and 
saying "no, I'm sorry person-who-signs-checks, we're going to spend the 
next year making what you asked for initially and THEN we're going to 
entertain change requests".

So you can't treat requirements as static things graved in stone.  Agile 
tries to deal with that, and as near as I can tell, only having nibbled 
at the edges of it, it does a reasonably good job of it for things that 
aren't terribly safety critical.  Agile is also new, so it's naturally 
going to attract zealots -- the trick is to see the value underneath the 
hype, and then make rational choices about what to do.

-- 
www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26594

On 17/05/17 16:25, Tim Wescott wrote:
> On Wed, 17 May 2017 10:32:59 +0100, Tom Gardner wrote:
>
>> On 17/05/17 09:57, Reinhardt Behm wrote:
>>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>>
>>>> On 17/05/17 01:56, Don Y wrote:
>>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>>> The other dysfunctional aspect of unit tests is that,
>>>>>> while they are very useful when making incremental improvements
>>>>>> during design, they can be a real impediment in a few months/years
>>>>>> time. The problem is that over time people forget which tests
>>>>>> demonstrate required properties, and which are merely ensuring
>>>>>> behaviour of implementation artifacts. At that point people are
>>>>>> afraid to make changes that break tests, even if the tests are
>>>>>> unimportant. At that point the codebase has become ossified.
>>>>>
>>>>> But that's true any time you (attempt to) nail down an aspect of a
>>>>> design.  Moreso if you don't provide a rationale for WHY the
>>>>> requirement (whether it be from a spec or a test) was imposed.
>>>>
>>>> Of course. Nonetheless, it happens - and zealots sometimes refuse to
>>>> admit it.
>>>
>>> Therefor any good development process demands that requirements
>>> (high-level,
>>> or low-level) must be traceable to system requirements or must be
>>> marked as design decisions. Then you have the WHY.
>>> A test can not be the source of a requirement. A test should also be
>>> traceable to sys-reqs.
>>> And hopefully the sys-reqs are good.
>>
>> We are in violent agreement.
>>
>> But my point is about the XP/Agile/TDD/Unit Test zealots that overstate
>> the benefits of those techniques and ignore their dysfunctional aspects.
>
> That's kind of the definition of a zealot.
>
> Something that Reinhardt -- and I think maybe you -- are missing, is that
> part of the reason for agile is that requirements don't remain static.
> As soon as people see a something working, the requirements change -- and
> saying "no, I'm sorry person-who-signs-checks, we're going to spend the
> next year making what you asked for initially and THEN we're going to
> entertain change requests".
>
> So you can't treat requirements as static things graved in stone.  Agile
> tries to deal with that, and as near as I can tell, only having nibbled
> at the edges of it, it does a reasonably good job of it for things that
> aren't terribly safety critical.  Agile is also new, so it's naturally
> going to attract zealots -- the trick is to see the value underneath the
> hype, and then make rational choices about what to do.

I understand and agree with all of that.

I once pushed for agile practices to be introduced into a
company for those reasons. I then saw the newly-trained
staff think it was a good idea to delete /all/ comments on
the religious principle that comments are bad because they
get out of sync with the code. They also changed private
functions and data to public so that they could be seen
by their unit tests - thereby encouraging future developers
to /misuse/ the classes in ways that are easily avoidable.

That doesn't mean agile is bad (it isn't!), only that
/unthinkingly/ following a process is bad.

[toc] | [prev] | [next] | [standalone]

#26597

On Wed, 17 May 2017 18:22:16 +0100, Tom Gardner wrote:

> On 17/05/17 16:25, Tim Wescott wrote:
>> On Wed, 17 May 2017 10:32:59 +0100, Tom Gardner wrote:
>>
>>> On 17/05/17 09:57, Reinhardt Behm wrote:
>>>> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>>>>
>>>>> On 17/05/17 01:56, Don Y wrote:
>>>>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>>>>> The other dysfunctional aspect of unit tests is that,
>>>>>>> while they are very useful when making incremental improvements
>>>>>>> during design, they can be a real impediment in a few months/years
>>>>>>> time. The problem is that over time people forget which tests
>>>>>>> demonstrate required properties, and which are merely ensuring
>>>>>>> behaviour of implementation artifacts. At that point people are
>>>>>>> afraid to make changes that break tests, even if the tests are
>>>>>>> unimportant. At that point the codebase has become ossified.
>>>>>>
>>>>>> But that's true any time you (attempt to) nail down an aspect of a
>>>>>> design.  Moreso if you don't provide a rationale for WHY the
>>>>>> requirement (whether it be from a spec or a test) was imposed.
>>>>>
>>>>> Of course. Nonetheless, it happens - and zealots sometimes refuse to
>>>>> admit it.
>>>>
>>>> Therefor any good development process demands that requirements
>>>> (high-level,
>>>> or low-level) must be traceable to system requirements or must be
>>>> marked as design decisions. Then you have the WHY.
>>>> A test can not be the source of a requirement. A test should also be
>>>> traceable to sys-reqs.
>>>> And hopefully the sys-reqs are good.
>>>
>>> We are in violent agreement.
>>>
>>> But my point is about the XP/Agile/TDD/Unit Test zealots that
>>> overstate the benefits of those techniques and ignore their
>>> dysfunctional aspects.
>>
>> That's kind of the definition of a zealot.
>>
>> Something that Reinhardt -- and I think maybe you -- are missing, is
>> that part of the reason for agile is that requirements don't remain
>> static. As soon as people see a something working, the requirements
>> change -- and saying "no, I'm sorry person-who-signs-checks, we're
>> going to spend the next year making what you asked for initially and
>> THEN we're going to entertain change requests".
>>
>> So you can't treat requirements as static things graved in stone. 
>> Agile tries to deal with that, and as near as I can tell, only having
>> nibbled at the edges of it, it does a reasonably good job of it for
>> things that aren't terribly safety critical.  Agile is also new, so
>> it's naturally going to attract zealots -- the trick is to see the
>> value underneath the hype, and then make rational choices about what to
>> do.
> 
> I understand and agree with all of that.
> 
> I once pushed for agile practices to be introduced into a company for
> those reasons. I then saw the newly-trained staff think it was a good
> idea to delete /all/ comments on the religious principle that comments
> are bad because they get out of sync with the code. They also changed
> private functions and data to public so that they could be seen by their
> unit tests - thereby encouraging future developers to /misuse/ the
> classes in ways that are easily avoidable.
> 
> That doesn't mean agile is bad (it isn't!), only that /unthinkingly/
> following a process is bad.

Unthinkingly following any process is bad.  Refusing to follow any 
process at all is bad*.  Trying to apply a process to the wrong 
situation** is bad.  I've seen it go down all these ways.  It was bad 
every time.

I need to find out what makes good practice vis-a-vis hiding functions 
for unit tests.  One way or another the answer has to be that the 
functions STAY hidden for higher-level "production" code -- whether this 
means that class foo has a "friend class testFoo" in it, or if it means 
that you have a #define TEST_CLASS_FOO, or if there's something yet again 
-- I don't know.

* This can be ameliorated in a group environment by identifying the 
people who are cranky about the process because of honestly perceived 
faults, and inviting them to the Dark Side -- uh, to the process steering 
committee meetings.  They end up understanding the underlying reasons, or 
better, making the process better.  The people who just want to be 
cowboys are generally either poor programmers in general, or are good 
programmers if they're put into an organization small enough to not need 
written process.

** A friend of mine used to own a company that built card-swipe machines, 
when they were first coming out.  He got bought by a banking company, and 
had buckets of entertainment when their IT department got wind of Someone 
Writing Software that We Don't Control and tried to impose the coding 
standard on him.  The punchline was pointing at the 8051 on the circuit 
board and saying "where do I get a COBOL compiler for that?"

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26600

On 17/05/17 18:36, Tim Wescott wrote:
> On Wed, 17 May 2017 18:22:16 +0100, Tom Gardner wrote:
>> I once pushed for agile practices to be introduced into a company for
>> those reasons. I then saw the newly-trained staff think it was a good
>> idea to delete /all/ comments on the religious principle that comments
>> are bad because they get out of sync with the code. They also changed
>> private functions and data to public so that they could be seen by their
>> unit tests - thereby encouraging future developers to /misuse/ the
>> classes in ways that are easily avoidable.
>>
>> That doesn't mean agile is bad (it isn't!), only that /unthinkingly/
>> following a process is bad.
>
> Unthinkingly following any process is bad.  Refusing to follow any
> process at all is bad*.  Trying to apply a process to the wrong
> situation** is bad.  I've seen it go down all these ways.  It was bad
> every time.

Yes indeed.


> I need to find out what makes good practice vis-a-vis hiding functions
> for unit tests.  One way or another the answer has to be that the
> functions STAY hidden for higher-level "production" code -- whether this
> means that class foo has a "friend class testFoo" in it, or if it means
> that you have a #define TEST_CLASS_FOO, or if there's something yet again
> -- I don't know.

I don't know for C++; I hate the language and have managed
to avoid using it in anger. I'm sure there are some "design
patterns" of accepted practice around for you to find.
Probably too many, so you'll have to spend time discovering
the disadvantages that their proponents don't mention.

Java, and I expect C#, is probably more flexible since there
are many dangerously powerful tools available. Think reflection,
and proceed from there.

[toc] | [prev] | [next] | [standalone]

#26572

On 5/17/2017 1:57 AM, Reinhardt Behm wrote:
> AT Wednesday 17 May 2017 16:42, Tom Gardner wrote:
>
>> On 17/05/17 01:56, Don Y wrote:
>>> On 5/16/2017 3:51 PM, Tom Gardner wrote:
>>>> The other dysfunctional aspect of unit tests is that,
>>>> while they are very useful when making incremental
>>>> improvements during design, they can be a real
>>>> impediment in a few months/years time. The problem is
>>>> that over time people forget which tests demonstrate
>>>> required properties, and which are merely ensuring
>>>> behaviour of implementation artifacts. At that point
>>>> people are afraid to make changes that break tests,
>>>> even if the tests are unimportant. At that point the
>>>> codebase has become ossified.
>>>
>>> But that's true any time you (attempt to) nail down
>>> an aspect of a design.  Moreso if you don't provide a
>>> rationale for WHY the requirement (whether it be from a
>>> spec or a test) was imposed.
>>
>> Of course. Nonetheless, it happens - and zealots
>> sometimes refuse to admit it.
>
> Therefor any good development process demands that requirements (high-level,
> or low-level) must be traceable to system requirements or must be marked as
> design decisions. Then you have the WHY.

But if all of this is written in "legalese", you can easily end up with
a document(s) that is ambiguous -- even to the original author(s), some
time after it's been written!

[Lawyers spend a lot of time trying to write precise contracts; then
spend the rest of their time trying to pick holes/ambiguities in the
contracts written by others!]

1. A game shall consist of 3, 4 or 5 balls, adjustable by the operator.
2. At the end of the last ball, the game shall be over.
3. A free ball shall be awarded for each 10,000 points.
4. The maximum ball count shall not exceed 6.

Seems like a straight forward, terse specification.
But, it doesn't explicitly indicate that the OPERATOR is a different
entity from the PLAYER (nor does it even mention how a game is PLAYED).

Nor does it clearly indicate the sequencing of these requirements.

If configured for 5 balls and, during the play of the first ball,
the player attains a score of 22000, is he awarded *2* free balls,
one for each 10,000 point attainment?  Or, just one (because he's
already been allocated *5*)?

If you've chosen to implement a "balls remaining" counter, then
does that counter indicate "4" while the player is playing his
first ball?  So, can it be incremented to 6 by the two "free balls"
and still remain in compliance with requirement #4?

If a player achieves 10,000 points on *each* ball played, does this
mean he can essentially "play forever" -- a free ball awarded to replace
the ball he is currently playing?

Now, imagine someone tweeks the specification to incorporate a "bonus"
feature that allows points to be "banked" during play -- perhaps
spanning the play of several balls.  If the "last ball" is in play
and the current score is 9000 with an accumulated bonus of 3000,
does that ball leaving the playfield (end of play for that ball)
terminate the game before or after the bonus is awarded?  As the
score rolls past 10,000 when the bonus is awarded, is new life
breathed into the player as he is awarded a free ball *by* that
bonus award?  Or, has "play" been considered terminated BEFORE
the bonus is awarded (he gets the points but not the additional
feature of the free ball)

As systems get more complex (this was a trivial one!), it is easy
for someone tweeking a specification to lose track of the many
interdependencies/relationships between clauses.  So, the consequences
of a new requirement can be insidious.

Furthermore, the requirements can effectively *suggest* an
implementation without actually *mandating* it.  E.g., "ball count"
is easily interpreted as "ball countER", despite being different
semantic entities.

A well written spec will formally define all of these terms
AND each instance of such a term.  So, "BALL COUNT" will *not*
be assumed when reading "The display will indicate the ball count".
But, it is really hard to catch all of these details when writing
*or* (proof)reading such a document.

A more prosaic description (incl examples) can convey intent in
a conversational (instead of declarative) tone.

> A test can not be the source of a requirement. A test should also be
> traceable to sys-reqs.

Yes.

> And hopefully the sys-reqs are good.

[toc] | [prev] | [next] | [standalone]

#26547

"Tim Wescott" <seemywebsite@myfooter.really> wrote in message 
news:0cCdndKxRuwl1IbEnZ2dnUU7-bWdnZ2d@giganews.com...
> Since this is a newsgroup, and this is news...
>
> Wescott Design Services is going into remission, while I pursue a day
> job.  Job title is Software Designer 5 at Planar Systems -- so any
> circuit design or control systems jones will have to be satisfied by
> hobby work or on the side.
>
> In the near term I'll be finishing up current work with current
> customers; in the longer term I'll probably concentrate on the
> educational videos and maybe hobby stuff.
>
> Lots of embedded Linux work in my near future, and possibly TDD
> proselytizing.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> I'm looking for work -- see my website!

Good luck. I don't have any job and got a traffic ticket for $238 plus $54 
to attend traffic school. I plan to fight the case since the signs are not 
properly posted. If I lose, I will ask for community service and tell the 
court I have no money and would like to pick up trash on the roads. The city 
pays $10 an hour for picking up trash. Or, I might get an easier job working 
in a senior centor. Time will tell. I made an illegal left turn where the 
signs are hard to see. There is a picture here::

https://ibb.co/jUv3t5

.

[toc] | [prev] | [next] | [standalone]

#26550

On 5/16/2017 3:04 PM, billbowden wrote:
> Good luck. I don't have any job and got a traffic ticket for $238 plus $54
> to attend traffic school. I plan to fight the case since the signs are not
> properly posted.

If the ticket was a "photo citation" (i.e., if a real human didn't
see you and cite you) you can often beat the wrap by hiding from the
process server.  YMMV.  A neighbor did this and the charges were
dropped (part of accepting the "ticket" is waiving your right to be
served; so, never responding to the "ticket" means you've NOT
waived your right to service... making it encumbant on The System
to officially serve you.]

> If I lose, I will ask for community service and tell the
> court I have no money and would like to pick up trash on the roads. The city
> pays $10 an hour for picking up trash. Or, I might get an easier job working
> in a senior centor. Time will tell. I made an illegal left turn where the
> signs are hard to see. There is a picture here::

Many of the non-profits at which I've volunteered "accept"
community service workers.  Never having delved into their
specific details, it *seems* like hours are exchanged at
roughly $10.

Note that you may not be able to avoid the "traffic school"
charges; these sorts of things often have lots of little
gotchas in the fine print.

[Failing to do the traffic school may also ding your auto
insurance premium, disproportionately.  Just make sure you
understand ALL of the tradeoffs!]

[toc] | [prev] | [next] | [standalone]

#26556

On Tue, 16 May 2017 13:49:28 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>Since this is a newsgroup, and this is news...
>
>Wescott Design Services is going into remission, while I pursue a day 
>job.  Job title is Software Designer 5 at Planar Systems -- so any 
>circuit design or control systems jones will have to be satisfied by 
>hobby work or on the side.
>
>In the near term I'll be finishing up current work with current 
>customers; in the longer term I'll probably concentrate on the 
>educational videos and maybe hobby stuff.
>
>Lots of embedded Linux work in my near future, and possibly TDD 
>proselytizing.

Sounds great. When I was looking for work when I got out of college, I
had an offer to work at a little company called Motion Message.
They did LED message displays, that was in 87. I got another offer and
I declined their offer. But I thought it was a neat idea at the time.


Cheers

[toc] | [prev] | [next] | [standalone]

#26557

On Tue, 16 May 2017 13:49:28 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>Since this is a newsgroup, and this is news...
>
>Wescott Design Services is going into remission, while I pursue a day 
>job.  Job title is Software Designer 5 at Planar Systems -- so any 
>circuit design or control systems jones will have to be satisfied by 
>hobby work or on the side.
>
>In the near term I'll be finishing up current work with current 
>customers; in the longer term I'll probably concentrate on the 
>educational videos and maybe hobby stuff.
>
>Lots of embedded Linux work in my near future, and possibly TDD 
>proselytizing.

America, Great Again!

[toc] | [prev] | [next] | [standalone]

#26575

Tim Wescott <seemywebsite@myfooter.really> writes:

> Since this is a newsgroup, and this is news...
>
> Wescott Design Services is going into remission, while I pursue a day 
> job.  Job title is Software Designer 5 at Planar Systems -- so any 
> circuit design or control systems jones will have to be satisfied by 
> hobby work or on the side.
>
> In the near term I'll be finishing up current work with current 
> customers; in the longer term I'll probably concentrate on the 
> educational videos and maybe hobby stuff.
>
> Lots of embedded Linux work in my near future, and possibly TDD 
> proselytizing.

Congratulations Tim. We'll have to exchange trade secrets someday...

BTW, does PS use a specific unit test framework? Have you used it
yet? How do you like it?
-- 
Randy Yates, Embedded Firmware Developer
Garner Underground, Inc.
866-260-9040, x3901
http://www.garnerundergroundinc.com

[toc] | [prev] | [next] | [standalone]

#26580

On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
> 
>> Since this is a newsgroup, and this is news...
>>
>> Wescott Design Services is going into remission, while I pursue a day
>> job.  Job title is Software Designer 5 at Planar Systems -- so any
>> circuit design or control systems jones will have to be satisfied by
>> hobby work or on the side.
>>
>> In the near term I'll be finishing up current work with current
>> customers; in the longer term I'll probably concentrate on the
>> educational videos and maybe hobby stuff.
>>
>> Lots of embedded Linux work in my near future, and possibly TDD
>> proselytizing.
> 
> Congratulations Tim. We'll have to exchange trade secrets someday...
> 
> BTW, does PS use a specific unit test framework? Have you used it yet?
> How do you like it?

I start next week, so I don't know and no.  It's my former coworker from 
FLIR who's pushing TDD, and the manager who hired me is kind of warily 
standing on the sidelines going "what's the deal here?"

The guy pushing it is extremely smart and capable, so whatever it is it's 
probably good.

-- 
www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26591

On 17/05/17 16:02, Tim Wescott wrote:
> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>
>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>
>>> Since this is a newsgroup, and this is news...
>>>
>>> Wescott Design Services is going into remission, while I pursue a day
>>> job.  Job title is Software Designer 5 at Planar Systems -- so any
>>> circuit design or control systems jones will have to be satisfied by
>>> hobby work or on the side.
>>>
>>> In the near term I'll be finishing up current work with current
>>> customers; in the longer term I'll probably concentrate on the
>>> educational videos and maybe hobby stuff.
>>>
>>> Lots of embedded Linux work in my near future, and possibly TDD
>>> proselytizing.
>>
>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>
>> BTW, does PS use a specific unit test framework? Have you used it yet?
>> How do you like it?
>
> I start next week, so I don't know and no.  It's my former coworker from
> FLIR who's pushing TDD, and the manager who hired me is kind of warily
> standing on the sidelines going "what's the deal here?"
>
> The guy pushing it is extremely smart and capable, so whatever it is it's
> probably good.

I expect you'll find it is the codification of
many of the development mentality and practices
that you have been using for a long time.

Be cautious about how TDD applies to bottom-up design
(i.e. finding things that work and clagging them
together) v.s. top-down design. TDD works naturally
with top-down design where all the yet-to-be-implemented
are well understood and feasible.

Anybody that /thinks/ will realise that sometimes
it is beneficial to do a "spike investigation" to
quickly validate key concepts from top-to-bottom, and
then to use that experience to do it "properly"
using full-blown TDD.

[toc] | [prev] | [next] | [standalone]

#26593

On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:

> On 17/05/17 16:02, Tim Wescott wrote:
>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>
>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>
>>>> Since this is a newsgroup, and this is news...
>>>>
>>>> Wescott Design Services is going into remission, while I pursue a day
>>>> job.  Job title is Software Designer 5 at Planar Systems -- so any
>>>> circuit design or control systems jones will have to be satisfied by
>>>> hobby work or on the side.
>>>>
>>>> In the near term I'll be finishing up current work with current
>>>> customers; in the longer term I'll probably concentrate on the
>>>> educational videos and maybe hobby stuff.
>>>>
>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>> proselytizing.
>>>
>>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>>
>>> BTW, does PS use a specific unit test framework? Have you used it yet?
>>> How do you like it?
>>
>> I start next week, so I don't know and no.  It's my former coworker
>> from FLIR who's pushing TDD, and the manager who hired me is kind of
>> warily standing on the sidelines going "what's the deal here?"
>>
>> The guy pushing it is extremely smart and capable, so whatever it is
>> it's probably good.
> 
> I expect you'll find it is the codification of many of the development
> mentality and practices that you have been using for a long time.
> 
> Be cautious about how TDD applies to bottom-up design (i.e. finding
> things that work and clagging them together) v.s. top-down design. TDD
> works naturally with top-down design where all the yet-to-be-implemented
> are well understood and feasible.
> 
> Anybody that /thinks/ will realise that sometimes it is beneficial to do
> a "spike investigation" to quickly validate key concepts from
> top-to-bottom, and then to use that experience to do it "properly"
> using full-blown TDD.

It's not magic.  I've been geeking out on the COSMAC 1802 lately, because 
it was the first microprocessor I ever owned (I had an ELF-II kit).  The 
user's manual has an entire chapter extolling the virtue of SUBROUTINES 
(ooh, ahh) and how to implement them.  It's quite gushy about how using 
subroutines make your code better.  And yet, I've worked on lots of 
crappy code that has subroutines.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26598

On 17/05/17 18:21, Tim Wescott wrote:
> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>
>> On 17/05/17 16:02, Tim Wescott wrote:
>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>
>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>
>>>>> Since this is a newsgroup, and this is news...
>>>>>
>>>>> Wescott Design Services is going into remission, while I pursue a day
>>>>> job.  Job title is Software Designer 5 at Planar Systems -- so any
>>>>> circuit design or control systems jones will have to be satisfied by
>>>>> hobby work or on the side.
>>>>>
>>>>> In the near term I'll be finishing up current work with current
>>>>> customers; in the longer term I'll probably concentrate on the
>>>>> educational videos and maybe hobby stuff.
>>>>>
>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>> proselytizing.
>>>>
>>>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>>>
>>>> BTW, does PS use a specific unit test framework? Have you used it yet?
>>>> How do you like it?
>>>
>>> I start next week, so I don't know and no.  It's my former coworker
>>> from FLIR who's pushing TDD, and the manager who hired me is kind of
>>> warily standing on the sidelines going "what's the deal here?"
>>>
>>> The guy pushing it is extremely smart and capable, so whatever it is
>>> it's probably good.
>>
>> I expect you'll find it is the codification of many of the development
>> mentality and practices that you have been using for a long time.
>>
>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>> things that work and clagging them together) v.s. top-down design. TDD
>> works naturally with top-down design where all the yet-to-be-implemented
>> are well understood and feasible.
>>
>> Anybody that /thinks/ will realise that sometimes it is beneficial to do
>> a "spike investigation" to quickly validate key concepts from
>> top-to-bottom, and then to use that experience to do it "properly"
>> using full-blown TDD.
>
> It's not magic.  I've been geeking out on the COSMAC 1802 lately, because
> it was the first microprocessor I ever owned (I had an ELF-II kit).  The
> user's manual has an entire chapter extolling the virtue of SUBROUTINES
> (ooh, ahh) and how to implement them.  It's quite gushy about how using
> subroutines make your code better.  And yet, I've worked on lots of
> crappy code that has subroutines.

:)

The 1802's implementation of subroutines was, um, quirky to
the point of being obtuse.

I hand built my first computer using a 6800, after having
thought long and hard about the 1802 and 8080. It was a mess,
but worked, I learned a heck of a lot, and prospective
employers were duly impressed.

[toc] | [prev] | [next] | [standalone]

#26599

On Wed, 17 May 2017 18:36:52 +0100, Tom Gardner wrote:

> On 17/05/17 18:21, Tim Wescott wrote:
>> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>>
>>> On 17/05/17 16:02, Tim Wescott wrote:
>>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>>
>>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>>
>>>>>> Since this is a newsgroup, and this is news...
>>>>>>
>>>>>> Wescott Design Services is going into remission, while I pursue a
>>>>>> day job.  Job title is Software Designer 5 at Planar Systems -- so
>>>>>> any circuit design or control systems jones will have to be
>>>>>> satisfied by hobby work or on the side.
>>>>>>
>>>>>> In the near term I'll be finishing up current work with current
>>>>>> customers; in the longer term I'll probably concentrate on the
>>>>>> educational videos and maybe hobby stuff.
>>>>>>
>>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>>> proselytizing.
>>>>>
>>>>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>>>>
>>>>> BTW, does PS use a specific unit test framework? Have you used it
>>>>> yet?
>>>>> How do you like it?
>>>>
>>>> I start next week, so I don't know and no.  It's my former coworker
>>>> from FLIR who's pushing TDD, and the manager who hired me is kind of
>>>> warily standing on the sidelines going "what's the deal here?"
>>>>
>>>> The guy pushing it is extremely smart and capable, so whatever it is
>>>> it's probably good.
>>>
>>> I expect you'll find it is the codification of many of the development
>>> mentality and practices that you have been using for a long time.
>>>
>>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>>> things that work and clagging them together) v.s. top-down design. TDD
>>> works naturally with top-down design where all the
>>> yet-to-be-implemented are well understood and feasible.
>>>
>>> Anybody that /thinks/ will realise that sometimes it is beneficial to
>>> do a "spike investigation" to quickly validate key concepts from
>>> top-to-bottom, and then to use that experience to do it "properly"
>>> using full-blown TDD.
>>
>> It's not magic.  I've been geeking out on the COSMAC 1802 lately,
>> because it was the first microprocessor I ever owned (I had an ELF-II
>> kit).  The user's manual has an entire chapter extolling the virtue of
>> SUBROUTINES (ooh, ahh) and how to implement them.  It's quite gushy
>> about how using subroutines make your code better.  And yet, I've
>> worked on lots of crappy code that has subroutines.
> 
> :)
> 
> The 1802's implementation of subroutines was, um, quirky to the point of
> being obtuse.
> 
> I hand built my first computer using a 6800, after having thought long
> and hard about the 1802 and 8080. It was a mess,
> but worked, I learned a heck of a lot, and prospective employers were
> duly impressed.

The 1802 is neither a CISC processor nor a RISC processor -- it's a NHISC 
processor -- "Never Had Instruction Set Computer".

I wish I had the chops to organize a contest -- I think an annual "build 
the fastest 1802" contest would be fun to be involved in.  Imagine what 
you could do if the only basic rule was that it had to execute 1802 
machine code faithfully, with no constraints on how much happened per 
clock cycle.  Ditch TDA and TDB, keep the I/O command lines, Q, and the 
flags, and go to town.  Prefetch, pipelines, caches, parallel execution, 
predictive branching, everything -- all with that crazy 1802 instruction 
set.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26601

On 17/05/17 18:43, Tim Wescott wrote:
> On Wed, 17 May 2017 18:36:52 +0100, Tom Gardner wrote:
>
>> On 17/05/17 18:21, Tim Wescott wrote:
>>> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>>>
>>>> On 17/05/17 16:02, Tim Wescott wrote:
>>>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>>>
>>>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>>>
>>>>>>> Since this is a newsgroup, and this is news...
>>>>>>>
>>>>>>> Wescott Design Services is going into remission, while I pursue a
>>>>>>> day job.  Job title is Software Designer 5 at Planar Systems -- so
>>>>>>> any circuit design or control systems jones will have to be
>>>>>>> satisfied by hobby work or on the side.
>>>>>>>
>>>>>>> In the near term I'll be finishing up current work with current
>>>>>>> customers; in the longer term I'll probably concentrate on the
>>>>>>> educational videos and maybe hobby stuff.
>>>>>>>
>>>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>>>> proselytizing.
>>>>>>
>>>>>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>>>>>
>>>>>> BTW, does PS use a specific unit test framework? Have you used it
>>>>>> yet?
>>>>>> How do you like it?
>>>>>
>>>>> I start next week, so I don't know and no.  It's my former coworker
>>>>> from FLIR who's pushing TDD, and the manager who hired me is kind of
>>>>> warily standing on the sidelines going "what's the deal here?"
>>>>>
>>>>> The guy pushing it is extremely smart and capable, so whatever it is
>>>>> it's probably good.
>>>>
>>>> I expect you'll find it is the codification of many of the development
>>>> mentality and practices that you have been using for a long time.
>>>>
>>>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>>>> things that work and clagging them together) v.s. top-down design. TDD
>>>> works naturally with top-down design where all the
>>>> yet-to-be-implemented are well understood and feasible.
>>>>
>>>> Anybody that /thinks/ will realise that sometimes it is beneficial to
>>>> do a "spike investigation" to quickly validate key concepts from
>>>> top-to-bottom, and then to use that experience to do it "properly"
>>>> using full-blown TDD.
>>>
>>> It's not magic.  I've been geeking out on the COSMAC 1802 lately,
>>> because it was the first microprocessor I ever owned (I had an ELF-II
>>> kit).  The user's manual has an entire chapter extolling the virtue of
>>> SUBROUTINES (ooh, ahh) and how to implement them.  It's quite gushy
>>> about how using subroutines make your code better.  And yet, I've
>>> worked on lots of crappy code that has subroutines.
>>
>> :)
>>
>> The 1802's implementation of subroutines was, um, quirky to the point of
>> being obtuse.
>>
>> I hand built my first computer using a 6800, after having thought long
>> and hard about the 1802 and 8080. It was a mess,
>> but worked, I learned a heck of a lot, and prospective employers were
>> duly impressed.
>
> The 1802 is neither a CISC processor nor a RISC processor -- it's a NHISC
> processor -- "Never Had Instruction Set Computer".

:)

> I wish I had the chops to organize a contest -- I think an annual "build
> the fastest 1802" contest would be fun to be involved in.  Imagine what
> you could do if the only basic rule was that it had to execute 1802
> machine code faithfully, with no constraints on how much happened per
> clock cycle.  Ditch TDA and TDB, keep the I/O command lines, Q, and the
> flags, and go to town.  Prefetch, pipelines, caches, parallel execution,
> predictive branching, everything -- all with that crazy 1802 instruction
> set.

I hate all those with a vengeance, since they prevent hard
real-time software.

I'm currently experimenting with a /small/ XMOS device which
deliberately avoids all of those techniques so that it can
guarantee timing. So far I've been able to get the /software/
to reliably count the edges on two 20Mb/s input pins,
process the results and simultaneously shove them up a USB
link to a host PC.

Now I've got to understand the algorithms in reciprocal and
continuous timestamping frequency counters :)

[toc] | [prev] | [next] | [standalone]

#26602

On 17/05/17 18:55, Tom Gardner wrote:
> On 17/05/17 18:43, Tim Wescott wrote:
>> On Wed, 17 May 2017 18:36:52 +0100, Tom Gardner wrote:
>>
>>> On 17/05/17 18:21, Tim Wescott wrote:
>>>> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>>>>
>>>>> On 17/05/17 16:02, Tim Wescott wrote:
>>>>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>>>>
>>>>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>>>>
>>>>>>>> Since this is a newsgroup, and this is news...
>>>>>>>>
>>>>>>>> Wescott Design Services is going into remission, while I pursue a
>>>>>>>> day job.  Job title is Software Designer 5 at Planar Systems -- so
>>>>>>>> any circuit design or control systems jones will have to be
>>>>>>>> satisfied by hobby work or on the side.
>>>>>>>>
>>>>>>>> In the near term I'll be finishing up current work with current
>>>>>>>> customers; in the longer term I'll probably concentrate on the
>>>>>>>> educational videos and maybe hobby stuff.
>>>>>>>>
>>>>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>>>>> proselytizing.
>>>>>>>
>>>>>>> Congratulations Tim. We'll have to exchange trade secrets someday...
>>>>>>>
>>>>>>> BTW, does PS use a specific unit test framework? Have you used it
>>>>>>> yet?
>>>>>>> How do you like it?
>>>>>>
>>>>>> I start next week, so I don't know and no.  It's my former coworker
>>>>>> from FLIR who's pushing TDD, and the manager who hired me is kind of
>>>>>> warily standing on the sidelines going "what's the deal here?"
>>>>>>
>>>>>> The guy pushing it is extremely smart and capable, so whatever it is
>>>>>> it's probably good.
>>>>>
>>>>> I expect you'll find it is the codification of many of the development
>>>>> mentality and practices that you have been using for a long time.
>>>>>
>>>>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>>>>> things that work and clagging them together) v.s. top-down design. TDD
>>>>> works naturally with top-down design where all the
>>>>> yet-to-be-implemented are well understood and feasible.
>>>>>
>>>>> Anybody that /thinks/ will realise that sometimes it is beneficial to
>>>>> do a "spike investigation" to quickly validate key concepts from
>>>>> top-to-bottom, and then to use that experience to do it "properly"
>>>>> using full-blown TDD.
>>>>
>>>> It's not magic.  I've been geeking out on the COSMAC 1802 lately,
>>>> because it was the first microprocessor I ever owned (I had an ELF-II
>>>> kit).  The user's manual has an entire chapter extolling the virtue of
>>>> SUBROUTINES (ooh, ahh) and how to implement them.  It's quite gushy
>>>> about how using subroutines make your code better.  And yet, I've
>>>> worked on lots of crappy code that has subroutines.
>>>
>>> :)
>>>
>>> The 1802's implementation of subroutines was, um, quirky to the point of
>>> being obtuse.
>>>
>>> I hand built my first computer using a 6800, after having thought long
>>> and hard about the 1802 and 8080. It was a mess,
>>> but worked, I learned a heck of a lot, and prospective employers were
>>> duly impressed.
>>
>> The 1802 is neither a CISC processor nor a RISC processor -- it's a NHISC
>> processor -- "Never Had Instruction Set Computer".
>
> :)
>
>> I wish I had the chops to organize a contest -- I think an annual "build
>> the fastest 1802" contest would be fun to be involved in.  Imagine what
>> you could do if the only basic rule was that it had to execute 1802
>> machine code faithfully, with no constraints on how much happened per
>> clock cycle.  Ditch TDA and TDB, keep the I/O command lines, Q, and the
>> flags, and go to town.  Prefetch, pipelines, caches, parallel execution,
>> predictive branching, everything -- all with that crazy 1802 instruction
>> set.
>
> I hate all those with a vengeance, since they prevent hard
> real-time software.
>
> I'm currently experimenting with a /small/ XMOS device which
> deliberately avoids all of those techniques so that it can
> guarantee timing. So far I've been able to get the /software/
> to reliably count the edges on two 20Mb/s input pins,

Oops, 50Mb/s, i.e. 100Mb/s total and I might be able
to get it to 100Mb/s per input.


> process the results and simultaneously shove them up a USB
> link to a host PC.
>
> Now I've got to understand the algorithms in reciprocal and
> continuous timestamping frequency counters :)

[toc] | [prev] | [next] | [standalone]

#26604

On Wed, 17 May 2017 18:55:16 +0100, Tom Gardner wrote:

> On 17/05/17 18:43, Tim Wescott wrote:
>> On Wed, 17 May 2017 18:36:52 +0100, Tom Gardner wrote:
>>
>>> On 17/05/17 18:21, Tim Wescott wrote:
>>>> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>>>>
>>>>> On 17/05/17 16:02, Tim Wescott wrote:
>>>>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>>>>
>>>>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>>>>
>>>>>>>> Since this is a newsgroup, and this is news...
>>>>>>>>
>>>>>>>> Wescott Design Services is going into remission, while I pursue a
>>>>>>>> day job.  Job title is Software Designer 5 at Planar Systems --
>>>>>>>> so any circuit design or control systems jones will have to be
>>>>>>>> satisfied by hobby work or on the side.
>>>>>>>>
>>>>>>>> In the near term I'll be finishing up current work with current
>>>>>>>> customers; in the longer term I'll probably concentrate on the
>>>>>>>> educational videos and maybe hobby stuff.
>>>>>>>>
>>>>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>>>>> proselytizing.
>>>>>>>
>>>>>>> Congratulations Tim. We'll have to exchange trade secrets
>>>>>>> someday...
>>>>>>>
>>>>>>> BTW, does PS use a specific unit test framework? Have you used it
>>>>>>> yet?
>>>>>>> How do you like it?
>>>>>>
>>>>>> I start next week, so I don't know and no.  It's my former coworker
>>>>>> from FLIR who's pushing TDD, and the manager who hired me is kind
>>>>>> of warily standing on the sidelines going "what's the deal here?"
>>>>>>
>>>>>> The guy pushing it is extremely smart and capable, so whatever it
>>>>>> is it's probably good.
>>>>>
>>>>> I expect you'll find it is the codification of many of the
>>>>> development mentality and practices that you have been using for a
>>>>> long time.
>>>>>
>>>>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>>>>> things that work and clagging them together) v.s. top-down design.
>>>>> TDD works naturally with top-down design where all the
>>>>> yet-to-be-implemented are well understood and feasible.
>>>>>
>>>>> Anybody that /thinks/ will realise that sometimes it is beneficial
>>>>> to do a "spike investigation" to quickly validate key concepts from
>>>>> top-to-bottom, and then to use that experience to do it "properly"
>>>>> using full-blown TDD.
>>>>
>>>> It's not magic.  I've been geeking out on the COSMAC 1802 lately,
>>>> because it was the first microprocessor I ever owned (I had an ELF-II
>>>> kit).  The user's manual has an entire chapter extolling the virtue
>>>> of SUBROUTINES (ooh, ahh) and how to implement them.  It's quite
>>>> gushy about how using subroutines make your code better.  And yet,
>>>> I've worked on lots of crappy code that has subroutines.
>>>
>>> :)
>>>
>>> The 1802's implementation of subroutines was, um, quirky to the point
>>> of being obtuse.
>>>
>>> I hand built my first computer using a 6800, after having thought long
>>> and hard about the 1802 and 8080. It was a mess,
>>> but worked, I learned a heck of a lot, and prospective employers were
>>> duly impressed.
>>
>> The 1802 is neither a CISC processor nor a RISC processor -- it's a
>> NHISC processor -- "Never Had Instruction Set Computer".
> 
> :)
> 
>> I wish I had the chops to organize a contest -- I think an annual
>> "build the fastest 1802" contest would be fun to be involved in. 
>> Imagine what you could do if the only basic rule was that it had to
>> execute 1802 machine code faithfully, with no constraints on how much
>> happened per clock cycle.  Ditch TDA and TDB, keep the I/O command
>> lines, Q, and the flags, and go to town.  Prefetch, pipelines, caches,
>> parallel execution, predictive branching, everything -- all with that
>> crazy 1802 instruction set.
> 
> I hate all those with a vengeance, since they prevent hard real-time
> software.
> 
> I'm currently experimenting with a /small/ XMOS device which
> deliberately avoids all of those techniques so that it can guarantee
> timing. So far I've been able to get the /software/
> to reliably count the edges on two 20Mb/s input pins, process the
> results and simultaneously shove them up a USB link to a host PC.
> 
> Now I've got to understand the algorithms in reciprocal and continuous
> timestamping frequency counters :)

Some guy has Verilog code for an 1802 in which he claims a 60MHz clock, 
one clock per instruction (or perhaps fetch).  That would be 
deterministic, and fast by some measures.

All the modern pipeline/predict/prefetch whiz-bang doesn't prevent hard 
real time, if only the processor manufacturers would publish the absolute 
maximum time it takes to execute any possible instruction, or (better) 
provide tools for finding the maximum time-from-interrupt for any given 
chunk of code.  Then you could just add up all the critical stuff and 
make sure it works.

In my experience there isn't THAT much variation -- you just need to know 
how much variation to allow for to meet hard real time criteria.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26607

On 17/05/17 19:28, Tim Wescott wrote:
> On Wed, 17 May 2017 18:55:16 +0100, Tom Gardner wrote:
>
>> On 17/05/17 18:43, Tim Wescott wrote:
>>> On Wed, 17 May 2017 18:36:52 +0100, Tom Gardner wrote:
>>>
>>>> On 17/05/17 18:21, Tim Wescott wrote:
>>>>> On Wed, 17 May 2017 18:11:22 +0100, Tom Gardner wrote:
>>>>>
>>>>>> On 17/05/17 16:02, Tim Wescott wrote:
>>>>>>> On Wed, 17 May 2017 09:12:46 -0400, Randy Yates wrote:
>>>>>>>
>>>>>>>> Tim Wescott <seemywebsite@myfooter.really> writes:
>>>>>>>>
>>>>>>>>> Since this is a newsgroup, and this is news...
>>>>>>>>>
>>>>>>>>> Wescott Design Services is going into remission, while I pursue a
>>>>>>>>> day job.  Job title is Software Designer 5 at Planar Systems --
>>>>>>>>> so any circuit design or control systems jones will have to be
>>>>>>>>> satisfied by hobby work or on the side.
>>>>>>>>>
>>>>>>>>> In the near term I'll be finishing up current work with current
>>>>>>>>> customers; in the longer term I'll probably concentrate on the
>>>>>>>>> educational videos and maybe hobby stuff.
>>>>>>>>>
>>>>>>>>> Lots of embedded Linux work in my near future, and possibly TDD
>>>>>>>>> proselytizing.
>>>>>>>>
>>>>>>>> Congratulations Tim. We'll have to exchange trade secrets
>>>>>>>> someday...
>>>>>>>>
>>>>>>>> BTW, does PS use a specific unit test framework? Have you used it
>>>>>>>> yet?
>>>>>>>> How do you like it?
>>>>>>>
>>>>>>> I start next week, so I don't know and no.  It's my former coworker
>>>>>>> from FLIR who's pushing TDD, and the manager who hired me is kind
>>>>>>> of warily standing on the sidelines going "what's the deal here?"
>>>>>>>
>>>>>>> The guy pushing it is extremely smart and capable, so whatever it
>>>>>>> is it's probably good.
>>>>>>
>>>>>> I expect you'll find it is the codification of many of the
>>>>>> development mentality and practices that you have been using for a
>>>>>> long time.
>>>>>>
>>>>>> Be cautious about how TDD applies to bottom-up design (i.e. finding
>>>>>> things that work and clagging them together) v.s. top-down design.
>>>>>> TDD works naturally with top-down design where all the
>>>>>> yet-to-be-implemented are well understood and feasible.
>>>>>>
>>>>>> Anybody that /thinks/ will realise that sometimes it is beneficial
>>>>>> to do a "spike investigation" to quickly validate key concepts from
>>>>>> top-to-bottom, and then to use that experience to do it "properly"
>>>>>> using full-blown TDD.
>>>>>
>>>>> It's not magic.  I've been geeking out on the COSMAC 1802 lately,
>>>>> because it was the first microprocessor I ever owned (I had an ELF-II
>>>>> kit).  The user's manual has an entire chapter extolling the virtue
>>>>> of SUBROUTINES (ooh, ahh) and how to implement them.  It's quite
>>>>> gushy about how using subroutines make your code better.  And yet,
>>>>> I've worked on lots of crappy code that has subroutines.
>>>>
>>>> :)
>>>>
>>>> The 1802's implementation of subroutines was, um, quirky to the point
>>>> of being obtuse.
>>>>
>>>> I hand built my first computer using a 6800, after having thought long
>>>> and hard about the 1802 and 8080. It was a mess,
>>>> but worked, I learned a heck of a lot, and prospective employers were
>>>> duly impressed.
>>>
>>> The 1802 is neither a CISC processor nor a RISC processor -- it's a
>>> NHISC processor -- "Never Had Instruction Set Computer".
>>
>> :)
>>
>>> I wish I had the chops to organize a contest -- I think an annual
>>> "build the fastest 1802" contest would be fun to be involved in.
>>> Imagine what you could do if the only basic rule was that it had to
>>> execute 1802 machine code faithfully, with no constraints on how much
>>> happened per clock cycle.  Ditch TDA and TDB, keep the I/O command
>>> lines, Q, and the flags, and go to town.  Prefetch, pipelines, caches,
>>> parallel execution, predictive branching, everything -- all with that
>>> crazy 1802 instruction set.
>>
>> I hate all those with a vengeance, since they prevent hard real-time
>> software.
>>
>> I'm currently experimenting with a /small/ XMOS device which
>> deliberately avoids all of those techniques so that it can guarantee
>> timing. So far I've been able to get the /software/
>> to reliably count the edges on two 20Mb/s input pins, process the
>> results and simultaneously shove them up a USB link to a host PC.
>>
>> Now I've got to understand the algorithms in reciprocal and continuous
>> timestamping frequency counters :)
>
> Some guy has Verilog code for an 1802 in which he claims a 60MHz clock,
> one clock per instruction (or perhaps fetch).  That would be
> deterministic, and fast by some measures.
>
> All the modern pipeline/predict/prefetch whiz-bang doesn't prevent hard
> real time, if only the processor manufacturers would publish the absolute
> maximum time it takes to execute any possible instruction, or (better)
> provide tools for finding the maximum time-from-interrupt for any given
> chunk of code.  Then you could just add up all the critical stuff and
> make sure it works.
>
> In my experience there isn't THAT much variation -- you just need to know
> how much variation to allow for to meet hard real time criteria.

It complicates things enormously, doubly so when all the
caches are involved. ISTR someone measuring a 486 with
its tiny caches, and finding the mean:max ISR time was
somewhere around 1:5. I expect I've still got a paper
copy, /somewhere/.

The XMOS tools claim to indicate the exact loop/function
times, assuming input is available and output can be
delivered (Occam channel semantics).

The event-driven multicore hardware+software
co-implementation looks to be rather nice too.
And the I/O is pleasantly high-level too: do
i/o on a specific clock cycle, wait until
there's a change, etc etc. Makes high speed
bit-bashing in software tractable.

[toc] | [prev] | [next] | [standalone]

#26614

On Tue, 16 May 2017 13:49:28 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>Since this is a newsgroup, and this is news...
>
>Wescott Design Services is going into remission, while I pursue a day 
>job.  Job title is Software Designer 5 at Planar Systems -- so any 
>circuit design or control systems jones will have to be satisfied by 
>hobby work or on the side.
>
>In the near term I'll be finishing up current work with current 
>customers; in the longer term I'll probably concentrate on the 
>educational videos and maybe hobby stuff.
>
>Lots of embedded Linux work in my near future, and possibly TDD 
>proselytizing.


Planar Systems is one VERY cool company !  I had to look at their web
site...  They even have displays in the SPAM museum !!

I wonder why they want you to clear your cache and cookies before
applying to a job application ?  Maybe so you have to enter everything
from scratch.

boB

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web