Re: KEil bought by ARM

In article <1130631639.361837.120140@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
larwe <zwsdotcom@xxxxxxxxx> writes
>
>Chris Hills wrote:
>
>> Though it can take weeks to finding the old versions of Open source
>> compilers and especially getting all the right parts.
>
>Ah, the fatal flaw in my reasoning. Wouldn't it be fantastic if a
>gifted engineer could devise some magical technology whereby the
>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?

I know many companies that do this.

The difference it with the commercial compiler you are using EXACTLY the
same one that was used on the original program.

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.

>> With commercial compilers you can usually get the original vendor to
>> provide the right version overnight. I have myself provided specific
>
>ROFL!!!!! Some vendors, maybe - Rowley, for instance. Did you ever try
>to do this with, say, IAR?

Yes.

> How about OrCAD?

No idea.

> My employer is a
>multi-billion-dollar Fortune 50 company, and we certainly never got
>that level of support out of them. Just how big does one have to be in
>order to see these legendary levels of support?

It is not size that matters.

>Let me summarize my experiences in pithy, yet supremely apposite terms:
>
>* If you lose your dongle, you are fucked.

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.

> $Multi-K for the latest
>compiler version. Oh, and you'll have to port and requalify all your
>code.

You will have to re-qualify your code unless you rebuild the original
compiler with EXACTLY the same tools as the first time.... you still
have those don't you? and of course the tools used to build them if they
were source as well.... and probably the same level of computer with the
same OS. You don't want different optimisations creeping in.

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
re-qualify your code (and tools).

>* If you upgrade your machines and the dongle doesn't work with your
>new hardware, you are fucked.

This is true in some cases.

>$Multi-K for the latest compiler version.
>Oh, and you'll have to port and requalify all your code.

See above if you change ONE item of the open source including the tools
needed to build the compiler and possibly the OS you need to re-qualify
the TOOLS as well as the code.

>* 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.

>Either port all your code
>or hunt eBay. Or go to one of those Russian or Greek websites and pay
>EUR50 for a CD-ROM with thirty different cracked compiler versions on
>it. Naturally, the BSA and any certifying authorities (UL, for
>instance) won't mind that you're using a pirated, cracked compiler to
>build life-critical firmware.


What rubbish. You can get old version out of the compiler vendor that
will work with current dongles I have done this.

>* 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? :-)

> you are
>fucked. Might as well rewrite your code from scratch rather than try to
>analyze all the idiosyncrasies of the old and new platforms and get it
>all working happily.

I agree here.

>* If you point out to the compiler vendor that they are costing you
>thousands of dollars in engineering time, you are not merely fucked
>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.

????

>That lovely old oft-quoted comment about the British Navy ("a hotbed of
>buggery and the lash") is an utterly accurate description of what it's
>like to live with proprietary, copy-protected tools.

Not in the slightest.

>> some years ago, than pick up from the compiler vendor an exact version
>> of commercial SW.
>
>... that likely as not will not function on contemporary operating
>systems due to dongle issues.

Not a problem. All the compiler vendors I have worked with can modify
their old versions to work with current compilers.

>> Your illustration falls over when you compare like with like. If you
>> have the source (or executables) for the old SW then the problems are
>> the same. Unless you are suggesting that the old compiler SW is that old
>> that it will not run on modern OS?
>
>The compilers will generally run just fine when cracked.

Which is why the compiler vendors can modify their old compiler to work
with current dongles. The copy protection is separate to the actual
compile/link mechanisms.

>It's the
>copy-protection that works actively to defeat any sane form of
>development system archival. And challenge-response registration
>systems are just as bad, by the way - because they route your urgent
>issues back through the nexus of a [potentially nonexistent] compiler
>vendor who has a vested interest in forcing you to spend on an upgrade.

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


>> source compiler re-built for the later OS? I assume you compiled it with
>> the same compiler used originally? if you rebuilt it with a newer
>
>Yes!

SO lets get this straight.

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.

BTW having build from source code a compiler how do you test and PROVE
is is the same one you built before and how do you validate it?

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

What do you use to test and validate the open source compiler you have
just built? You have to show that it IS the EXACTLY same tool that was
validated (I hope) previously. How do you do this and PROVE that the
source has not been modified?


OR

You could archive the commercial compiler you used at the time.

Excluding the dongle IF the commercial compiler will not run on the
modern OS then neither will the open source version for the same
reasons.

The only problem is the dongle. Most compiler vendors will crack their
own system to use a current dongle if that is required.


How do you qualify, validate and test the open source tools to the same
standards as the commercial tools? You use Plum-Hall, Perennial or
similar perhaps?



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@xxxxxxxxxxxx www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



.

Quantcast