EmbeddedRelated.com
Forums

IAR C compiler in-line assemble support

Started by bcbourdon June 27, 2003
On Fri, 27 Jun 2003 15:45:42 -0700, Richard wrote:

>[ the msg is long, so I do selective snipping, hopefully I do not
>accidentally mis-represented what you said ...]
>
>At 03:18 PM 6/27/2003 -0700, Jonathan Kirwan wrote:
>>...So, whether I take your point here, or not, doesn't matter. The
>>questions still arise. And still need to be addressed. As a
>>person who recommends purchases, I'm just a conduit for this
>>kind of thing, telling my boss (or whomever is asking) what you
>>or someone else says in reply to this kind of thing. If they
>>like your answer, that's great. If they don't, then don't
>>expect me to necessarily get into the middle of it and make your
>>points for you. It's not a factual question, so much as a
>>perceptual one. And it's your job to have an answer, not mine.
>
>That's fine, and we are in a position that can say, we will try our darnest
>to make sure that people will be happy with our decisions. If not, they are
>welcome to use other company's products, or GCC etc. We don't need to get
>every sales there is. The marketplace will offer choices. Great to live in
>a capitalistic society, eh? :-)

Indeed it is!

>>I thought J.C. Wren's point was interesting and worth a little
>>exploration.
>>...
>>Lattice has no unlock codes, no weird crap to get in my way. I
>>can flop their tools on a new machine I build up in minutes and
>>get going. No pain at all. It's an old product. But you know
>>what? I've never been scared of using it because it's not copy
>>protected. I know I'm in control. That's a very nice feeling,
>>for embedded development where a product may very well outlast
>>any company (including the company which developed the product.)
>
>Ah, what if you found bugs in their compilers? That it is dead as a
>doornail in terms of support. You will need to work around it.

Been there, done that, too. One was that I needed to write a
short utility to remove certain .OBJ record types because the
Intel linker/locator didn't understand them. Not a problem.
That's what I'm here for. But I'd rather not have a completely
*dead* compiler and have to work around *that*.

>>...>Yup, if you have their
>> >compilers, you are dead.
>>
>>No! Here is where you and I part company, Richard. I'm *using*
>>Lattice C, right now. Last time I did a compilation run with it
>>was about 3 weeks ago.
>>
>>I am decidedly NOT dead. So don't tell me otherwise.
>
>Only regarding support and bug fixes!

Ah. Well, that's life. If the compiler was so bad that the
results were unusable, we wouldn't have gotten three years of
hard development out of it, right? In short, it was
sufficiently good for the task. Once that is known and out of
the way, I can focus on other questions. Like whether or not
that toolset can be unearthed in 10 years and still be there for
me.

>> >Or even Greenhills,
>>
>>Hated Greenhills. Buggier than anything and lousy support, in
>>the 1990 time frame. Scared to even look at them, now.
>>
>> >SDS, etc. They are bigger companies that got bought up
>> >by,... even bigger companies!
>>
>>Yes. POint being?
>
>The point being that some people like to vault off a copy of the
>development tools, in case they need to rebuild old projects. That's fine.
>The trouble comes in when management says, lets add this teeny feature to
>this 10 year old products, and wham, bug times. So much for vaulting off
>old copies. Point is everything has a risk.

Perhaps. But you are hinting that this is a bigger problem than
my actual experience tells me it is. I've used more than a few
dozen different compiler toolsets for embedded applications I've
written or partnered with others to write. And the practice of
these companies and clients I've worked for (I've been
self-employed for more than 20 years), one of the key things
they (and I) care about is whether or not they will be able to
make improvements to the product or fix problems at a later
time.

You can say that there is no support for bug fixes. But in
practice, with actual C compilers (I still have a dozen of them
in my personal library) which were acceptable for their original
purpose -- they remain acceptable for future purposes. At
least, in my embedded world.

If I use a PIC C compiler today, what I want to know is whether
or not I can revive that PIC C compiler in 4 years to make a fix
to the code or add a new command to the RS-232 parser. And I
don't want to worry about whether or not the same machine is
still around.

>In theory, you need to vault off a copy of the PC w/ the OS as well. Why?

No disagreement. And, indeed, often I do exactly that.

>For example, your Lattice C probably does not use a DOS-32 extender.

No, it runs on plain, unprotected DOS. They were working
*before* EMM386.EXE was out, I believe, which placed DOS into
protected mode. But it works fine under a Win98 DOS box.

>They
>work more or less OK until Win2K and XP. So should you make sure all
>vendors' tools work on DOS box only? Etc.

I keep the O/S with the products.

>It's a complex issue and each
>person has to make their own decisions.

Indeed.

>We don't claim to be the best for
>everyone although we try to please as many people as we logically can. We
>are flexible. People wanted dongles, so we offer that as an option. etc.

Yup. Just telling you about my situation. I thought you might
care to hear it.

However, this *is* a central issue I face each and every time I
consider a toolset. And my bosses and clients are just as
worried about it as I am. More so, perhaps.

> >So if you have their compilers, you are toasted as well.
>>
>>Not if they don't use copy protection. If you've ever read my
>>posts on this subject, you *know* I'm dead opposed to protection
>>schemes, exactly because of my long experience developing
>>products and seeing the problems that these things actually have
>>done to development. And I have a very hard time agreeing with
>>anyone telling me that their bread-and-butter is so important to
>>them that they are willing to place me and my client at risk,
>>just for their protection. Especially, since we aren't thieves
>>and we are paying the bills.
>
>In this country, if someone steals our compiler, they will never buy anyway
>regardless our prices. Other countries are different. Roughly 30% of the
>sales are oversea. We EVEN sell in Russia and China where piracy is so
>rampant, it's not funny. Just it is unfair if a vendor ONLY put in copy
>protection because they think their clients are thieves otherwise, it is
>UNFAIR for a customer to think that's the only reason a vendor chooses to
>use some sort of copy protection.

I *do* understand. I also understand that some do not choose
this model, as well. In any case, I plan to bring up the issue
when the mood strikes me. Because it is a perennial problem for
me.

>Jon, we have over thousands of ACTIVE users at a given time. You give me a
>scenario where I can painlessly update them, minding that some of the
>customers are oversea etc. and I will consider it strongly.

I'm just talking about my needs, Richard. You know your
situation better than I do. But you can rest assured that I,
too, know my situation better than you. I just thought I'd talk
about it, a bit. In my case, I *need* to have control. Me, not
you. And, in practice, this plays a large role in what I decide
to do. It's way easier for me to pay the price up front and
have to deal with something as potentially unsupported as GCC,
for example, if what I buy in the end is control over my
situation. In this case, I've opted otherwise. For a complex
array of trade-offs. But I've always got my eye on the long
term for my clients. And this is one area of some friction.

>>But that's my slant, Richard. I also accept the efforts I'm
>>forced to go through, at times. I *do* understand the cautious
>>behavior and self-protection instincts. But you can also
>>understand that I look for those schemes which are less likely
>>to get in my way, should push come to shove. I want control
>>over my projects. It's as simple as that.
>
>No disagreement here. Hence we offer choices....

Yes, but I'm talking about being *in control*, not under someone
else's control of our options. I've been in situations where
the toolset was locked and there was no way to revive the
compiler and the vendor was long since gone. Luckily, I've
often found ways to break the deadlock -- hence, a modest but
developed skill set I wish I didn't need to have. But the issue
gets all the more pointed, the better these schemes get at
foiling thieves.

But whatever, I think I've been pretty clear. And I didn't
develop this attitude on my own. I developed it because of my
clients and the 30 years I've been developing products. You'd
be surprised just how many of them are still in service. Some
of them are 10 years old, installed at nearly 20,000 sites. I
care about these issues, deeply.

>> >Anyway, speaking for ImageCraft only:
>> >- if I ever get rich enough to retire, my plan is to release all tools w/o
>> >any copy protections etc. BTW, the #1 reason we use the licensing scheme
>> >is so that we can upgrade our customers w/o any pain and suffering.
>>
>>I hope you get that rich. In fact, I hope you get rich enough
>>to send me a spare million. ;)
>
>If I get as rich as Bill G, I will sure to send you a million or two.

Hehe!! Okay. I'll light a candle, tonight. :)

>> >- if I were to get hit over by a truck, there are plans to do #1.
>>
>>Excellent.
>>
>> >- if neither is available for whatever reasons, there are painfully
>> >obvious ways to run our compilers on any Win32 platform if you whack your
>> >brain hard enough to think about it.
>>
>>Hehe. Hopefully, you'll have a nice instruction sheet on that
>>in escrow...
>
>We have employees and lots of distributors. Even hackers on the net who can
>tell you. ImageCraft is not a single person company any more :-)

Hehe. I should have figured.

>> >Enough said.
>>
>>Well... maybe.
>>
>>But thanks much for your point of view. It's enjoyable.
>>
>>Jon
>
>Let me just reiterate that do not assume we put in copy protection just to
>prevent piracy. There are other reasons as well. Mine may be different from
>Qudravox or Rowley, but they probably do have other reasons themselves as
>well!

Okay. I'll think about that. Maybe I'll figure them out.

Jon

Beginning Microcontrollers with the MSP430

At 07:43 PM 6/27/2003 -0400, J.C. Wren wrote:
> Why are there passwords at all? It sounds like you're still
> thinking
>anti-theft here, unless I'm just misunderstanding you. I'd probably put each
>version on a passworded web page, and bulk email my legit customers the
>password.

Because some customers get their announcement from their distributors, etc.

>...
> I don't have a magic solution for this, I just know what I want
> as a customer
>:)


Believe me that I do take your suggestions seriously, and I may do
something similar in the future. Obviously you are not the first one that
brings it up. OTOH, we do have lots of customers who accept our decisions.
As I said, we can't make everyone happy. Oh well... OTOotherH, if you ever
change your mind before we do :-), I will glad to have you as a customer on
the 430 as well :-)

// richard <http://www.imagecraft.com>
<http://www.dragonsgate.net/mailman/listinfo>
First, I have to wrap my head around the idea that anyone would WANT to use a
PIC, and use C on it on top of that. Blah! :)

--John

On Friday 27 June 2003 19:56 pm, Jonathan Kirwan wrote:
> If I use a PIC C compiler today, what I want to know is whether
> or not I can revive that PIC C compiler in 4 years to make a fix
> to the code or add a new command to the RS-232 parser. And I
> don't want to worry about whether or not the same machine is
> still around.
On Fri, 27 Jun 2003 16:56:50 -0700, I wrote:

>Some of them are 10 years old, installed at nearly 20,000 sites.

By the way, I didn't mean to imply that 10 years is the oldest.
Only that the largest active installation base for which I worry
about uses a 10 year old toolset.

Jon
On Fri, 27 Jun 2003 20:04:29 -0400, J.C. Wren wrote:

> First, I have to wrap my head around the idea that anyone would WANT to use a
>PIC, and use C on it on top of that. Blah! :)

Hehe. There are *VERY* good reasons for using PIC. This is one
I'd love to debate -- lots of personal stories, here. But
that's one for another day, eh? And that's not to say that I'm
not entirely excited about the MSP430 -- I am!

Jon
On Sat, 28 Jun 2003 00:48:31 +0100, you wrote:

>Before anybody jumps on this, the point is that the assertion was a
>90-day evaluation from ImageCraft, not 30-day.

All I got from that discussion was that Richard said Tam was
right about the facts, but wrong about the stated policy. Tam
could have checked the policy before speaking, but it's easy to
see why Tam got that impression since it actually did last
longer than 30 days. He misspoke, but it's easy to understand
why and cut some slack.

Jon
Hi Paul,

I would like to first clarify a few issues :

1. All bugs I have found in the vendors' tools that participate here, I've always
reported directly, not on a forum, unlike eg. the ICC-AVR forum where some
report bugs on the forum. I don't see the point. (Notwithstanding the fact that
often they aren't bugs).
The reason I bring this up is that my last resort always is to invite dismay or
to (mis)convey as litiguous.

2. I would never have even raised the subject, privately or on the forum.
You seem to have missed the essence of my suggestion vis-a-vis your postings
relating to IAR. (and I'm not defending IAR)

Actually, sadly I find myself in a similar predicament as Tam now, however I won't
take the bait.

OK, once again :
------------------

RAL has an excellent product.
Rule #1 in business is that you don't promote your product by bagging the competition,
hence there's no reason for you to attack IAR, as you undoubtedly have a superior product.
However, you have been attacking IAR on a regular basis when there is no need to.

It's no coincidence that your demeaning comments on IAR started only after RAL was in the firing line.
I can readily identify that the whole Tamar issue is based on the fact that you provoked him - when actually
his original, fundamental and central theme was that you appear to be unable to accept (constructive) criticism.

I merely wanted to point out to you that you are using certain peripheral issues as a vehicle to rationalise
conduct that I do not approve of.
It was sincerely hoped you would identify this, and be "big enough" to take it on as constructive.

I'm actually somewhat dissapointed with your reply :

> Long post; I reply here, but must admit that I feel many others on this
> list won't bother to read very far into the post, or even into it at all.

which actually again is a bit provocative.

I'm on your side, I'm trying to point something out to you, but it merely seems to have been reciprocated with
antagonistic comments.

I am referring to :
---------------------

> Sure, we can all concentrate on the problems, but then I can also
> concentrate on the problems in other compilers too.

But you do !!!!!! -->

> Of course, there are a number of you in this forum that have stumbled
> over bugs in the latest IAR compiler, yes?
> When you report them to IAR, what is the response for your
> $400+ per year tax? Do you get an immediate fix?

Also :

> FWIW, I an IAR customer, too. I'm a Keil customer. I have lots of
> compilers here. I use what's appropriate.

Yes, but you're a compiler vendor as well - I'm not ???

Point is Paul - that I pointed out that the fundamental issues that you were slinging at IAR
you need to address too.
You have only taken that direction since IAR started to criticise RAL.
Whether the criticism was published or not is not pertinent.
What is pertinent is that the mere fact that IAR (partially substantiated) criticised you,
and ever since then you have aired your response by merely running them down on this
forum - Have a think about it.

I'm sorry you took it this way.
I know very well the massive amount of work that has gone into CrossWorks, and that it still does.
But I don't approve of "double standards", especially when it is at others' expense.

Please don't compromise all the hard work your team has put into CrossWorks by bickering at IAR
only because they criticised you.
Keep up the good works, and the rest will sort itself out.
The consumer will quickly find its way to the party that offers the best product and support.


Best regards,
Kris
I'd like a bit of help with a project I'm creating. It seems like most
people here are friendly so I'll give it a go.

I've been programming for 20 years - started with COBOL on a mainframe, the
old Sinclair ZX81 and the Jupiter Ace in Forth (I got Space Invaders into
1k). I continued into various mainframe database languages and then into
programming in Windoze. After brief experiments with VB I found Delphi and
then Borland C++ Builder which is now my favourite. I also spent quite a bit
of time with MS Access which I don't like very much but it seems to work
(sometimes).

A few years ago I got involved in a project creating a bio-monitoring device
which would measure small changes in skin resistance and display them on a
computer. Such information seems useful to a therapist in deciding which
areas to address with a client seeking emotional guidance.

I developed the windoze software and someone else created the hardware and
firmware with a PIC.

As sometimes happens we had our disagreements and parted company. Now I am
in the position of having invested hundreds of hours of time in the windows
software and having to create hardware and firmware.

I thought that PIC processors, which my erstwhile partner used, would be
workable but after consultation with the good people at Olimex it seemed
better to go for the MSP430.

There are lots of books about PIC to take one through the introductory
stages of making the LED blink or saying "Hello World" on an LCD but such
don't seem to exist for the MSP430.

My project involves using an LTC2440 24 bit A/D chip interfaced to a PC via
an RS232 line.

I have the assembler code they wrote for me and the prototype module. I also
have a parallel port jtag programmer from them. The board worked and sent
data to my PC.

Now here come the really nae questions

I wanted to make a small change to the assembler code. I am using the
Kickstart software - Embedded workstation and C-spy. I plugged the jtag
programmer from Olimex into the socket and connected the board to the
batteries.

I opened the Embedded Workbench software, loaded the project file and then
clicked on the C-spy icon.

Messages came up saying "erasing flash" and "programming" and then I click
on "Go" in the "execute" menu and I get a flashing stop hand icon. However
no data gets sent across to the PC. I retried it using the original without
my changes.

I guess that what I am doing wrong is probably covered somewhere in the
thousands of pages of documentation that I've downloaded over the last few
days but if someone could give me a quick pointer it would be appreciated.

--
Ralph Hilton
Kris,

> RAL has an excellent product.
> Rule #1 in business is that you don't promote your product by
> bagging the competition, hence there's no reason for you to
> attack IAR, as you undoubtedly have a superior product.
> However, you have been attacking IAR on a regular basis when
> there is no need to.

I don't mean to attack IAR. I just had a question as to what your
yearly tax bought you and how immediately you got a fix once a bug is
reported. This is a (recurring) theme for us--customers want an
"immediate fix" which, sometimes, we can provide by a new compiler,
library, or whatever, and the question was posed as to what IAR
customers find in such a case? The premise started that there were bugs
identified in the IAR compiler (as evidenced from postings in this
group) and, therefore, what IAR's response was when presented with such
issues? Immediate fix? Wait for next upgrade? What?

For the issue that you have identified, what is the fix? "Don't use
that optimization level, sir, and wait for the next release, it'll be
along RSN?" or "Yes, a known problem, here's a replacement compiler..."?

> It's no coincidence that your demeaning comments on IAR
> started only after RAL was in the firing line. I can readily
> identify that the whole Tamar issue is based on the fact that
> you provoked him - when actually his original, fundamental
> and central theme was that you appear to be unable to accept
> (constructive) criticism.

I have already asked for clarification of the original provocation on
this list. Tamar's objection is to the wording of a single paragraph of
a single mail, as far as I can tell. There are other issues that seem
to have been boiling under and come to light. Obviously, we haven't
kept Tamar as a customer given his latest postings.

> I merely wanted to point out to you that you are using
> certain peripheral issues as a vehicle to rationalise conduct
> that I do not approve of. It was sincerely hoped you would
> identify this, and be "big enough" to take it on as constructive.

Which conduct is that? I really haven't bleated on about IAR for quite
some while according to the record of posts I've made to the group.

> I'm actually somewhat dissapointed with your reply :
>
> > Long post; I reply here, but must admit that I feel many others on
> > this list won't bother to read very far into the post, or
> even into it
> > at all.
>
> which actually again is a bit provocative.

I think it's a statement of fact; when I see a long, rambling post, I
must say that after a few paragraphs I lose the plot, and just turn off.
Much better is a short message which doesn't go over one page. (This
one does, so I believe is consigned to the same fete except for
interested parties).

> I'm on your side, I'm trying to point something out to you,
> but it merely seems to have been reciprocated with
> antagonistic comments.
>
> I am referring to :
> ---------------------
>
> > Sure, we can all concentrate on the problems, but then I can also
> > concentrate on the problems in other compilers too.
>
> But you do !!!!!! -->
>
> > Of course, there are a number of you in this forum that
> have stumbled
> > over bugs in the latest IAR compiler, yes?
> > When you report them to IAR, what is the response for your
> > $400+ per year tax? Do you get an immediate fix?

This is not a rhetorical question, it is an enquiry and you have left
out the sentence that comes immediately after it, namely: "I must admit
that I am more than a little interested in the answers to these
questions." The reason? Trying to figure out how we could better serve
customers by guaging what IAR provide for the yearly maintenance fee.
This is not a get-at-IAR, though it could be read that way. How else do
you say "What do you get for your yearly maintenance fee from IAR?" with
conjectures without it also sounding like a get-at-IAR diatribe?

> Also :
>
> > FWIW, I an IAR customer, too. I'm a Keil customer. I have lots of
> > compilers here. I use what's appropriate.
>
> Yes, but you're a compiler vendor as well - I'm not ???

I do not see the relevance of being a compiler vendor. That is part of
our business, not all our business.

> Point is Paul - that I pointed out that the fundamental
> issues that you were slinging at IAR you need to address too.

I don't think I've really said much about IAR other than point to the
benchmark case. But as I've also pointed out, there are steps being
taken to rectify this but how far they will ultimately get I just can't
say. And I haven't brought that up for a long time either.

> You have only taken that direction since IAR started to
> criticise RAL. Whether the criticism was published or not is
> not pertinent. What is pertinent is that the mere fact that
> IAR (partially substantiated) criticised you, and ever since
> then you have aired your response by merely running them down
> on this forum - Have a think about it.

I don't see how I have run IAR down other than by pointing to the
benchmarks. I have notified IAR of a problem in their MSP430 compiler,
not on the list. Again, I have extended the same courtesy to other
compiler vendors here without running them down. It's not
the-three-independent-against-IAR, but I just highlighted the issue.
And provided proof to you privately of the tactics against other
vendors.

> I'm sorry you took it this way.
> I know very well the massive amount of work that has gone
> into CrossWorks, and that it still does. But I don't approve
> of "double standards", especially when it is at others' expense.

Again, I haven't brought up the benchmark issue for a long time. It's
being sorted. I am unable to say much more at this time.

> Please don't compromise all the hard work your team has put
> into CrossWorks by bickering at IAR only because they
> criticised you. Keep up the good works, and the rest will
> sort itself out. The consumer will quickly find its way to
> the party that offers the best product and support.

My only issue with IAR is the benchmark: using a non-optimized compiler
without letting others validate their claims and use this as input.
Should I provide by own benchmark and show that CrossWorks generates the
densest code? Easy to do, but hardly ndependent. This is why there's a
whole industry built around benchmarks (SPEC, EEMBC), but you need to
pay big bucks to join the club. And, as I said, we're moving towards
some sort of agreement over such issues anyway.

However, should people be interested in benchmarks, then the numbers
published for Salvo should make interesting reading. And they'll be
even more interesting with the next compiler, I can assure you.

One thing: IAR do have a very good code generator now, which has raised
the bar quite a bit. So, we need to follow to stay in touch. However,
code generation is not the only issue when selecting a development
system, but it's the one that IAR focus on because now they can produce
smaller code than us--for the moment, at least. ;-)

-- Paul.
Hi Paul,

I think further excursions are no longer constructive here. I think it's best to "agree to disagree".

I would however appreciate the opportunity to briefly land on this issue :

> I think it's a statement of fact; when I see a long, rambling post, I
> must say that after a few paragraphs I lose the plot, and just turn off.
> Much better is a short message which doesn't go over one page. (This
> one does, so I believe is consigned to the same fete except for
> interested parties).

Maybe a possible permuation would be that this is/was the common denominator :

If you see a "long, rambling post" and you "lose the plot and just turn off",
simple - don't invite one.
I really thought that, as a business owner, you might have considered a course
of action where you don't "lose the plot and turn off".
The end of your correspondence could have a "pot of gold" ??

I regret that this thread, which sincerely was intended to be constructive,
rapidly deteriorated into a "battle of wits" :

> This is not a get-at-IAR, though it could be read that way. How else do
> you say "What do you get for your yearly maintenance fee from IAR?" with
> conjectures without it also sounding like a get-at-IAR diatribe?

Answer :
By more concisely describing what it is you are conveying ("rambling"),
or - By not bringing it up at all..............

(Nothwithstanding the fact that I referred to a syndrome that had been ongoing
since ~ March 2003 in your postings vis-a-vis reaction to criticism of IAR)

Let's just leave this topic for what it is, and perhaps we can revisit it in a few weeks, and see
what our perspective is then - and if we still feel the same way - so be it.
It does not change my opinion of you or your intellect Paul.

All the best,
Kris