twitter: comp.lang.c - 25 new messages in 9 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 10 ==
Date: Tues, Jan 26 2010 12:04 am
From: jacob navia

gwowen a écrit :
> On Jan 26, 6:37 am, jacob navia <ja...@spamsink.net> wrote:
>> That is why lcc-win proposes a garbage collector, because is the only
>> sensible solution.
>
> And what language do you write your garbage collector in? ;)
>

Boehm's GC is written in plain C. Yes, you can write a GC in C. There
are a few bits and pieces done in assembly, but for the most part
everything is in C.

> Garbage collectors clearly have their place, and an (optional) one
> would be a boon to any language that doesn't have one built in.

True

> But
> there are perfectly good alternatives, besides manual reference
> counting. The fact that COM screwed up reference counting, doesn't
> mean that reference counting is a non-starter.

COM did not "screw it". Reference counting has its drawbacks, that's all.

> In many circumstances
> a smart pointer is preferable to GC, as it gives a programmer greater
> control over deterministic destruction (RAII works a lot better on
> managing mutexes than GC, for example -- lock()/unlock() cares about
> timing in a way malloc()/free() doesn't).

That could be done in C if we had operator overloading, something I have
been trying to promote for years.

> In many circumstance, GC is
> preferable to smart pointers, as the programmer doesn't care about
> those things.
>

Yes.
> As ever: There is no silver bullet.

True. GC has its drawbacks too. For instance if you forget a reference to some
huge object you create an enormous memory leak since the collector can't
free it. Finding out where is that reference can be an incredibly complex
task.

Note that that is a problem for ALL GC's, java, lisp whatever.

== 2 of 10 ==
Date: Tues, Jan 26 2010 12:18 am
From: Nick Keighley

On 26 Jan, 08:04, jacob navia <ja...@nospam.org> wrote:
> gwowen a écrit :

<snip>

> > As ever: There is no silver bullet.
>
> True. GC has its drawbacks too. For instance if you forget a reference to some
> huge object you create an enormous memory leak since the collector can't
> free it. Finding out where is that reference can be an incredibly complex
> task.
>
> Note that that is a problem for ALL GC's, java, lisp whatever.

it has to be, otherwise the garbage collector would have to read your
mind. "ah, I see he has a reference to GiganticDataStructure that he
meant to get rid of. I'll just null it out and re-run gc".

== 3 of 10 ==
Date: Tues, Jan 26 2010 1:32 am
From: gwowen

On Jan 26, 8:04 am, jacob navia <ja...@nospam.org> wrote:
> > But
> > there are perfectly good alternatives, besides manual reference
> > counting. The fact that COM screwed up reference counting, doesn't
> > mean that reference counting is a non-starter.
>
> COM did not "screw it". Reference counting has its drawbacks, that's all.

The IUnknown AddRef() and Release() interface is incredibly brittle
and error prone. Making a programmer manage all the references by
hand is a bad idea. AddRef/Release is to reference counting as malloc
()/free() is to memory. It's not consistent to repeatedly recommend
GC for memory, without spotting that the IUnknown is prone to the same
problem.

As the background mechanism, reference counting is fine -- just like
heap allocation is fine. It is forcing the programmer to manage it by
hand that can frequently lead to errors. It's actually probably worse
for interfaces, because most programmers have an idea who the "owner"
of some memory is, which, in my experience, is not necessarily the
case with Interfaces. Also, leaked memory is easily cleaned up at
process exit time -- that's also not necessarily the case for non-
memory resources.

== 4 of 10 ==
Date: Tues, Jan 26 2010 1:47 am
From: Rob Kendrick

On Tue, 26 Jan 2010 07:26:49 +0100
jacob navia <jacob@nospam.org> wrote:

> Your argument that "it is not part of the text of the standard"
> is just ridiculous. The "C" of the standard is not even able to
> use a directory effectively and there is NO serious software in C
> that uses that minimal subset.

You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
piece of software; one of the fastest scripting languages around. And
written entirely in ANSI C with only a handful of concessions (such as
dlopen to allow for extensions).

It's quite easy to write great, reusable, reliable software components
in ANSI C without reaching for OS-specific extensions.

== 5 of 10 ==
Date: Tues, Jan 26 2010 2:09 am
From: Michael Foukarakis

On Jan 26, 10:04 am, jacob navia <ja...@nospam.org> wrote:
> gwowen a écrit :
>
> > On Jan 26, 6:37 am, jacob navia <ja...@spamsink.net> wrote:
> >> That is why lcc-win proposes a garbage collector, because is the only
> >> sensible solution.
>
> > And what language do you write your garbage collector in? ;)
>
> Boehm's GC is written in plain C. Yes, you can write a GC in C. There
> are a few bits and pieces done in assembly, but for the most part
> everything is in C.
>
> > Garbage collectors clearly have their place, and an (optional) one
> > would be a boon to any language that doesn't have one built in.
>
> True
>
> > But
> > there are perfectly good alternatives, besides manual reference
> > counting. The fact that COM screwed up reference counting, doesn't
> > mean that reference counting is a non-starter.
>
> COM did not "screw it". Reference counting has its drawbacks, that's all.

It's not in any way convenient for the programmer. The fact that all
parties involved have to consistently count references is as error
prone as simply enforcing the proper use of malloc() & free() and
equivalents, and it has led to notoriously hard to find bugs. Even
Microsoft admitted that COM did, in fact, "screw it" which is why they
favoured tracing GC in .NET, so there's no point in trying to defend
its shortcomings. My personal belief is that *manual* reference
counting is still a bad idea - why do it when you can completely
decouple it from the programmer by providing him with a decent memory
manager? That way, everybody wins. And if you can't do that, just let
the poor guy manage malloc() & free(), why burden him/her with a
crippled interface?

> > In many circumstances
> > a smart pointer is preferable to GC, as it gives a programmer greater
> > control over deterministic destruction (RAII works a lot better on
> > managing mutexes than GC, for example -- lock()/unlock() cares about
> > timing in a way malloc()/free() doesn't).
>
> That could be done in C if we had operator overloading, something I have
> been trying to promote for years.

Operator overloading and lots of preprocessor tricks, correct?

This can be a problem with smart pointers as well. Typical example:
shared_ptr between an automatic pointer and a member of a singleton
(seen it a thousand times..).

== 6 of 10 ==
Date: Tues, Jan 26 2010 2:13 am
From: jacob navia

Rob Kendrick a �crit :
> On Tue, 26 Jan 2010 07:26:49 +0100
> jacob navia <jacob@nospam.org> wrote:
>
>> Your argument that "it is not part of the text of the standard"
>> is just ridiculous. The "C" of the standard is not even able to
>> use a directory effectively and there is NO serious software in C
>> that uses that minimal subset.
>
> You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> piece of software; one of the fastest scripting languages around. And
> written entirely in ANSI C with only a handful of concessions (such as
> dlopen to allow for extensions).
>
Sure, then graphics, network, and whatever are done by loading

AN EXTERNAL LIBRARY

That is the same as with C. You link in C statically (or dynamically)
but you can't do any network/graphics/dynamic loading/you-name-it
without having to use external libraries what was my point!

> It's quite easy to write great, reusable, reliable software components
> in ANSI C without reaching for OS-specific extensions.
>
> B.

Of course. Then you use dlopen to load all the OS-specific components!
You have just confirmed what I said:

Using ONLY the minimum mentioned in the standard you can't use directories
graphics, network and many other things that are essential today.

The standard is just a common minimum and a program that uses standard
libraries is written in C and uses extensions like (for instance) a GC.

== 7 of 10 ==
Date: Tues, Jan 26 2010 2:35 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <hjm2j9$52l$1@speranza.aioe.org>,
jacob navia <jacob@jspamsink.org> wrote:

>That is why lcc-win proposes a garbage collector, because is the only
>sensible solution.

Is your garbage collector adequate for heavily recursive
functional-style programming? You probably also need good
tail-recursion optimisation. TRO may help garbage collection
if it removes stack frames that would otherwise "hold on" to
garbage.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

== 8 of 10 ==
Date: Tues, Jan 26 2010 3:00 am
From: Richard Heathfield

jacob navia wrote:
> Stefan Ram a �crit :
>>
>> C does not have a garbage collector.
>>
>
> Many things are left for system libraries, like graphics, network,
> garbage collectors, and many other things like (for instance)
> directory access, thread management, multiprocessing etc.

Right.

> All of this can be done in C if you do not arbitrarily restrict
> the language to the minimal subset as you are trying to do here.

Sure. Nevertheless, if one does not restrict oneself in that way, one
gives up a certain degree of portability - the fewer restrictions one
places on what third-party features one accepts, the less portable one's
code. It seems that you don't place a high value on portability, since
you've basically selected one platform (possibly two) and stuck to it
(them). Not everybody has that freedom.

> I have promoted and distributed a garbage collector for C since
> several years. People like you (and the other "regs") have always
> fought this, so your attitude is not surprising.

Nobody has fought your distribution of a GC. It is true that people in
this newsgroup have objected to your using it as a dumping ground for
advertisements. But if you were to promote it in appropriate channels,
e.g. your web site, nobody could reasonably object to that.

> What is surprising is that now you refuse even to acknowledge that
> a widely distributed implementation of gc exists, and it is used.

He isn't refusing to acknowledge that garbage collectors exist. He's
arguing that C doesn't have one. It doesn't. *You* have one. Your
implementation may well provide one, as an extension. But C itself does
not have one.

> Your argument that "it is not part of the text of the standard"
> is just ridiculous.

No, it's a rational stance.

> The "C" of the standard is not even able to
> use a directory effectively

Perhaps you're not aware that directories are not a universal feature of
filesystems. C has to be able to work on systems where directories
either don't exist at all, or work very differently to what you're used
to. (I can think of at least three, two of which I would call major
commercial systems. The third is Pick, and failing to acknowledge it as
major may be a touch unfair on it. There are probably more than I can
bring to mind, of course.)

> and there is NO serious software in C that uses that minimal subset.

If you define "serious software" as "software that uses extensions",
you're right. It's hard to see in what other way you could be right. I
write pretty serious software in C pretty often, and I write it in that
subset you so disdain. When I do need extensions, which is rare but not
unheard of, they go into their own module in their own wrapper, so that
I can easily find the bits I need to re-write for each new system.

> With your attitude there is no software written in C.

Your reliance on extensions is not an imposition on other people's
ability to cope without them, or to abstract them into isolated modules.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 9 of 10 ==
Date: Tues, Jan 26 2010 3:04 am
From: ld

On Jan 26, 4:47 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> ld <laurent.den...@gmail.com> writes:
> >>>You don't need a GC, just a richer set of ownership rules.
> >>Yes, please give me the URI of this set!
> >http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos-draft-dls09.pdf
>
> This seems to be a library that either uses garbage collection
> or user aided reference counting.

Not a gc but a "kind of reference counting"

There is a difference between reference counting and ownership. The
latter rely on "extended" reference counting to manage automatic
object and static object and should not retain an object referenced
but not owned: e.g. graph's nodes are not retained while graph's
elements are retained. So in practice correct management ownership
means that you stick to DAGs, yes. But there is languages (e.g.
Haskell) where you can only create DAGs, and it doesn't limit their
capabilities.

> I was hoping for ownership rules for plain C objects or
> linked C data structures.

I don't see the problem to turn structure into objects (in the OO
sens).

> C does not have a garbage collector.

Boehm gc. But GCs have other problems:

- memory overhead
- non deterministic finalization
- hidden change in algorithm complexity
- tuned for some "classical use" but could be inefficient for
unexpected cases
- ...

> A reference counter is an additional subobject that must be
> added to all objects to be managed in this way.

Right. And as far you have to manage objects (in the OO sens), you
will have to do it in one way or another, this is inherent to objects
with dynamic lifetime. As you will have to bound objects to their
class in OO class-based model.

> This URI list rules for reference counting with COM (using
> "AddRef" and "Release"):
>
> http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting
>
> And this URI lists some of the problems with reference counting:
>
> http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting_2

But ownership means no cycle. Two objects cannot _own_ each other. If
you fall into such case, it's probably because the design (or the
understanting of ownership) is incorrect and need to lifting (e.g.
introduce a manager for these objects). Brute reference counting is
dangerous, yes, but ownership isn't. Unfortunately, many programmers
don't make the difference.

> Another URI:
>
> "Bugs caused by incorrect reference counting in COM
> systems are notoriously hard to resolve"

My rules are _local_ (same scope) so I never have incorrect reference
counting.

a+, ld.

== 10 of 10 ==
Date: Tues, Jan 26 2010 3:15 am
From: ld

On Jan 26, 4:04 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Anyway I came late into this thread,

we all came late, the thread started in 2008 ;-)

> but I don't think anyone was
> proposing to embed Haskell as cpp macros or anything like that ;-).

I did something close with COS because once you have implemented loop
in cpp, you get a functional language (with gc) ;-) So I get things
like map, foldl, foldr, filter, etc...

See chaos-pp on sourceforge for a serious lib like this, mine is
focused (and limited) for COS.

> The
> idea is just that it's possible for one's C programs to be influenced by
> functional style, and to implement some nontrivial functional constructs
> through a few coding disciplines supported by some utility functions.

Right. The library of COS is mainly written in a functional style
inspired by Haskell. For example, you can look at

http://cos.cvs.sourceforge.net/viewvc/cos/CosStd/include/cos/gen/algorithm.h?view=markup

where each generic function (in the CLOS sens) with a 'fun' parameter
expect a functor (closure).

cheers,

ld.

==============================================================================
TOPIC: Getting the size of a C function
http://groups.google.com/group/comp.lang.c/t/dcc5cb3c26da8f6f?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 12:14 am
From: David Brown

On 25/01/2010 21:42, Jon Kirwan wrote:
> On Mon, 25 Jan 2010 13:13:37 +0100, David Brown
> <david@westcontrol.removethisbit.com> wrote:
>
>> On 25/01/2010 11:26, Jon Kirwan wrote:
>>> On Mon, 25 Jan 2010 10:21:59 +0100, David Brown
>>> <david@westcontrol.removethisbit.com> wrote:
>>>
>>>> On 25/01/2010 00:19, Jon Kirwan wrote:
>>>>> <snip>
>>>>> You give me a great way to segue into something. There are
>>>>> cases where you simply have no other option than to do
>>>>> exactly that. I'll provide one example. There are others.
>>>>
>>>> In embedded development, /every/ rule has an exception, except this one :-).
>>>
>>> :)
>>>
>>>> There are definitely times when you have to manually check your outputs,
>>>> or write code that only works with specific compiler options, or add
>>>> assembly code hacks that rely on details of the compiler working. But
>>>> you don't do it unless you have no better way - you certainly don't
>>>> design in your hacks at the first step.
>>>
>>> Just to be argumentative (no other good reason, really), one
>>
>> Being argumentative /is/ a good reason if it makes us think.
>>
>>> of my applications requires equal execution times across two
>>> code edges. In other words, the execution time must be
>>> constant regardless which branch is taken. c doesn't provide
>>> for that, quite simply. So the very first thing I do porting
>>> this application to a new processor is to ensure that I can
>>> achieve this well, or if not, exactly what the variability
>>> will be (because I must then relax the clocking rate to
>>> account for it.) It's one of those unknowns that must be
>>> locked down, immediately.
>>>
>>> So yes, I hack at the very first step in this case. But I'm
>>> just toying. In general, I take your point here.
>>
>> That's an example of when you need special consideration. My point is
>> that you only do that sort of thing if you have no better way to
>> implement the required functionality.
>
> Understood, and agreed.
>
>>> .....
>>>
>>> As an aside, one of the first things I may do with a new c
>>> compiler and target is to explore methods to support process
>>> semantics. The c language doesn't provide quite a number of
>>> very useful semantics, this being one of them.
>>>
>>> (Another I enjoy the use of is named, link-time constants.
>>> They are not variable instances, in case you are confused
>>> about my wording here. Instead, they are much like #define
>>> in c except that these constants are link-time, not compile-
>>> time, and if you change them there is no need to recompile
>>> all the c code that uses them. You just change one file that
>>> creates those constants and re-link. The linker patches in
>>> the values, directly. Saves recompile time. Probably every
>>> assembler supports them, and every linker _must_ support
>>> them. But c does not provide syntax to access the semantic
>>> that is available in its own linker.)
>>
>> Are you talking about using constants in your code which are evaluated
>> at link time, much in the way that static addresses are handled? Maybe
>> I've misunderstood you, but that strikes me as a poor way to handle what
>> are really compile-time constants - it's bad modularisation and
>> structure (sometimes a single file is the best place to put these
>> constants - but it should be because that's the best place, not because
>> you want to fit some weird way of compiling). It is highly
>> non-standard, potentially leading to confusion and maintenance issues.
>> It also limits the compiler's options for optimising the code. And if
>> re-compilation time is a serious issue these days, you need to consider
>> getting better tools (PC and/or compiler), or making better use of them
>> (better makefile setup, or use ccache).
>>
>> Of course, it is always fun getting your tools to do interesting things
>> in unusual ways - but it's not always a good idea for real work.
>
> Well, you are of course correct in the sense that a specific
> constant value shouldn't be scattered throughout a series of

Constant values should, like everything else, be declared and defined in
the place that makes most sense for the structure of the program. That
may mean just locally within a module or function, or in a module's
header file, in a program-global header, or occasionally declared in a
header and defined in an implementation file (for better data hiding,
though perhaps missed optimisation opportunities). So the only rule
here is to put them in the right place for the program, not just because
it shaves a quarter second off the re-compile time.

> modules like casting dust to the winds. It's not a good
> idea. Your point is wisely made. However, you are also
> wrong in suggesting, once again, some absolute rule that
> _always_ applies. In this case, my point remains because

Rules in embedded development are never absolute - we have both said as
much in this thread. But there are plenty of rules, written and
unwritten, that are strong enough to state as though they always apply.
If you feel you need to break them, you do so when you have clear and
reasoned arguments why your software will be better with the rule broken.

> there is _some_ need for the semantic. It doesn't matter if
> there are better ways for most things, if there are some
> times a need for this semantic.
>
> I think you understood me, correctly. Just in case there is
> any question at all, I'm talking about this semantic, if you
> are familiar with the Microsoft assembler:
>
> QUANTUM EQU 47
> PUBLIC QUANTUM
>
> You can't do that in c. There is no syntax for it.
>

I can't imagine a time when I would need to do that, or any problem it
might solve. Sometimes you want symbols that are defined at the linker
level to be exported to C - the start and end of a section, for example
- but I don't see any reason to pass constants around within the C
program itself in this way. I suppose you might have an assembly module
which exports constants that you then want to use in C, but it would be
better to use a common #define that is available to both C code and the
assembly code.

> In the above example, this constant might be the default
> number of timer ticks used per process quantum in a round
> robin arrangement. But as you say, you are correct to
> suggest that this kind of value usually only needs placement
> in a single module, so the advantage may arguably be reduced
> to a theoretical one, not a practical one. (Though I suppose
> I could always posit a specific case where this QUANTUM might
> be used in several reasonable places.)
>

Can you give me an example in which this is actually a required way to
handle such constants? As I said above, you could have "#define QUANTUM
47" in a header that is included by both the C code and assembly code as
needed. (And if your assembler doesn't like that sort of syntax, get a
better assembler. If that fails, between the C preprocessor and the
assembler's macro capabilities, you should be able to concoct a common
way of including the constants. And if that also fails, write a script
that is called by your Makefile and generates the required headers and
include files.)

> However, there are times where there are values which may be
> required in several modules. These may be field masks and
> init values, for example, of hardware registers or software
> control flags. It's not always the case that writing a
> specific subroutine to compose them for you is the better
> solution. Sometimes, it's better to expose the constants,
> broadly speaking, and use them in a simple, constant-folding,
> c language way. Libraries in c are riddled with these.
>

I agree entirely that exposing the global constants is often the best
way of using such values - I hate these silly little "accessor"
functions people write because they think that global data (variable or
constant) is somehow "bad", and it's better to write an inefficient and
unclear global function instead. But your constants should be available
to the compiler at compile time if at all possible - having them
available only at link time wastes your compiler's strengths.

> In addition, these public link-time constants can be used to
> conditionally include or exclude code sections. In fact,
> almost every compiler uses this fact in one way or the other.
> CRT0, in particular, may take advantage of such features to
> conditionally include or exclude initialization code for
> libraries which may, or may not, have been linked in. And
> most linkers support the concept in some fashion -- because
> it is needed.
>
> And yes, I'd sometimes like c-level access to it.
>

On devices for which I write my own CRT0 or other pre-C startup code, I
write it in C. Typically there's a couple of lines of assembly to set
the stack pointer and jump to the C startup function, but things like
clearing .bss and copying .data are all done in C. If I wanted sections
that may or may not be included, I'd use C - either with #if's, or by
relying on the compiler to eliminate dead code. And some symbols, such
as section start and end points, are passed from the linker into the C
code - but only those that /must/ be passed in that way.

>>> With cooperative switching (and I use that where possible,
>>> because it is much easier to implement and support) I may be
>>> able to write fairly simple routines in assembly to support
>>> it (a dozen lines, or two.) But there is no escaping the
>>> idea that whatever I do there relies on details about the
>>> compiler. Different compilers on the MSP430, for example,
>>> make different choices about register assignments, which must
>>> be preserved across calls, which are scratchable, and which
>>> are used to optionally pass parameters (and the conditions
>>> under which registers may be chosen to pass them.)
>>
>> Yes, these are more examples of where you need to work with the compiler
>> details.
>
> Yes. No question.
>
>>> With pre-emptive switching, it opens up a Pandora's box.
>>> Library routines that may use static memory, for example. But
>>> if pre-emptive switching is a part of the product, then I
>>> face the problems squarely and usually up front in the
>>> development. It's crucial to know exactly what works and how
>>> well it works, right away.
>>>
>>> I also enjoy the use of coroutine thunking, from time to
>>> time. This, and process semantics, make for clear, very
>>> readable code that works well and is able to be maintained by
>>> a broader range of programmers (so long as they don't try and
>>> rewrite the core o/s code, of course.)
>>>
>>> I still take your point. But I hope you don't mind a small
>>> moment of banter just to add to your suggestion that every
>>> rule has exceptions, including the rule of not hacking things
>>> at the outset. ;)
>>>
>>>> Another rule for embedded development is always know your tools, and
>>>> preferably pick /good/ tools. Microchip are known to be good for many
>>>> things - the quality of their 16-bit PIC C compilers is definitely not
>>>> one of them.
>>>> <snip>
>>>
>>> Well, there is that. I cannot defend their use of _static_
>>> memory for compiler temporaries, as they chose to do. It's
>>> unconscionable. Their argument to me (one or two of those
>>> who actually _wrote_ its code) was that it led to faster
>>> emitted code -- in short, it appeared to show off their parts
>>> better. And they felt they "had it covered."
>>
>> It is certainly perfectly possible to use static memory for compiler
>> temporaries, and it will certainly be faster than the normal alternative
>> (temporaries on a stack) for many small processors. But it has to be
>> implemented correctly!
>
> Well, _if_ one is going to use statics _then_ of course it
> has to be implemented correctly! Who could argue otherwise?
>

Apparently the quality controllers and testers of your particular
compiler would argue otherwise!

> The problem is in the _doing_ of that. It requires (or at
> least I imagine so, right now, being ignorant of a better
> way) looking at the entire program block to achieve. And
> that is a bit of a step-change away from the usual c compiler
> mode of operation. It _might_ be implemented in the linker
> stage, I suppose. Though I'm struggling to imagine something
> a little less than a Rube Goldberg contraption to get there
> in the linker side.
>

It certainly isn't an easy problem to use statics for temporary data in
a way that makes efficient use of memory - and of course, in a way that
is safe and correct. I'm sure Walter Banks could tell you all about it
(though he might consider it a trade secret).

>>> Well, they were wrong and a false bargain was made.
>>>
>>> I'm sure they aren't the only ones guilty of choosing to sell
>>> the smell of sizzle over the quality of meat, though. Not by
>>> a long shot.
>>>
>>> Jon
>
> As an aside, I have a lot of other things I'd like in c or
> c++ which just aren't there. For example, I dearly miss
> having access to thunking semantics in c or c++ (which does
> NOT break the c/c++ program model in any way, shape, or form
> and could easily be implemented as part of either language
> with no dire impacts at all. I might use this for efficient
> iterators (don't imagine that I'm talking about std library
> iterators here, which are somewhat similar in use but in no
> way similar in their implementation details -- they are much
> less efficient), so also do I miss this. There is no good
> reason I can think of not to have it and its utility is
> wonderful. (I'd be so happy to talk about it, at some point,
> as the examples are excellent and easily shown.)
>

What do you mean by "thunking" in this context? The term has several
meanings, as far as I know. If your answer is going to take more than a
dozen lines (you are better known for your in-depth explanations than
your short summaries!), it should probably be in its own thread.

mvh.,

David

== 2 of 2 ==
Date: Tues, Jan 26 2010 2:58 am
From: Jon Kirwan

On Tue, 26 Jan 2010 09:14:50 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

>On 25/01/2010 21:42, Jon Kirwan wrote:
>> On Mon, 25 Jan 2010 13:13:37 +0100, David Brown
>> <david@westcontrol.removethisbit.com> wrote:
>>
>>> On 25/01/2010 11:26, Jon Kirwan wrote:
>>>> On Mon, 25 Jan 2010 10:21:59 +0100, David Brown
>>>> <david@westcontrol.removethisbit.com> wrote:
>>>>
>>>>> On 25/01/2010 00:19, Jon Kirwan wrote:
>>>>>> <snip>
>>>>>> You give me a great way to segue into something. There are
>>>>>> cases where you simply have no other option than to do
>>>>>> exactly that. I'll provide one example. There are others.
>>>>>
>>>>> In embedded development, /every/ rule has an exception, except this one :-).
>>>>
>>>> :)
>>>>
>>>>> There are definitely times when you have to manually check your outputs,
>>>>> or write code that only works with specific compiler options, or add
>>>>> assembly code hacks that rely on details of the compiler working. But
>>>>> you don't do it unless you have no better way - you certainly don't
>>>>> design in your hacks at the first step.
>>>>
>>>> Just to be argumentative (no other good reason, really), one
>>>
>>> Being argumentative /is/ a good reason if it makes us think.
>>>
>>>> of my applications requires equal execution times across two
>>>> code edges. In other words, the execution time must be
>>>> constant regardless which branch is taken. c doesn't provide
>>>> for that, quite simply. So the very first thing I do porting
>>>> this application to a new processor is to ensure that I can
>>>> achieve this well, or if not, exactly what the variability
>>>> will be (because I must then relax the clocking rate to
>>>> account for it.) It's one of those unknowns that must be
>>>> locked down, immediately.
>>>>
>>>> So yes, I hack at the very first step in this case. But I'm
>>>> just toying. In general, I take your point here.
>>>
>>> That's an example of when you need special consideration. My point is
>>> that you only do that sort of thing if you have no better way to
>>> implement the required functionality.
>>
>> Understood, and agreed.
>>
>>>> .....
>>>>
>>>> As an aside, one of the first things I may do with a new c
>>>> compiler and target is to explore methods to support process
>>>> semantics. The c language doesn't provide quite a number of
>>>> very useful semantics, this being one of them.
>>>>
>>>> (Another I enjoy the use of is named, link-time constants.
>>>> They are not variable instances, in case you are confused
>>>> about my wording here. Instead, they are much like #define
>>>> in c except that these constants are link-time, not compile-
>>>> time, and if you change them there is no need to recompile
>>>> all the c code that uses them. You just change one file that
>>>> creates those constants and re-link. The linker patches in
>>>> the values, directly. Saves recompile time. Probably every
>>>> assembler supports them, and every linker _must_ support
>>>> them. But c does not provide syntax to access the semantic
>>>> that is available in its own linker.)
>>>
>>> Are you talking about using constants in your code which are evaluated
>>> at link time, much in the way that static addresses are handled? Maybe
>>> I've misunderstood you, but that strikes me as a poor way to handle what
>>> are really compile-time constants - it's bad modularisation and
>>> structure (sometimes a single file is the best place to put these
>>> constants - but it should be because that's the best place, not because
>>> you want to fit some weird way of compiling). It is highly
>>> non-standard, potentially leading to confusion and maintenance issues.
>>> It also limits the compiler's options for optimising the code. And if
>>> re-compilation time is a serious issue these days, you need to consider
>>> getting better tools (PC and/or compiler), or making better use of them
>>> (better makefile setup, or use ccache).
>>>
>>> Of course, it is always fun getting your tools to do interesting things
>>> in unusual ways - but it's not always a good idea for real work.
>>
>> Well, you are of course correct in the sense that a specific
>> constant value shouldn't be scattered throughout a series of
>
>Constant values should, like everything else, be declared and defined in
>the place that makes most sense for the structure of the program. That
>may mean just locally within a module or function, or in a module's
>header file, in a program-global header, or occasionally declared in a
>header and defined in an implementation file (for better data hiding,
>though perhaps missed optimisation opportunities). So the only rule
>here is to put them in the right place for the program, not just because
>it shaves a quarter second off the re-compile time.
>
>> modules like casting dust to the winds. It's not a good
>> idea. Your point is wisely made. However, you are also
>> wrong in suggesting, once again, some absolute rule that
>> _always_ applies. In this case, my point remains because
>
>Rules in embedded development are never absolute - we have both said as
>much in this thread. But there are plenty of rules, written and
>unwritten, that are strong enough to state as though they always apply.
> If you feel you need to break them, you do so when you have clear and
>reasoned arguments why your software will be better with the rule broken.
>
>> there is _some_ need for the semantic. It doesn't matter if
>> there are better ways for most things, if there are some
>> times a need for this semantic.
>>
>> I think you understood me, correctly. Just in case there is
>> any question at all, I'm talking about this semantic, if you
>> are familiar with the Microsoft assembler:
>>
>> QUANTUM EQU 47
>> PUBLIC QUANTUM
>>
>> You can't do that in c. There is no syntax for it.
>>
>
>I can't imagine a time when I would need to do that, or any problem it
>might solve. Sometimes you want symbols that are defined at the linker
>level to be exported to C - the start and end of a section, for example
>- but I don't see any reason to pass constants around within the C
>program itself in this way. I suppose you might have an assembly module
>which exports constants that you then want to use in C, but it would be
>better to use a common #define that is available to both C code and the
>assembly code.
>
>> In the above example, this constant might be the default
>> number of timer ticks used per process quantum in a round
>> robin arrangement. But as you say, you are correct to
>> suggest that this kind of value usually only needs placement
>> in a single module, so the advantage may arguably be reduced
>> to a theoretical one, not a practical one. (Though I suppose
>> I could always posit a specific case where this QUANTUM might
>> be used in several reasonable places.)
>
>Can you give me an example in which this is actually a required way to
>handle such constants? As I said above, you could have "#define QUANTUM
>47" in a header that is included by both the C code and assembly code as
>needed. (And if your assembler doesn't like that sort of syntax, get a
>better assembler. If that fails, between the C preprocessor and the
>assembler's macro capabilities, you should be able to concoct a common
>way of including the constants. And if that also fails, write a script
>that is called by your Makefile and generates the required headers and
>include files.)
>
>> However, there are times where there are values which may be
>> required in several modules. These may be field masks and
>> init values, for example, of hardware registers or software
>> control flags. It's not always the case that writing a
>> specific subroutine to compose them for you is the better
>> solution. Sometimes, it's better to expose the constants,
>> broadly speaking, and use them in a simple, constant-folding,
>> c language way. Libraries in c are riddled with these.
>
>I agree entirely that exposing the global constants is often the best
>way of using such values - I hate these silly little "accessor"
>functions people write because they think that global data (variable or
>constant) is somehow "bad", and it's better to write an inefficient and
>unclear global function instead. But your constants should be available
>to the compiler at compile time if at all possible - having them
>available only at link time wastes your compiler's strengths.
>
>> In addition, these public link-time constants can be used to
>> conditionally include or exclude code sections. In fact,
>> almost every compiler uses this fact in one way or the other.
>> CRT0, in particular, may take advantage of such features to
>> conditionally include or exclude initialization code for
>> libraries which may, or may not, have been linked in. And
>> most linkers support the concept in some fashion -- because
>> it is needed.
>>
>> And yes, I'd sometimes like c-level access to it.
>
>On devices for which I write my own CRT0 or other pre-C startup code, I
>write it in C. Typically there's a couple of lines of assembly to set
>the stack pointer and jump to the C startup function, but things like
>clearing .bss and copying .data are all done in C. If I wanted sections
>that may or may not be included, I'd use C - either with #if's, or by
>relying on the compiler to eliminate dead code. And some symbols, such
>as section start and end points, are passed from the linker into the C
>code - but only those that /must/ be passed in that way.

Let's just leave it here as an agreement to disagree, then. I
believe you are sincere in considering what I've already
written, probably doing me more justice than I may deserve.
But since you still cannot gather, I have to assume it's my
fault in writing poorly and that the effort may require more
time than I care to have for a semantic only of some small
value. We've already made more of it than the newsgroup's
time is worth. So I'm fine leaving the topic behind and just
saying that I have used the semantic before to good use and
sometimes miss it in c. There's no payoff here. Let's just
leave it as a mild disagreement over a not-terribly-important
issue.

>>>> With cooperative switching (and I use that where possible,
>>>> because it is much easier to implement and support) I may be
>>>> able to write fairly simple routines in assembly to support
>>>> it (a dozen lines, or two.) But there is no escaping the
>>>> idea that whatever I do there relies on details about the
>>>> compiler. Different compilers on the MSP430, for example,
>>>> make different choices about register assignments, which must
>>>> be preserved across calls, which are scratchable, and which
>>>> are used to optionally pass parameters (and the conditions
>>>> under which registers may be chosen to pass them.)
>>>
>>> Yes, these are more examples of where you need to work with the compiler
>>> details.
>>
>> Yes. No question.
>>
>>>> With pre-emptive switching, it opens up a Pandora's box.
>>>> Library routines that may use static memory, for example. But
>>>> if pre-emptive switching is a part of the product, then I
>>>> face the problems squarely and usually up front in the
>>>> development. It's crucial to know exactly what works and how
>>>> well it works, right away.
>>>>
>>>> I also enjoy the use of coroutine thunking, from time to
>>>> time. This, and process semantics, make for clear, very
>>>> readable code that works well and is able to be maintained by
>>>> a broader range of programmers (so long as they don't try and
>>>> rewrite the core o/s code, of course.)
>>>>
>>>> I still take your point. But I hope you don't mind a small
>>>> moment of banter just to add to your suggestion that every
>>>> rule has exceptions, including the rule of not hacking things
>>>> at the outset. ;)
>>>>
>>>>> Another rule for embedded development is always know your tools, and
>>>>> preferably pick /good/ tools. Microchip are known to be good for many
>>>>> things - the quality of their 16-bit PIC C compilers is definitely not
>>>>> one of them.
>>>>> <snip>
>>>>
>>>> Well, there is that. I cannot defend their use of _static_
>>>> memory for compiler temporaries, as they chose to do. It's
>>>> unconscionable. Their argument to me (one or two of those
>>>> who actually _wrote_ its code) was that it led to faster
>>>> emitted code -- in short, it appeared to show off their parts
>>>> better. And they felt they "had it covered."
>>>
>>> It is certainly perfectly possible to use static memory for compiler
>>> temporaries, and it will certainly be faster than the normal alternative
>>> (temporaries on a stack) for many small processors. But it has to be
>>> implemented correctly!
>>
>> Well, _if_ one is going to use statics _then_ of course it
>> has to be implemented correctly! Who could argue otherwise?
>
>Apparently the quality controllers and testers of your particular
>compiler would argue otherwise!

I think they simply didn't see it, before. A failure to
imagine as well as they should have done. Nothing more.

>> The problem is in the _doing_ of that. It requires (or at
>> least I imagine so, right now, being ignorant of a better
>> way) looking at the entire program block to achieve. And
>> that is a bit of a step-change away from the usual c compiler
>> mode of operation. It _might_ be implemented in the linker
>> stage, I suppose. Though I'm struggling to imagine something
>> a little less than a Rube Goldberg contraption to get there
>> in the linker side.
>
>It certainly isn't an easy problem to use statics for temporary data in
>a way that makes efficient use of memory - and of course, in a way that
>is safe and correct. I'm sure Walter Banks could tell you all about it
>(though he might consider it a trade secret).

I'm sure he knows a great deal more about the complexities
than I do, so you are most certainly right that he could tell
me about the subject. I've never claimed expertise here.
Merely the ability to observe specific failures when I see
poor results from poorly imagined solutions.

>>>> Well, they were wrong and a false bargain was made.
>>>>
>>>> I'm sure they aren't the only ones guilty of choosing to sell
>>>> the smell of sizzle over the quality of meat, though. Not by
>>>> a long shot.
>>>>
>>>> Jon
>>
>> As an aside, I have a lot of other things I'd like in c or
>> c++ which just aren't there. For example, I dearly miss
>> having access to thunking semantics in c or c++ (which does
>> NOT break the c/c++ program model in any way, shape, or form
>> and could easily be implemented as part of either language
>> with no dire impacts at all. I might use this for efficient
>> iterators (don't imagine that I'm talking about std library
>> iterators here, which are somewhat similar in use but in no
>> way similar in their implementation details -- they are much
>> less efficient), so also do I miss this. There is no good
>> reason I can think of not to have it and its utility is
>> wonderful. (I'd be so happy to talk about it, at some point,
>> as the examples are excellent and easily shown.)
>
>What do you mean by "thunking" in this context? The term has several
>meanings, as far as I know. If your answer is going to take more than a
>dozen lines (you are better known for your in-depth explanations than
>your short summaries!), it should probably be in its own thread.

There are some excellent discussions already available. See,
for example, the Metaware C (and Pascal) compiler manuals and
their implemention of an iterator semantic, as well as their
extensive discussion (with well-made examples) of its
abundant benefits. There is also a somewhat different, but
also interesting discussion made by Randall Hyde in The Art
of Assembly manuals he generously put together some years
back. (Don't worry yourself thumbing through Microsoft's use
of the term.)

...

The following case below is not nearly as well thought out,
syntax wise, as Metaware's implementation (in other words,
don't mistake it as a complete syntax designed by experts)
but it may get the seed of a point across.

for ( p in Primes( 20, 70 ) )
printf( "%d\n", p );

The code for Primes() might be, in short-hand, something like
this below. (Please excuse my abuse of basic knowledge about
prime numbers by using an increment by 1 in the for loop or
any other tests for starting or ending on an even number only
because I want to keep the code with as few lines as is
reasonable to make the point. The idea is the point, not the
implementation here.)

integer Primes( int a, int b ) {
int i;
for ( i= a; i <= b; ++i )
if ( IsPrime( i ) )
yield( i );
return;
}

I'm intentionally being brief, as well as leaving out a short
discussion of each line. Partly, because longer examples may
interfere with the central points. Partly, because you
shouldn't need any discussion and should be able to almost
instantly see what the above code "means" without that extra.
It's in a form that should be plain without a manual.

The place to focus isn't so much on examining Primes(), but
instead more by imagining a wide variety of the types of
for() loops which may require the mechanism itself. (Not my
poor example, which may or may not be useful to anyone.)

For example, you might prefer to imagine that Primes() is
instead a routine that yields all the nodes of some arbitrary
tree or graph using some very specific walking mechanism. If
you use your imagination and let it take you for a ride, then
perhaps the point may be clarified.

If that gets you towards where I'm pointing, then the next
question is how would you implement this in assembly code,
consistent with c compilers you are aware of and in such a
way that does _not_ break an existing linker in the process?

On the other hand, if this doesn't do it for you at all -- if
in short, your imagination isn't moved by those examples
beyond the short distance I walked with them -- then let me
commend again Metaware's c/pascal implementations and Hyde's
AofA documentation before further discussion continues.

But less than the above made my imagination literally spin
with ideas when I first came across it. So maybe the above
is enough. I hope so. It's also closely connected in a
round about way to the idea of nested functions, aka Pascal.
(If you see the connection, then I think you've probably got
the larger picture.)

Jon

==============================================================================
TOPIC: ◈•_•◈wholesale cheap fashionable Jeans etc at www.ecyaya.com
http://groups.google.com/group/comp.lang.c/t/3773026ec606a642?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 1:03 am
From: hero

◈•_•◈wholesale cheap fashionable Jeans etc at www.ecyaya.com

wholesale cheap Affliction Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Ed Hardy Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Armani Jean with high quality and low price at www.ecyaya.com

wholesale cheap Christian Audigier Jean with high quality and low
price at www.ecyaya.com

wholesale cheap Akademiks Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Bape Jean with high quality and low price at www.ecyaya.com

wholesale cheap Black Label Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Coogi Jean with high quality and low price at www.ecyaya.com

wholesale cheap Crown Holder Jean with high quality and low price at
www.ecyaya.com

wholesale cheap D&G Jean with high quality and low price at www.ecyaya.com

wholesale cheap Diesel Jean with high quality and low price at www.ecyaya.com

wholesale cheap Ecko Unltd Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Evisu Jean with high quality and low price at www.ecyaya.com

wholesale cheap G-Star Jean with high quality and low price at www.ecyaya.com

wholesale cheap Gucci Jean with high quality and low price at www.ecyaya.com

wholesale cheap Iceberg Jean with high quality and low price at www.ecyaya.com

wholesale cheap Jack&Jones Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Justcavalli Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Kanji Jean with high quality and low price at www.ecyaya.com

wholesale cheap LEVI'S Jean with high quality and low price at www.ecyaya.com

wholesale cheap LRG Jean with high quality and low price at www.ecyaya.com

wholesale cheap LV Jean with high quality and low price at www.ecyaya.com

wholesale cheap Rock Jean with high quality and low price at www.ecyaya.com

wholesale cheap True Relig Jean with high quality and low price at
www.ecyaya.com

wholesale cheap Versace Jean with high quality and low price at www.ecyaya.com

== 2 of 2 ==
Date: Tues, Jan 26 2010 1:03 am
From: hero