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: dj3vande on 15 Jan 2010 11:43
In article <5de738e1-b64c-470c-a097-4020a2397cf0(a)j5g2000yqm.googlegroups.com>,
Nick Keighley <nick_keighley_nospam(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.


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".


dave

--
Dave Vandervies dj3vande at eskimo dot com
I only have to be quoted in a sig 5000 more times before I catch up
with Richard Heathfield.
--Nick Keighley in comp.lang.c
From: -jg on 15 Jan 2010 15:19
On Jan 16, 8:28 am, Jon Kirwan <j...(a)infinitefactors.org> wrote:
>
> Walter, they don't even do _that_ task well enough.
>
> Since this topic appears to suggest the idea of having a
> compiler do something I consider almost crazy-minded at this
> point in time.....

Yes, the best reply to the original overall question, is a Pencil !!.

However, there are some details, aside from the
'find a new algorithm'(?!) request that tools could be
expected to offer.

Taking this:
[" It will be even more helpful if that tool
also provides the cycle counts, cache
usage, cache misses and lines of code
also. "]

Lines of code should already be there, in a listing output, and also
in a debugger.
Likewise, on a chip/ICE with HW breakpoints and sys timers, you could
expect a good system to be able to give time-of-flight on running
code, if you really need that.
The OP sees to expect all this in an EDITOR, which is miss-directed,
but it is possible in a full tool chain.

-jg


From: Andy on 15 Jan 2010 17:32
On Jan 14, 9:57 am, David Brown <da...(a)westcontrol.removethisbit.com>
wrote:
> I don't agree here (perhaps as a compiler writer you are thinking of
> "implementation" in terms of generated target code - then I'd agree).
> Kids use Logo to learn about programming concepts, and how to get the
> computer to do what you want it to do.  They learn to write things like:
>
> TO SQUARE :size
> REPEAT 4 [ FD :size RT 90 ]
> END
>
> This is entirely about writing an imperative implementation of how you
> want the system to draw a square.
>
> Compare this to a sample program in a real functional programming
> language, Haskell:
>
> factorial 0 = 1
> factorial n = n * factorial(n - 1)
>
> Here you tell the system what you want - you give a mathematical
> description of the results.  You don't care how it gets them - maybe it
> uses recursion, maybe it uses iteration, maybe it builds up a cache of
> calculated values as it goes along.
>

The LOGO interpreter/compiler is just as free to implement alternative
solutions to drawing a square as the Haskell compiler is of altering
the described recursive implementation of a factorial. Whether the
compiler is smart enough to do so has nothing to do with the language
being "procedural" or "functional".

Andy
From: Jasen Betts on 16 Jan 2010 03:28
On 2010-01-15, Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote:
> 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.

emacs comes close. :)



--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: -jg on 16 Jan 2010 16:01
On Jan 16, 11:18 pm, Walter Banks <wal...(a)bytecraft.com> wrote:

> To illustrate this point. Your exact timing example is not a
> C compiler limitation but a language limitation. How do
> you describe exact timing all paths in a function in an
> unambiguous way in C? Exact timing is an application
> objective.

Something like exact timing would be via local directives, and is
going to be very locally dependant.
It almost comes into "better reporting"

I remember we added a simple code-size report, for each code block,
so pgmrs could quickly compare different choices. Trivial to do, and
useful.

We did think about reporting time, but that quickly degenerates as
you do not know what path combinations will actually occur, and it can
vary widely across
same core:different vendor.
So our solution here was always to verify on a scope,
and patch as needed. That covers all complexity levels.


On this 'exact timing' topic, I note the new Cortex M0 cores (NXP,
Nuvoton?), claims a fixed-int-response time, so they remove the
'current opcode' jitter. This was also discussed some years ago as a
feature option for a faster 8051 that never got to silicon.
It's a good thing to see devices that are moving 'less deterministic'
offer a way to be 'more deterministic' :)
[- and it side-steps all that SW work ]

-jg

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