I haven't tried either. I had a short torture session with ADA, was 
forced to use Pascal, which is anathema to me, with its (fairly) strong 
typing, and have tried many other languages over time, to see if they 
offered me anything I wanted. Oddly enough I like BASIC, especially the 
more structured types like BBC BASIC. VB6 I don't really like, but use 
it occasionally for quick and dirty interface programs. I wouldn't 
consider using BASIC on a micro though. My language of choice on the PC 
is C. When I first started working with PC's (I avoided the PC as a 
retrograde step for many years after its introduction) I wrote in 
assembler, writing all my own device drivers, coopting the BIOS, and 
substituting for most functions. Later I went back to C to write our 
companies management data base, ie accounts, stock control, contact 
lists etc, and used C throughout. For a long time (91 to 94) I used C to 
develop and improve my audio codec, even though processing speed 
requirements meant that it was written in ASM.

I find C too restrictive though on micros. The need for the preprocessor 
highlights many of C's shortcomings. The reasons I don't use it are:-

I like absolute control of everything, especially memory allocation. 
This is an onerous task in C, and varies between compilers.

I like to type switch at will.

C is not designed for bit manipulation. The methods to achieve this in C 
aren't as clear as asm.

In general asm is clearer to read and discern function from than C (most 
C fans will disagree) esppecially when you seen long chains of nested 
parenthesis and pointers, or pages of complex preprocessor directives. 
Even the C experts here regularly argue about the meaning, and the 
different compilers use different methods for many things. This puts the 
lie to the myth of C portability.

I like absolute control of the system initialisation. Sure I can write 
my own version of cstartup, or whatever a particular vendor calls it, 
but that sort of negates the reasons for using a compiler.

To get the best performance out of the MSP430 requires stringent 
management of the registers. I can do this far better than a compiler.

I like C on the PC, but totally despise C++. The function names are 
often longer than the equivalent code in asm.

I am about to venture into philips ARM, and will probably try and start 
out with C, simply because 90% of my code requirement is extremely 
simple, it has just one very short (42 bytes on the MSP430) piece of 
code that is recursively called that needs to be super-efficient, which, 
once the rest is developed, I will convert to asm. The MSP430 just can't 
go fast enough, even at 16MHz, to get the results I need.

So, I'd be interested in any low cost ARM compilers out there.

NOw, finally, although I might be a linguistic luddite, as you hopefully 
have gathered I really do appreciate the efforts you guys make in 
supporting your products. I realise that asm isn't for everybody, and 
don't try and convert people. I love to see the sillies that occur, like 
rolf's post, and some of the other really complex things in C that are 
simple in asm. The simple fact though is that most people are now taught 
C, barely, if ever, are exposed to asm, and probably wouldn't want to be 
involved with the necessary hardware intimacy required to get the best 
from the machine. I'd rather turn people on to the MSP430, whatever the 
language they use, thus guaranteeing the continued development of the 
family. The existence of so many high quality compilers for the family 
serves my needs by attracting  more new users.

Cheers

Al



Paul Curtis wrote:

> Al,
> 
> Have you tried APL?  Or even Perl?  Now, without proper training, those
> are seriously scary.
> 
> Personally, I love Modula-2 but I can't make a business out of it. 
The
> C strain has impetus behind it.  Modula-2 died when it was standardised
> (a failing of the standardisation process, unfortunately, VDM-SL with
> pie-in-the-sky aspirations) whereas C has prospered by codifying
> existing practice and not pushing too far and leaving (gasp!) holes
> where the compiler implementers can play games and taunt each other in
> the playground.
> 
> The C preprocessor should never have been but, boy, is it useful!
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  
> 
> 
>>-----Original Message-----
>>From: onestone [mailto:onestone@ones...] 
>>Sent: 23 November 2004 23:43
>>To: msp430@msp4...
>>Subject: Re: [msp430] How to Auto-generate Unique Labels in C?
>>
>>
>>How I just love the simplicity and clarity of C. The meaning 
>>of the following simply leaps from the page without any 
>>effort at interpretation.
>>
>>:?}
>>
>>Sorry rolf, that was just irresistible.
>>
>>Al
>>
>>rolf.freitag@rolf... wrote:
>>
>>
>>>Hi
>>>
>>>i am using a similar macro for debugging:
>>>
>>>// Debug messages for user and kernel space.
>>>// Preparation because ANSI-/ISO-C99 does not know 
>>
>>__FUNCTION__ (gcc feature).
>>
>>>#   ifndef __FUNCTION__
>>>#      define __FUNCTION__ __func__
>>>#   endif
>>>#   if defined(DeBuG) || defined(DEBUG)
>>>#      ifdef __KERNEL__
>>>#         define mc_DEBUG(fmt, args...) { 
>>
>>(void)printk(KERN_EMERG "mc_DEBUG: \"%s\",
\"%s\", line %d: ", \
>>
>>>        __FILE__, __FUNCTION__, __LINE__); 
>>
>>(void)printk(KERN_EMERG fmt, ## args); }
>>
>>>#      else
>>>#         define mc_DEBUG(fmt, args...) { 
>>
>>(void)fprintf(stderr, "mc_DEBUG: \"%s\",
\"%s\", line %d: ", \
>>
>>>        __FILE__, __FUNCTION__, __LINE__); 
>>
>>(void)fprintf(stderr, fmt, ## args); }
>>
>>>#      endif
>>>#   else
>>>#      define mc_DEBUG(fmt, args...)
>>>#   endif
>>>
>>>and several macros for static and dynamic debug level:
>>>
>>>// same with dynamic debug level
>>>#   if defined(DeBuG) || defined(DEBUG)
>>>#      define mc_debug(debug_level, fmt, args...)\
>>>   if (debug_level >= DEBUG_LEVEL) mc_DEBUG(fmt, ##args);
>>>#   else
>>>#      define mc_debug(debug_level, fmt, args...)
>>>#   endif
>>>
>>>// same with static debug level; expands to no code if not used
>>>#   if ((defined(DeBuG) || defined(DEBUG)) && (DEBUG_LEVEL
<= 0))
>>>#      define mc_debug0(fmt, args...) mc_DEBUG(fmt, ##args);
>>>#   else
>>>#      define mc_debug0(fmt, args...)
>>>#   endif
>>>
>>>...
>>>
>>>In the linux sources you can find hundreds of other and 
>>
>>more simple debug macros.
>>
>>>Rolf
>>>
>>>
>>>msp430@msp4... schrieb am 23.11.04 23:38:35:
>>>
>>>
>>>>Hi Andrew:
>>>>
>>>>#define DoLabel(X) X
>>>>#define MyUniqueLabelMacro() A##DoLabel(__LINE__)
>>>>
>>>>This generates identifiers of the type A<linenumber.  This is
a 
>>>>use-once macro, you can use it exactly once to define a label
but 
>>>>can't use it to reference a label.  If the labels are only
inside 
>>>>compounds, then they are scoped by the compiler so there 
>>
>>are no name clashes possible anyway.
>>
>>>>--
>>>>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk 
>>
>>CrossWorks 
>>
>>>>for MSP430, ARM, and (soon) Atmel AVR processors
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: aekalman [mailto:aek@aek@...]
>>>>>Sent: 23 November 2004 22:28
>>>>>To: msp430@msp4...
>>>>>Subject: [msp430] How to Auto-generate Unique Labels in C?
>>>>>
>>>>>
>>>>>
>>>>>Hi All.
>>>>>
>>>>>This is more of a C-centric, rather than MSP430-specific
question, 
>>>>>but with all the compiler vendors here on-line :) I though
I'd ask 
>>>>>... I think I once saw this done, but I've searched
everywhere and 
>>>>>can't find it.
>>>>>
>>>>>Is there a way / what is the best way to have the compiler 
>>>>>auto-generate lables in C code?
>>>>>
>>>>>In the broadest sense, what I want is to be able to invoke a
macro 
>>>>>and have it create a unique label each time it is invoked,
e.g.
>>>>>
>>>>>#define MyUniqueLabelMacro()      // your wizard code here
>>>>>
>>>>>and use it like this:
>>>>>
>>>>>{
>>>>> ...
>>>>> MyUniqueLabelMacro()
>>>>> ...
>>>>> MyUniqueLabelMacro()
>>>>>}
>>>>>
>>>>>so that it results in
>>>>>
>>>>>{
>>>>> ...
>>>>> auniquelabel:
>>>>> ...
>>>>> anotheruniquelabel:
>>>>>}
>>>>>
>>>>>I can do this manually by explicitly passing a label name to
the 
>>>>>macro, but I would prefer (because the labels are only 
>>
>>used locally, 
>>
>>>>>not outside the scope of any function) to not have to pass
an 
>>>>>argument to the macro. Each such label must be unique,
however, 
>>>>>otherwise (in my experience) many assemblers will choke.
>>>>>
>>>>>I'd like to see a solution in ANSI C only (no in-line
assembly, 
>>>>>etc.), but I'll settle for the latter of the former
isn't possible.
>>>>>
>>>>>I was thinking about something along the lines of using 
>>
>>__FILE__ and 
>>
>>>>>__LINE__, but the filename is likely to cause problems with
its '.'
>>>>>character, etc. ...
>>>>>
>>>>>Thanks for any help.
>>>>>
>>>>>--Andrew E Kalman, Ph.D.
>>>>>aek at pumpkin inc dot com
>>>>>
>>>>> 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>------------------------ Yahoo! Groups Sponsor 
>>>>>--------------------~--> Make a clean sweep of pop-up
ads.
>>>>>Yahoo! Companion Toolbar.
>>>>>Now with Pop-Up Blocker. Get it for free!
>>>>>http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/CFFolB/TM
>>>>>--------------------------
>>>>>------~->
>>>>>
>>>>>.
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>
>>
>>
>>------------------------ Yahoo! Groups Sponsor 
>>--------------------~-->
>>$9.95 domain names from Yahoo!. Register anything.
>>http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/CFFolB/TM
>>--------------------------
>>------~-> 
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Richard, 

> You have one choice, from yours truly :-) STD for
$199, ADV 
> for $349 with Thumb support, PRO for $749 with Global Optimizer.

Does it do code factoring?  That lr is a pesky little s**te, isn't it?
;-)

> Or GNU, I bet you are a GNU fan -- not!
Nevertheless, Paul 
> has his usual good IDE on top of GNU, so if you are going to 
> pay someone for a GNU based compiler w/ IDE, you may as well 
> patronize Paul.

I'm considering, but only just considering, writing a Thumb compiler.
Many devices are now Thumb-optimized and the Cortex-M3 looks like a good
target for such a thing (depending on what Thumb-2 is).  There were good
reasons to base CrossWorks for ARM on GNU (not least of which was that I
didn't have to write an ARM code generator *again* and a Thumb code
generator *as well*).  Thus, CrossWorks for Thumb might appear featuring
all the bells and whistles, but who knows?

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  

You have one choice, from yours truly :-) STD for $199, ADV for $349 with 
Thumb support, PRO for $749 with Global Optimizer.

Or GNU, I bet you are a GNU fan -- not! Nevertheless, Paul has his usual 
good IDE on top of GNU, so if you are going to pay someone for a GNU based 
compiler w/ IDE, you may as well patronize Paul.

At 04:42 PM 11/23/2004, onestone wrote:
>...
>
>So, I'd be interested in any low cost ARM compilers out there.

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

It isn't something I could ever imagine wanting, let alone see as
desirable.

Firstly every label I use has meaning. The very thought of arbitrary 
labels is wrong to me.

Secondly in all the time I've written in C (although I wouldn't
consider 
myself an expert I do consider myself proficient) I've never had a need 
for an internal label in a function that I can recall. This suggests 
that Andrews need is more than just esoteric.

Oh, I'm not a big fan of macro's either, luddite that I am, I 
micromanage too much, probably.

Al

Richard wrote:

> Come on Al, lets be fair. I don't (usually
:-) ) argue w/ C vs. assembly, 
> but Andrew is asking for some really esoteric thing. Why don't you
give us 
> an equivalent asm example, in ANY of your favorite macro assembler's
syntax.
> 
> At 03:43 PM 11/23/2004, onestone wrote:
> 
> 
> 
>>How I just love the simplicity and clarity of C. The meaning of the
>>following simply leaps from the page without any effort at
interpretation.
>>
>>:?}
>>
>>Sorry rolf, that was just irresistible.
>>
> 
> 
> // richard (This email is for mailing lists. To reach me directly, please 
> use richard at imagecraft.com) 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

--- In msp430@msp4..., onestone <onestone@b...> wrote:
> It isn't something I could ever imagine
wanting, let alone see as
desirable.
> 
> Firstly every label I use has meaning. The very thought of
arbitrary 
> labels is wrong to me.
>

Oh, c'mon Al, you luddite! :-)

Labels inside multiply repeated macros are an obvious case of not
needing unique label names in assembler. If the assembler doesn't
support local labels, what are you to do?

 
> Secondly in all the time I've written in C
(although I wouldn't
consider 
> myself an expert I do consider myself proficient)
I've never had a
need 
> for an internal label in a function that I can
recall. This
suggests 
> that Andrews need is more than just esoteric.

Esoteric is my middle name. Andrew "E.' Kalman, after all.

Yes, in my macro I need the PC for a processor that doesn't have a
readable PC.

Odd, isn't it?

But the toolset in question is able to resolve assembly-language
labels across all modules as run-time addresses at link time. Run-time
address = PC. Kinda cool ... kudos to Clyde for that one.

The target in question isn't a C-friendly part (it's a PIC16, where
PCL is readable, but PCH is not). So the usual C methods don't work.
Ergo, other methods are required.

--Andrew Esoteric Kalman, Ph.D.
aek at pumpkin inc dot com

P.S. Suprisingly, I do agree with Al on certain things :), but they
are (as I recently discovered) in the OT realm of politics, where the
off-topic banter in this group has really got out of hand.

--- In msp430@msp4..., onestone <onestone@b...> wrote:
> It isn't something I could ever imagine
wanting, let alone see as
desirable.

This reminds me of something my Dad told me about his doctoral exam at
Columbia ... One of the reviewers said something to the effect that
"this cannot be right, yada yada yada" and basically refused to sign
off on it.

So, Dad went and published his work in a mechanical engineering
journal instead.

The rest, as they say, is history.

I think it's interesting that I gravitate towards stuff that other
people say can't work, can't be done, etc. I'm by no means the
smartest guy around (or on this list), but I do enjoy a challenge. 

--Andrew E. Kalman, Ph.D.
aek at pumpkin inc dot com

aekalman wrote:

> 
> --- In msp430@msp4..., onestone <onestone@b...> wrote:
> 
>>It isn't something I could ever imagine wanting, let alone see as
> 
> desirable.
> 
>>Firstly every label I use has meaning. The very thought of
> 
> arbitrary 
> 
>>labels is wrong to me.
>>
> 
> 
> Oh, c'mon Al, you luddite! :-)
> 
> Labels inside multiply repeated macros are an obvious case of not
> needing unique label names in assembler. If the assembler doesn't
> support local labels, what are you to do?

Note that I'm not a macro fan either. Truly a luddite! The odd few bits 
of code that I do tend to repeat (typically short loops) are either so 
short the macro would take more effort to type, or long enough that a 
function call might be warranted.

Al
> 
>  
> 
>>Secondly in all the time I've written in C (although I
wouldn't
> 
> consider 
> 
>>myself an expert I do consider myself proficient) I've never had a
> 
> need 
> 
>>for an internal label in a function that I can recall. This
> 
> suggests 
> 
>>that Andrews need is more than just esoteric.
> 
> 
> Esoteric is my middle name. Andrew "E.' Kalman, after all.
> 
> Yes, in my macro I need the PC for a processor that doesn't have a
> readable PC.
> 
> Odd, isn't it?
> 
> But the toolset in question is able to resolve assembly-language
> labels across all modules as run-time addresses at link time. Run-time
> address = PC. Kinda cool ... kudos to Clyde for that one.
> 
> The target in question isn't a C-friendly part (it's a PIC16,
where
> PCL is readable, but PCH is not). So the usual C methods don't work.
> Ergo, other methods are required.

Neat solution.

> 
> --Andrew Esoteric Kalman, Ph.D.
> aek at pumpkin inc dot com
> 
> P.S. Suprisingly, I do agree with Al on certain things :), but they
> are (as I recently discovered) in the OT realm of politics, where the
> off-topic banter in this group has really got out of hand.

Nice to know I have one or two good thoughts, even if they are 
non-technical. ;?}

Al

At 05:43 PM 11/23/2004, aekalman wrote:



>--- In msp430@msp4..., onestone
<onestone@b...> wrote:
> > It isn't something I could ever imagine wanting, let alone see as
>desirable.
>
>This reminds me of something my Dad told me about his doctoral exam at
>Columbia ... One of the reviewers said something to the effect that
>"this cannot be right, yada yada yada" and basically refused to
sign
>off on it.
>
>So, Dad went and published his work in a mechanical engineering
>journal instead.
>
>The rest, as they say, is history.

Google for "Kalman Filter" for people who are wondering what the heck 
Andrew is talking about,


// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

here again we find ourselves in agreement. The only things that are fun 
to do are those that most others figure can't be done. This doesn't
make 
you smart. Just devious and twisted perhaps :<>. The number of people in 
academia who've never had to earn a living from what they teach astounds 
me, there is a vast difference between engineering and teaching it in my 
opinion. But that's another OT story best kept until the list goes dead 
once more.

Al

aekalman wrote:

> 
> --- In msp430@msp4..., onestone <onestone@b...> wrote:
> 
>>It isn't something I could ever imagine wanting, let alone see as
> 
> desirable.
> 
> This reminds me of something my Dad told me about his doctoral exam at
> Columbia ... One of the reviewers said something to the effect that
> "this cannot be right, yada yada yada" and basically refused to
sign
> off on it.
> 
> So, Dad went and published his work in a mechanical engineering
> journal instead.
> 
> The rest, as they say, is history.
> 
> I think it's interesting that I gravitate towards stuff that other
> people say can't work, can't be done, etc. I'm by no means
the
> smartest guy around (or on this list), but I do enjoy a challenge. 
> 
> --Andrew E. Kalman, Ph.D.
> aek at pumpkin inc dot com
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

----- Original Message ----- 
From: "aekalman" <aek@aek@...>
To: <msp430@msp4...>
Sent: Tuesday, November 23, 2004 10:58 PM
Subject: [msp430] Re: How to Auto-generate Unique Labels in C?


> 
> 
> --- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote: 
>> #define DoLabel(X) X
>> #define MyUniqueLabelMacro() A##DoLabel(__LINE__) 
>> 
>> This generates identifiers of the type A<linenumber.  This is a
> use-once
>> macro, you can use it exactly once to define a label but can't use
> it to
>> reference a label.  If the labels are only inside compounds, then
> they
>> are scoped by the compiler so there are no name clashes possible
> anyway.
> 
> 1) Why is DoLabel(x) x required? Why doesn't A##__LINE__ work? Why the
> extra subsitution layer?
> 
> 2) IINM, the scheme you've proposed works fine within a single file,
> in C. But I've seen assemblers that can reference EXTERN labels in all
> of the C files of a project. To do that, each label name must be
> unique (i.e. not allowed to have labels in two files with the same
> LINE number). Is there a way in C to get around that?
> 
> m4 (dunno what that is) is not an option for me -- must stay within
> the ANSI C preprocessor.

http://www.gnu.org/software/m4/

Leon