In article <xOUSA.16651$C56.666@fx34.am4>, spamjunk@blueyonder.co.uk says...> > On 17/05/17 10:10, Paul wrote: > > In article <B0USA.14491$8r1.938@fx42.am4>, spamjunk@blueyonder.co.uk > > says... > > ....... > >> The simple point to bear in mind is that the results of TDD > >> are only as good as the quality of the tests. Test the > >> wrong/unimportant thing, or don't test important behaviour, > >> and the outcome can be "suboptimal". > >> > >> That's not a difficult point (to put it mildly!), but it > >> is horrifying how it is ignored by zealots and/or not > >> appreciated by inexperienced. > >> > >> The best defense is, to quote one of the two mottoes > >> worth a damn, "Think". No change there, then! > > > > The Titanic sank but I bet nearly all the individual parts past their > > unit tests. > > > > Or the video I saw on Dev Humor a while back of sliding door and bolt > > to lock door fixed wrong way. Each part past its unit tests. > > Yup. > > None of this is difficult, but it does seem > to escape some people :(Some of the classic videos http://devhumor.com/media/2-unit-tests-0-integration-tests and https://www.youtube.com/watch?v=0GypdsJulKE -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/LogicCell/> Logic Gate Education <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
[OT] I got a JOB!!!
Started by ●May 16, 2017
Reply by ●May 17, 20172017-05-17
Reply by ●May 17, 20172017-05-17
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
Reply by ●May 17, 20172017-05-17
On 17/05/17 00:32, Tim Wescott wrote:> On Tue, 16 May 2017 23:51:26 +0100, Tom Gardner wrote: > >> On 16/05/17 23:11, Tim Wescott wrote: >>> On Tue, 16 May 2017 22:05:49 +0100, Tom Gardner wrote: >>> >>>> On 16/05/17 21:24, Tim Wescott wrote: >>>>> On Tue, 16 May 2017 20:17:17 +0000, eric.jacobsen wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> Software Designer 5? Sounds a little like being in Sector 7-G? >>>>> >>>>> "Really Senior Embedded Guy". >>>>> >>>>>>> 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. >>>>>> >>>>>> Time Division Duplex? >>>>> >>>>> Test Driven Design. >>>> >>>> Be prepared to meet some people that believe X works /because/ all the >>>> unit tests for X are passed and the console shows a green light. >>> >>> Well, yes. The two main good things about TDD for me is that it makes >>> me think early about how something really should work, and there are >>> finer- grained tests to make sure that if I did something really >>> dumbass it gets caught. >>> >>> Even with TDD, I still find errors, so I don't live under the delusion >>> that you can test in quality. >>> >>>> Usually they have never been introduced to the concept that "you can't >>>> test quality into a product". >>>> Unit tests developed as part of TDD are highly beneficial, but are not >>>> sufficient. >>>> >>>> But I'm sure you know that! >>> >>> Yea verily!! >> >> 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. >> >> Classic anti-patterns warning of that: unit tests on getters/setters, >> and/or changing visibility solely to enable unit tests. > > That's an interesting point. I haven't been using TDD long enough for > that to be an issue. Good to know!Another stumbling block can be to get people to consider the definition of "unit" in a unit test. Too frequently they equate it with "unit" = class/method. Sometimes they have difficulty thinking that unit can be a subsystem - they think that /can't/ be unit testing because it is "integration testing". If they argue, get them to define what they mean by a "unit test", and then point out that actually their "unit test" isn't testing a unit. It is testing the integration of their code and library code (and compiler and runtime). The corollary is that TDD mentality and technology can - and often should - be applied to integration testing. All you have to do is increase the granularity of the UUT.
Reply by ●May 17, 20172017-05-17
On 17/05/17 15:59, Paul wrote:> In article <xOUSA.16651$C56.666@fx34.am4>, spamjunk@blueyonder.co.uk > says... >> >> On 17/05/17 10:10, Paul wrote: >>> In article <B0USA.14491$8r1.938@fx42.am4>, spamjunk@blueyonder.co.uk >>> says... >>> ....... >>>> The simple point to bear in mind is that the results of TDD >>>> are only as good as the quality of the tests. Test the >>>> wrong/unimportant thing, or don't test important behaviour, >>>> and the outcome can be "suboptimal". >>>> >>>> That's not a difficult point (to put it mildly!), but it >>>> is horrifying how it is ignored by zealots and/or not >>>> appreciated by inexperienced. >>>> >>>> The best defense is, to quote one of the two mottoes >>>> worth a damn, "Think". No change there, then! >>> >>> The Titanic sank but I bet nearly all the individual parts past their >>> unit tests. >>> >>> Or the video I saw on Dev Humor a while back of sliding door and bolt >>> to lock door fixed wrong way. Each part past its unit tests. >> >> Yup. >> >> None of this is difficult, but it does seem >> to escape some people :( > > Some of the classic videos > > http://devhumor.com/media/2-unit-tests-0-integration-tests > > and > > https://www.youtube.com/watch?v=0GypdsJulKE:) Of course there's a good argument that much (most?) "integration testing" is really just "unit testing" with larger units. People can get too stuck on the specific definition (of unit) they have been taught.
Reply by ●May 17, 20172017-05-17
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.
Reply by ●May 17, 20172017-05-17
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
Reply by ●May 17, 20172017-05-17
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.
Reply by ●May 17, 20172017-05-17
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
Reply by ●May 17, 20172017-05-17
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 :)
Reply by ●May 17, 20172017-05-17
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 :)
