Re: KEil bought by ARM


> >sourcecode tarball I download today could be stored in some fashion
> >against the possibility that I might require it in the future. I guess
> >we'll just have to wait for someone to invent some such device.
>
> You mean in exactly the same way that people archive old versions of
> commercial compilers they use?

What of the dongle? What of the one-time install key? The product line
I work with has a typical installed lifespan of 15-20 years. People
don't normally replace these devices until they do major work on their
house.

> For Open source unless you are re-compiling the source with EXACTLY the
> same compiler you used the first time it is a different version.

It's easy and legal to archive the operating system and complete
"meta-toolchain", though. At worst, you have a known-good starting
point and can modify the bare minimum number of aspects of the
environment in order to get it working again.

With the proprietary solution, it's an opaque, monolithic lump that
either works or it doesn't. If it doesn't, expect to have to travel to
distant star systems and fellate unpleasant alien beings with dubious
personal hygiene in order to get your code buildable again.

> True. If you loose your original source so are you. This assumes that
> you are no longer developing or working with that compiler or target
> otherwise you would still have the dongle. There ae ways around this but
> it is best not to loose your tools.

Dongles get stolen, lost, ESD-zapped, sent to far-off lands for
offshore development purposes (one of the products I work with actually
has a floating license, the server for which is physically resident in
Bangalore), etc.

> IF you can't recompile the program you need to modify (before
> modification) to an IDENTICAL hex file it is NOT the same.So you need to

Possibly not even then.

> >* If you upgrade your compiler and have to return the dongle as part of
> >the upgrade process, and then find that you need to recompile some old
> >code with the old compiler, you are fucked.
>
> Nope. Most compiler vendors I have worked with will supply and old
> version of the compiler that will work with a new dongle. This does not
> of course affect the code output so no re-qualifying needed.

What can I tell you - compiler vendors apparently love you. They see
you walking in the door and lay out the red carpet. Servants bring
gold, frankincense and myrrh, and the president of the company unlaces
your sandals and washes the dust from your feet with his own hands.
Unfortunately for those of us not lucky enough to be the fruit of a
virgin birth, our treatment is rather different.

> >* If the vendor goes belly-up or is acquired by someone who has a
> >vested interest in migrating customers to some new platform,
>
> See title of this thread? :-)

I was thinking more of OrCAD actually, but yes - the title of this
thread too :)

> >vigorously but actively flogged and drenched in brine during the
> >process - a sensation I don't happen to relish, though I understand
> >it's quite popular in certain circles.
>
> ????

I live in New York City [though I can't wait to move out].

> Looks like you have decided and have a very blinkered view despite my
> real world experiences to the contrary.

I'm speaking of my experiences and of course my personal distaste also.
But I'm hardly in the minority here, on both counts.

> To build an old version of the open source compiler you need to archive
> the old version AND all the tools needed to build it AND any tools
> needed to build them etc.

Yes. Then, if something needs to change in that toolchain, your first
step is to rebuild the original source. If it binary compares with the
output of the original compiler, that is almost certainly "good
enough". The rationale here is:

* The output for a known input (starting point of code modification) is
the same.
* Any difference in behavior between old and new toolchains for a given
change is due to something you added or changed in the source for your
application, which requires requal anyway.

(That's not always good enough for my projects, but it's a good
starting point).

> All the decent commercial compiler suites are rigorously tested and
> validated against industry standard and accepted validation suites.

Or they're built, run once and shipped and customers become beta
testers. Do you _know_ the difference just from the smell when you
crack the shrinkwrap? Ever look at the output of some of these
standards-compliant, rigorously tested compilers? IAR's MSP430 and 78K0
products in particular have generated some horrendously insect-infested
code for me, as just one example.

.

Quantcast