----- Original Message -----
From: Gerhard Fiedler <lists@connectionbrazil.com>
To: Microcontroller discussion list - Public. <piclist@mit.edu>
Sent: Sunday, January 09, 2005 1:36 PM
Subject: Re: [PIC]: Assembly Language Integration with HI-TECH C


> Sergio Masci wrote:
>
> [fullquote snipped]
>
> >> Sergio Masci wrote:
> >>> XCSB uses a static stack and it identifies sections of the call tree
> >>> that are used by the main line and also the ISR. It peels off a
> >>> seperate static stack and generates safe efficient code where there is
> >>> a conflict.
> >>
> >> Except for being automatic, this sounds pretty much like what all static
> >> stack compilers would need to do.
> >
> > This is a pretty dismissive statement that belies the effort involed in the
> > achivement.
>
> Why is that? Sorry if it came over this way, but that's not what I wrote. I
> think the handling of a static stack is quite an achievement, and didn't
> "belie" this. I also think that doing it automatically is quite a nice
> feature, and didn't belie that either.
>
> > You note yourself that a programmer must manually keep track of which
> > functions are used by the ISR ...
>
> That's not exactly what I said. PICC handles this kind of semi-automatic:
> it throws (automatically) an error when it detects that a function is part
> of more than one call tree. The resolution of this error is then manual.
>
> > .. and yet you do not seem to realise the benefits of having this done
> > for you by the compiler.
>
> Not sure how you come to that conclusion. Did I step on a toe of yours
> somehow? To be clear, I highly appreciate the work that compiler
> programmers do for me, if the compiler works well. As I do appreciate the
> work of everybody else involved that helps me get my work done well.
>
> > How do you manage a library where functions can be called in either the
> > main line or the ISR, do you have two copies of each function? do you
> > need a special #def to control the call tree for a particular set?
>
> This is not really about how _I_ handle that, it is about how _PICC_
> handles that. (The whole thread was and is about PICC... at least that's
> how I read the subject.)
>
> PICC creates a separate call tree and static stack for main code and each
> interrupt vector. It throws an error when a function is called from more
> than one call tree. The user has the option (through pragma statements in
> the code) to create up to two extra call trees with their own static stack
> that doesn't overlap with the other static stacks. The pragmas associate
> individual functions with either of these two additional call trees.
>
> This solves the local storage/static stack overlap problem. It doesn't
> solve the reentrancy problem: even though their local storage doesn't
> overlap with other functions and thus these functions can be safely called
> from several other call trees, they are still not reentrant. In the case of
> the PICC compiler, it is the user's responsibility to make sure these
> functions don't get interrupted by an interrupt that would call them.
>
> This requirement is the reason why it might not be that bad at all that
> this whole thing is not automatic. After all, without the compiler solving
> the reentrancy problem, it wouldn't be completely automatic anyway and IMO
> would be worse than it is now, by hiding the fact that this function needs
> special treatment (prevent interrupts that would call it).
>
> I guess the compiler could solve that by automatically providing two copies
> of the function(s). Might be a thing to think about. OTOH, it is rare
> enough that it hasn't bothered me too much so far. Providing manually two
> copies of a function is a possible solution.
>
>
> Regarding your question about libraries: in this case you need the source
> code, and you need to modify the functions involved in the library code
> (adding the pragma). Not really a nice thing, and having the linker handle
> that automatically would definitely be an advantage in this situation.
> OTOH, I don't commonly use 3rd party library code in my interrupts, so I
> never had that problem.
>
>
> >>> Furthermore, XCSB supports multitasking natively and it does the same
> >>> thing for functions that clash within the multitasking system. A very
> >>> good argument for building multitasking into the language rather than
> >>> as a bolt-on library :-)
> >>
> >> Even though it can be convenient, I have mixed feelings about that. I've
> >> written some code in Dynamic C, a Z80 compiler with something like an
> >> application framework/multitasking OS built in. ...
>
> > Just to be clear, I have never stated that XCSB is a C compiler.
>
> Neither did I. Neither is Dynamic C... :)  But Dynamic C is a compiler that
> includes features like what could be called built-in multitasking.
>
>
> The following paragraph left me wonder... I didn't really understand what
> you were trying to say.
>
> > There seem to be many C compilers however which do not deserve the name.
Some of
> > them cannot handle structures, have limits on the number of parameters that
can
> > be passed to functions, do not support floating point, cannot pass or return
> > structures, have limits on array dimensions, cannot cope with function
pointers
> > or generate re-enterent code.
>
> There definitely are.
>
> > I am continually amused ...
>
> That's a good thing.
>
> > ... to see people talking about the benefits of using pure C while being
> > blind to all the hard work they actually have to endure just to overcome
> > the limitations of the particular C "compiler" they have tied themselves
> > to.
>
> Not sure what you mean by "people". Anybody in particular? Makes
> discussions easier to call things (and people) by their names.
>
> Not sure what you mean by "pure C", but I assume that you mean standard C,
> following one of the few standards.
>
> Not sure what you mean by "hard work". Could you be more specific? Makes
> discussions easier to call things by their names.
>
> > C is a nice language and I have used it for many years, but C does not
> > give you anything for free and this includes portability. Use whichever
> > language you like but at some stage you will realise that tieing
> > yourself to C is just as silly as tieing yourself to assembler.
>
> Yes, of course. (Here is that word "silly" again in this thread... seems
> hard for some to live without applying it to others.)
>
> I didn't get your point. Could you please rephrase it, specify it? Are you
> argumenting against non-standard C compilers (the first half of the
> paragraph suggested it? Are you argumenting against C (the second half
> suggested this)? Are you argumenting for XCSB (that seems to be the drift)?
> Are you making the point that it was silly for me to choose PICC as my main
> development tool for 12/14 bit core PICs (the last phrase in the context of
> the whole paragraph suggests that)?
>
> Can you say, plain, clear and simple, what you mean -- without talking
> about "many (unspecified) compilers", (unnamed) "people", what these
> unnamed people say (without citations of what they actually said), or
> (unspecified) "hard work" these unnamed people have to endure?
>
> Gerhard

Hi Gerhard,

I am embarrassed that my post went out in the state that it did. Normally when I
respond to a post that upsets me I write a draft, save it, then come back to it
later and re-read it and the original post with a cooler head to ensure that I
have not misread something and that my reply is not over the top.  Because of
this I have gotten into the habit of being very blunt in my first draft and
writing it in a fashion which includes notes to myself to be expanded on later.
On this occasion I was called away from my desk and I sent the draft
accidentally instead of saving it as I intended. It was only hours later that I
realised the mistake. Please note there was no signature at the end of my post.

I have not forgotten the encouragement and good wishes I have received from you
(Gerhard) in the past, and you have not "stepped on my toes".

I felt it was necessary to respond to your post because there are so many people
on this list who are desperate for guidance and these same people could easily
get the wrong impression from your post. It only takes a few people to
misunderstand and repeat an incorrect view to cause me many headaches.

What I should like to say is this:

XCSB supports multiple threads of execution via multiple static stacks. It does
all the work for you identifying which functions are called by which threads and
resolves contention where functions are called by multiple threads. This
includes the main line, the interrupt handler and any other background tasks.
This is unlike many C compilers where the burden of generating efficient
re-entrant code is pushed back onto the programmer. This burden often includes a
huge debugging effort.

I developed XCSB because I wanted to be free to add language features that would
benefit the programmer. I did not want to produce yet another non-standard C
compiler. A consequence of this is the built-in multitasking. This allows the
compiler to generate very efficient code compared to a compiler that implements
multitasking as a bolt-on library.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use




-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist