Prev: Aerodynamics for Engineers, 5E Solution manual Bertin Russ Cummings is available at affordable prices. Email me at instructors.team[at]gmail.com if you need to buy this. All emails will be answered ASAP.
Next: Looking for 2nd hand electronic tools
From: -jg on 16 Jan 2010 17:43
On Jan 17, 11:01 am, Jon Kirwan <j...(a)infinitefactors.org> wrote:
> On Sat, 16 Jan 2010 13:01:24 -0800 (PST), -jg
>
> <jim.granvi...(a)gmail.com> wrote:
>
> > It almost comes into "better reporting"
>
> Not just better reporting for the case I'm talking about.  If
> you can't provide something that actually impacts the code
> generation but have very good reporting on what you get out
> of it, you will find yourself fighting the darned thing at
> every turn of the code trying to work out equal times.  It's
> far better to provide the clues and hints a compiler can then
> use in generating code.

In the simplest cases, the difference between manually adding NOPs
and checking, or trawling the manual, setting a directive, and then
also checking the tool really DID do what you hoped, is negligible.

In the more complex cases, the tools are almost certain to drop the
ball, so you'll also need to manually check.

So that's why I favour 'better reporting' over 'granular smarts'
anytime, as the reporting is ALWAYS useful, and the smarts are only
case-by-case useful and with risky failure modes.
[aka The illusion of intelligence is dangerous]

The rare times I've needed to do this, it was no sweat to just use a
pencil, and then do an operational check.

-jg

From: -jg on 17 Jan 2010 15:15
On Jan 18, 7:52 am, Jon Kirwan <j...(a)infinitefactors.org> wrote:
> On Sun, 17 Jan 2010 07:11:53 -0500, Walter Banks
> <wal...(a)bytecraft.com> wrote:
> >3) Pre computing the next result and posting the result when
> >    needed. (This is routinely the approach in automotive
> >   controllers)

Pre computing can also mean taking a multi-branch-derived answer, and
applying it earliest in an interrupt.
So each interrupt sample/decision/calculates/stores, but before it
starts the SW branches, it pops out the answer from the last
interrupt.
So you trade off latency, for less jitter.

We do exactly this in a rate-multiplier DAC library.

This is also very revision safe.

[with the M0, this would yield 0 jitter (on one interrupt)
In the 8051, if you are in idle, there is also zero jitter.

Another jitter-accumulate-avoidance trick usable on small uC, with 'no
AutoReload on that timer', is to do the next value calc/reload only on
the high byte.
Places caveats on your crystal, and a ceiling on INT response times,
but does side-step any SW added creepage to total times.

'Timer-snap' that Walter mentioned, does not need to wholly consume a
timer, just have it running.
Useful when you have too many branches to control...

You read the lower-byte cycle value as a starting value, run all your
variant branches, and then pad the fastest ones with a timer-derived
pause.
Timer granularity is usually less an issue then SW granularity.
Getting single cycle increments in SW usually means multiple paths..
and your fix-it SW can consume more than the do-it sw ;)

Not sure how you'd 'compiler automate' this ?
perhaps insert a start tag, and a series of stop tags,
all in the source, and create/maintain/calibrate a whole series of
cycle-tables, for the cores your compiler supports. There are over a
dozen timing choices on 80C51's alone now.
(NOT going to be easy for the compiler to correctly add value-
dependant multiple branches, so a pencil is _still_ needed)

That's a lot of work, for a rarely used feature, that is sure to never
quite exactly match what the customer wants to do anyway! ;)

So I still don't think you can replace that pencil, but good reports
can make the task easier.

-jg

From: Walter Banks on 17 Jan 2010 17:26


-jg wrote:

> Not sure how you'd 'compiler automate' this ?
> perhaps insert a start tag, and a series of stop tags,
> all in the source, and create/maintain/calibrate a whole series of
> cycle-tables, for the cores your compiler supports. There are over a
> dozen timing choices on 80C51's alone now.
> (NOT going to be easy for the compiler to correctly add value-
> dependant multiple branches, so a pencil is _still_ needed)

We have one advantage in our compilers for this because we
normally compile directly to machine code. For processors with
deterministic timing constant timing is possible for the limited
set of problems whose timing is deterministic.


Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Walter Banks on 17 Jan 2010 17:33


-jg wrote:

> > On Sun, 17 Jan 2010 07:11:53 -0500, Walter Banks
> > <wal...(a)bytecraft.com> wrote:
> > >3) Pre computing the next result and posting the result when
> > > needed. (This is routinely the approach in automotive
> > > controllers)
>
> Pre computing can also mean taking a multi-branch-derived answer, and
> applying it earliest in an interrupt.
> So each interrupt sample/decision/calculates/stores, but before it
> starts the SW branches, it pops out the answer from the last
> interrupt.
> So you trade off latency, for less jitter.

In one of the processors each I/O pin had an associated interrupt
and one of the modes transferred latched an input bit or transferred
a latched bit to an output when the interrupt fired. The interrupt
was also synched to a specific clock edge.

I have used the same technique of pre computing bits for
processors with no special hardware.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Nick Keighley on 18 Jan 2010 05:34
On 15 Jan, 16:43, dj3va...(a)csclub.uwaterloo.ca.invalid wrote:
> In article <5de738e1-b64c-470c-a097-4020a2397...(a)j5g2000yqm.googlegroups.com>,
> Nick Keighley  <nick_keighley_nos...(a)hotmail.com> wrote:
> >On 13 Jan, 16:43, dj3va...(a)csclub.uwaterloo.ca.invalid wrote:
> >> In article <4b4def88$0$22938$e4fe5...(a)news.xs4all.nl>,
> >> [Jongware] <so...(a)no.spam.net> wrote:


> >> >Aha -- wouldn't the logical end point be a programming language where
> >> >you type "word processor", save it as source, compile, and have a word
> >> >processor?
>
> >> Why bother to compile it?  Just have it interpret on-the-fly.
> >> That way you could even run it in interactive mode, and it's
> >> sufficiently high-level that even non-programmers could usefully use
> >> it.
>
> >> Unix people call this a "shell".
>
> >I'm guessing you're trying to be funny/ironic. But in case you aren't,
> >Unix has dozens of stranglely incompatible Command Line Interfaces
> >that Unix people call "shells". None of them are word processors.
>
> Right.
> But all of them have the property that I can get a word processor by
> typing the name of a word processor that's installed on the system.

I thought you were claiming Unix uniquely had some sort of VHLL. Apart
from the weird embedded ones, don't *all* OSs have a way to run the
programs that are installed on them?

Wasn't jongware suggesting something even more magical? The VHLL that
can create appications that aren't stored on the machine?


> My point was that the "primitives" provided by a shell (the programs
> installed on the system) give a pretty good approximation to
> [Jongware]'s suggestion of "type 'word processor' and get a word
> processor".

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Aerodynamics for Engineers, 5E Solution manual Bertin Russ Cummings is available at affordable prices. Email me at instructors.team[at]gmail.com if you need to buy this. All emails will be answered ASAP.
Next: Looking for 2nd hand electronic tools