Re: KEil bought by ARM

In article <4365fc6d$1@xxxxxxxxxxxxxxx>, David Brown <david@westcontrol.
removethisbit.com> writes
>Chris Hills wrote:
>>
>> 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.
>
>Don't you think you're getting a bit absurd here?

Not at all. The compilers and the C standard change all the time

>easily checked). To be an issue, the old and new tools would have to
>differ in such a way that they could each properly build the
>cross-compiler so that it ran apparently error-free but generated
>different target code.

So as long as it generated the same hex file from the original
(unmodified project that need changing) then no problem. If the op hex
file is different then the compiler is different


>And if you really want to get the old tools, then every release of gcc
>is a simple download away.

But these need to be built IDENTICALLY to the way they were at the time.

With commercial compilers thjey are built do it WILL be the same
compiler

>> 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?
>>
>>
>
>Nothing in this is any different from using commercial compilers -
>except that you can't do any of the testing or comparisons yourself.

Yes you can. Why can't you do the testing yourself? Test suits don't
test the source of the compiler.


> If
>your (hypothetical) compiler vendor is happy to give you an old compiler
>modified to use a new dongle, have you any way of knowing that it really
>is the same old compiler as you used before?

Yes.

> Do you know that they used
>the same tools to build the modified compiler? Of course you don't know
>- in fact, you can be very confident that they don't.

They don't need to usually. It is one of the ancillary modules that
holds the locking that is not actually part of the parsers etc. It is an
integral part for the system but does not have any part of the compiler
process.

>> 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.
>>
>
>Could you give us some pointers to compiler vendors' web pages stating
>their policy of making and distributing such old compiler versions for
>the asking (for a reasonable price if required), since "most" vendors
>will do this for you?


No. None of them advertise it but I have supplied several

> While you are at it, could you point to some of
>these "validations" and "qualifications" that "decent commercial
>compilers" have?

Usually Plum-Hall, Perennial, Embassy, Paranoia etc IF you ask they
usually tell you.

>I have no doubt that some vendors do have this sort of level of customer
>support. But I have very great doubts that it applies to "most" - the
>economics simply doesn't make sense.

Fine, then we have different experiences.

>There are plenty of arguments for using particular commercial compilers
>rather than open source tools, such as ease of use, customer support,
>target support, integration with other tools, quality of generated code
>or libraries, documentation, etc.

Yes.

>But for ease of archiving old
>compilers, or supporting legacy systems, or transferring tools to other
>computers, closed-source tools (or any other software) cannot come close
>to competing with open-source.

No. this is where we came in..... :-)


>> 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?

this question still stands



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



.

Relevant Pages

  • Re: Inside an FBI Computer Forensics Lab
    ... properly reproduce or validate a piece of hardware. ... open source tools and well established procedures and methods are used ... like me could trivially design a black box which satisfied every ... possible to create a compiler that will recognizes your code during ...
    (alt.privacy)
  • Re: LPC900/80C51 Compiler Toolchain
    ... There are some situations where commercial developers have advantages over open source developers - it is often easier to get restricted information from the microcontroller manufacturers. ... no top-quality open source alternatives (sdcc is, as far as I understand it, a perfectly reasonable compiler - but it is not a top-ranking 8-bit compiler in the same way that gcc is for many 32-bit targets). ... Any serious embedded developer can tell you horror stories of fights with licenses, ranging from broken hardware dongles, lost licenses after hard disk crashes or changing network cards, confusions over licensing policies resulting in waste time and money, long waits for license codes, issues when transferring the software to another computer, and other such problems. ... more manufacturers are going straight for a gcc port for newer 32-bit architectures, rather than the more traditional approach of working closely with a commercial developer. ...
    (comp.arch.embedded)
  • Re: OT: efforts, emo crap...
    ... You cannot expect everybody to understand open source. ... for now, they want me to go to college, I guess this works. ... Liberate something which is only proprietory now. ... The Seed7 compiler now compiles to a C program which is ...
    (comp.lang.misc)
  • Re: LPC900/80C51 Compiler Toolchain
    ... There are some situations where commercial developers have advantages over open source developers - it is often easier to get restricted information from the microcontroller manufacturers. ... Even for those manufacturers which directly support gcc ports, there can be restrictions with some PHB wanting to keep details secret, which therefore cannot end up in open source code. ... no top-quality open source alternatives (sdcc is, as far as I understand it, a perfectly reasonable compiler - but it is not a top-ranking 8-bit compiler in the same way that gcc is for many 32-bit targets). ... Also the gcc port is usually created but not supported. ...
    (comp.arch.embedded)
  • RE: Micro$oft warns of undetectable spyware security risk ...
    ... Contrast this with a closed compiler ... The number of open source advocates who understand driver/kernel/os ... interest (remember they are likely not being paid to review all this ... bank building and vault available to everyone is going to make the bank ...
    (comp.os.vms)