... snip ...
In the past I have avoided that sort of thing (in other non-C compilers) by keeping the raw input value in string format. Things can get involved if compile time calculations are involved.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
Byte Craft Compilers are not dongled.
Regards
-- Walter Banks Byte Craft Limited
There is. The simplest example is this translation unit char compile_time[] = __TIME__; which rarely ever generates the same object file when compiled twice.
Another less obvious case would be C++ anonymous namespaces. Compilers tend to put a mixture of file name, PID and compile time into the generated symbol names to make them unique.
As far as I can tell, that would be a bug; compile-time floating-point computations should be performed using the same algorithms as on the target. Otherwise, this: double a = 0.3, b = 0.8; double c = a + b; double d = 0.3 + 0.8; could result in different values in c and d (it's a long-known misfeature of gcc that it still sometimes does on x86 because FPU registers have more precision than doubles; you want '-ffloat-store' to avoid this).
Stefan
Good point. Although I would get what I deserved if I expected identical images from that :)
I don't *think* these would survive into the target image for my own software (even if I used c++). Or are they still used at run-time for code with stripped debug info?
But your point is well made; in general a different target image may not mean that the compilers are "different".
-- John Devereux
With RTTI, the program can ask for class names ('typeid(x).name()'), and most compilers return some sort of mangled name at that place.
Another possible cause for differences in the image would be a linker arranging things alphabetically. With gcc, inline functions or templates don't end up in the .text section, but in .gnu.linkonce.XXX, where XXX is the symbol name. Other schemes for managing inlines/templates (involving a pre-linker and keying the functions to particular object files) add even more pseudo-nondeterminism (and explode in your face when you want to build multiple binaries from the same set of object files).
You might even encounter something like this with simple C. When you're building static libraries with 'ar ru', object files in the library may be in a different order for each linker invocation, causing them to be added to the image in different order.
On the other hand, it's not too bad. Most of the time, when I do a really local change, only that local part of my image changes. Plus the part containing the compile date :-)
However, it's a very good reason to give the very same image to your test departement that you want to ship to your customer.
Stefan
Yes, that's why we end up with something like program-v5-pre11, which is simply renamed to program-v5 when attempt #11 is finally found bug-free and released. Otherwise the version-increment and consequent rebuild would need testing again!
-- John Devereux
I use some intermediate floating point to calculate compile time integer constants. Typically to calculate the timer value based on a time specified in seconds with a resolution of 100 microseconds.
Regards Anton Erasmus
Do they have other security measures which might prevent them from being able to run under various emulators. virtual machines etc. ? If Byte Craft stops trading for some unforseen reason, would it be possible to get the compilers running without any Byte Craft support ?
Regards Anton Erasmus
Our compilers will run under various Windows emulators for example wine. Old compilers were designed to run under DOS emulators. Our compilers will run on other IDE's or can be called from Batch files.
Yes..
Regards
-- Walter Banks Byte Craft Limited
In message , Anton Erasmus writes
Franklin never did AFAIK a C51 compiler. They simply rebadged the Keil....
Yes.
Is this for IAR?
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
What do you mean "good guys"?
If you mean no dongle it depends what target MCU you want.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
It was sold as a Franklin compiler. Nowhere is it apparent that it is another compiler. The fact of the matter is, that if it did not use a dongle in the first place, we would not be in the position we are now. We learn from our past experiences, and have with newer tools either insisted on the dongle free versions, or switched to alternatives such as gcc. In the end a working gcc producing the least optimum code possible, is better than the best possible compiler which does not run because of a dongle problem.
The local IAR agents are useless. These days one can email IAR direct, but if it is a question regarding installing the compiler, or getting it to run (i.e. Dongle related), then they refer one back to the agents. The one time I reported a compiler bug, they acknowledged it, said they will give an updated version when they fix it, and I have not heard from them since. The install issues are typically no problem at all when one get the compiler initially. It is normally when one have to do a small update on old code when one suddenly finds the dongle is not working. New PC to fast, parallel port different etc. Updating code to the latest version is normally not an option. Even if the vendor is willing to provide an old unlocked version if one buys the latest version, it is inadequate. If one has paid to use the old version, and one do not use the processor family anymore, then having to fork out for the latest compiler to change a few lines of code is daylight robbery.
Support in South Africa seems to be inversely proportional to the price of the tools and size of the tool company.
Regards Anton Erasmus
That was part of the problem. Lot of history there. It is a long time ago and not something I can post publicly ( three sides (and lawyers) to every story).
The problem is that it is a battery powered dongle not that it is a dongle. I have 15 year old dongles that still work fine. Also 905 of the time for compilers that old for a small admin fee they will remove the dongle.
Yes. I agree. Code that works (if less efficient) is better than no code. However there are other compilers both free and commercial that have disappeared over the years and it can be just as bad getting any of them to work on modern PC's
BTW can you still get the original GCC (before they changed cores)?
Email me direct.
Look in the "my pages" part of the IAR web site.
This is a problem with Windows a lot of the time. BTW IAR will solve the dongle problems. There are various ways around it. Including a swap from the parallel to USB dongle.
Many if not all the compiler companies will in this sort of case remove the protection for the old versions.
Why? It solves the problem or are you intent on finding fault no mattter what?
There are other options. Email me direct.
That is a distributor problem not IAR as such. Franklin was also a distributor. You don't have much luck picking distributors. It can be just as bad with GCC as most people seem to use a gcc from a maintainer not FSF.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Local GCC mirror:
GCC source repository, so you can tell why a change was made and when:
distributor. You don't have much
to use a gcc from a
Availability of GCC packages from my distributor (Debian) for various architectures:
Search all bugs reported to Debian for GCC-related packages:
What was your big value-add again?
cheers, Rich.
-- rich walker | Shadow Robot Company | rw@shadowrobot.com technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
I've done a lot of support into South Africa for our compilers, and our clients there have to support people all over the world.
If you buy from a European supplier such as ourselves or Rowley you avoid the time zone issues. If you use VoIP/Skype you avoid the comms costs.
We haven't shipped compilers with dongles for a very long time. Twenty years ago the problem was corporate users. I've walked into into an office and seen ten computers running our software when only two licenses were current. These days the problem is "seepage", but most medium and large businesses are much better than they used to be. In practice it isn't a problem any more - if they aren't prepared to pay they'll use gcc, regardless of the resultant salary costs. In many companies, software tools still come out the capital budget, and salaries from another.
Once laptops became common, the dongle was the wrong solution. These days we just assume our customers are honest and do not support the ones who aren't.
Stephen
-- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
However most GCC don't use that as you say below
Most people use a gcc from one of the distributors who do their own patches and modifications and in the case of a lot of them include proprietary IP in the package. Not all the stuff the distis do is fed back.
You have a Debian-GCC not a "gcc" compiler.
But NOT for "GCC" only Debian's GCC and there a re a lot of other similar but different GCC distributions. Red had pointed out the performance in theirs varies from version to version and is NOT the same as any FSF version.
Saying "GCC" is like saying A compiler family where no two are likely to be the same. In a discussion yesterday with a FOSS devotee he said ONLY the FSF GCC are legitimate to call GCC the rest are deviations. Nice to know there is consistency.
Behaviour and efficiency varies wildly, even for the same target and version number. One company had 4 programmers using GCC... turned out they are using three different compilers even though they were for the same targets and had the same version number.
Some one yesterday said IAR made one error (in his opinion). That is enough... I will never use them again. Compared to the state of the GCC market IAR are positively saintly.
We deal mainly in critical systems. We can validate the compilers.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In message , Stephen Pelc writes
Or Keil or IAR or Cosmic or...
However they only support you if you have a fully paid up support agreement.
BE fair... people are hardly falling over themselves to pirate forth tools.
Where? Most European companies play by the rules.
In reality is it a MAJOR problem in the far east, Middle East and Asia.
Only in smaller companies. Most development work is still on desktops.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
We support any use who purchases our compilers. We give free upgrades for a period or for bug fixes in the current release. After that it's a paid upgrade. We also provide support contracts.
20+ years ago. The large UK Telecoms people.Sure is. The real issue is what solutions promote your particular business model. IMHO, the real problem for any compiler vendor is gcc and the sometimes dreadful free library code supplied for embedded use. Nowadays, the point that distinguishes tool chains for embedded use is the quality of the libraries and the debugging facilities.
How much on-site commissioning have you done? Some people still develop for machinery, not for widgets that talk to other widgets or computers. I can't fit ten full size vending machines in our office, let alone a full size stage lighting rig. Our neighbours might well object if we start testing bomb-disposal machines here.
And yes, we did have clients who forgot to pack their dongles and were now 6000 miles from base!
Stephen
-- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
That is the same for al commercial tools.... which BTW includes GCC when you get it from a Disti.
Hmm... Only seen that done once (also in a UK Telcoms company) However it was only once and it was only temporary.
Not really.
With what? One Silicon company is actually doing MISRA compliant library code for their parts.
That and the level of efficiency Most Gcc compilers are still a long way behind the best commercial ones.
Some... But we used Sun workstations :-) I take you point but not that many do on site commissioning.
Point taken. But how many in your dev team go out to the customer for commissioning?
Actually those can be tested in a large office and the car park. I think the ones I have seen tested are tested in the loading bay as that is all the space they need. They fit the shot gun later.
We did special support in those cases. One in the wilds of Canada (with a laptop) the other in Siberia.... Complete re-fit of a lighting system for a theatre. Internet? wot internet? 300 baud IF the phone lines were working!
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
You overstate your case so much that it's difficult to take you seriously when discussing gcc - especially in the context of native gcc on Linux distributions.
"Behaviour and efficiency" do not "vary wildly" - there are typically only very minor differences between the FSF gcc tree and distributions' gcc sources. When the FSF releases a gcc version, Debian (or any other distribution) will take that as their basis. They might apply a few patches (typically from the FSF development branches), they might use a non-default customisation (such as generating code for pentium and up rather than generic 386+ code, or choosing different languages to include), and in the case of Debian, they move the documentation to a separate package (because of license nitpicks).
There have been occasion bad decisions by distributions about gcc versions to use, with someone picking an experimental or otherwise incompatible version. But after a high-profile example from Red Hat (who managed to ship a gcc that was incompatible with their kernel version), I seriously doubt any distribution would do it again. In reality, it would be extremely difficult to find two native gcc compilers with the same x.y version number and the same target which did not give virtually the same working binary from the same source code and the same compilation switches. There might be small differences in the size or speed of the code due to different default switches, but nothing beyond that.
*All* distributions who make or collect patches to major packages like gcc will pass relevant patches back to the main FSF tree (although they may not be included). *All* distributions will base future versions of their gcc tools on the FSF tree, not some private fork. And I would be amazed if any distribution had included proprietary IP in their gcc package - it would be contrary to the GPL (and therefore illegal), and contrary to the whole point of using open source development processes in the first place.Within the world of embedded development, the situation is a little different. Here there definitely can be differences between different supplier's versions of gcc. This is mainly because the embedded world moves faster - in particular, support for new variant devices is often included in different supplier's builds before the changes are merged back to the FSF tree (though any changes of worth usually *do* get merged back in time). Specific extensions (such as attributes for interrupt handlers) are also often developed outside the main tree, and may or may not be merged back to the FSF tree. (One of the reasons I recommend CodeSourcery for gcc tools is that they are the official maintainers for certain ports - thus their changes almost always end up back at the FSF.) However, for the huge majority of code that is not dependent on details of the device or target-specific C extensions, any gcc build of the same basic version and the same target will give approximately the same results.
Libraries are a different matter - cross-compiler builds of gcc are often distributed with alternative libraries (standard glibc, newlib, or a proprietary library). This will obviously make a difference to the final binary.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.