Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 22 Feb 2012 10:15:23 -0600 Message-ID: <4F45149B.3040009@SPAM.comp-arch.net> Date: Wed, 22 Feb 2012 08:15:23 -0800 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <5f340edf-739a-46ba-9320-7151dfaa8f00@l14g2000vbe.googlegroups.com> In-Reply-To: <5f340edf-739a-46ba-9320-7151dfaa8f00@l14g2000vbe.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 32 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-zBj3DThn7nVDtbtGSmcLMaX3rAeAH/VJR5qk8gGZo5jy5KBUFS/pAudhWo/DW8hy/by/TXqcIhM9YDW!Q93frNlo4jAd7DbymlyYlKgZgDiJRjK6sXnV5oCq7BWRoVjqXiLY0uwAwcKirmg= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2903 X-Received-Bytes: 3044 Xref: x330-a1.tempe.blueboxinc.net comp.arch:6033 On 2/21/2012 11:38 AM, Michael S wrote: > On Feb 21, 9:13 pm, ChrisQ wrote: >> On 02/21/12 10:07, Terje Mathisen wrote: >> >> >> >>> If you have an embedded hard real-time system, one of the most >>> dependable ways to implement it is to have a core polling loop that goes >>> around checking all the various signals to be handled. >> >> That may work for some systems, but not anything like fast enough for hard >> real time work, where you may, for example, have high speed comms devices >> with little or no internal buffering. > > Such hardware was justifiable 20 years ago. Not now. If your hardware > guys still design comms with small fifos then your organization is in > bad need for designers with clue. > On properly designed modern hardware the only justification for fast > interrupt response requirement should be one or another form of > "closed loop". All "old" reasons should be eliminated by smart HW > buffering and, when appropriate, HW timestamping. Is trying to do a threat analysis, and then shoot a missile out of the air closed loop? Although I guess with the time constants involved, even that may no longer be hard real time. All hard real time becomes soft real time, as computers become relatively faster. However, the hard real time problems move on to physically faster issues.