What Is Gnu Compiler

[Fidelia Boldul]

Acompiler is a special program that translates a programming language's source code into machine code, bytecode or another programming language. The source code is typically written in a high-level, human-readable language such as Java or C++. A programmer writes the source code in a code editor or an integrated development environment (IDE) that includes an editor, saving the source code to one or more text files. A compiler that supports the source programming language reads the files, analyzes the code, and translates it into a format suitable for the target platform.

Compilers that translate source code to machine code target specific operating systems and computer architectures. This type of output is sometimes referred to as object code (which is not related to object-oriented programming). The outputted machine code is made up entirely of binary bits -- 1s and 0s -- so it can be read and executed by the processors on the target computers. For example, a compiler might output machine code for the Linux x64 platform or Linux ARM 64-bit platform.

Some compilers can translate source code to bytecode instead machine code. Bytecode, which was first introduced in the Java programming language, is an intermediate language that can be executed on any system platform running a Java virtual machine (JVM) or bytecode interpreter. The JVM or interpreter converts the bytecode into instructions that can be executed by the hardware processor. A JVM also makes it possible for the bytecode to be recompiled by a just-in-time compiler. (See also: Java compiler)

Some compilers can translate source code into another high-level programming language, rather than machine code or bytecode. This type of compiler might be referred to as a transpiler, transcompiler, source-to-source translator or it might go by another name. For example, a developer might use a transpiler to convert COBOL to Java.

Regardless of the source language or the type of output, a compiler must ensure that the logic of the output code always matches that of the input code and that nothing is lost when converting the code. A compiler is, in the strictest sense, a translator and must ensure that the output is correct and preserves all the original logic.

Compilers are sometimes confused with programs called interpreters. Although the two are similar, they differ in important ways. Compilers analyze and convert source code written in languages such as Java, C++, C# or Swift. They're commonly used to generate machine code or bytecode that can be executed by the target host system.

Interpreters do not generate IR code or save generated machine code. They process the code one statement at a time at runtime, without pre-converting the code or preparing it in advance for a particular platform. Interpreters are used for code written in scripting languages such as Perl, PHP, Ruby or Python.

If I am using a Arduino Mega 2560 Rev. 3. Simply put, what compiler is in use? I read and and that provided some help. I saw through a few google searches the AVR-GCC compiler seems to be in use. Can I find out which one specifically? I also know that it is changed to be in correct C format with a basic main function, but how exactly is the .ino turned into .c with the Arduino core functions (Is this simply Arduino.h). Thanks.

I'm not aware of any documentation describing exactly what mucking-about the Arduino IDE does with your sketch .INO file to generate the .cpp file. From observation, it inserts a #include for arduino.h, generates prototypes for the functions and variables defined in the file, and puts all the files it thinks are needed to build your sketch into a temporary directory. I think the algorithm for doing the inserting may have evolved in recent versions since some people have said that it is now possible to pre-empt the auto-generated prototypes by inserting your own prototypes, but that doesn't work for 1.0.4 which I use.

If you use File/Preferences to display the Preferences window and select the 'Show verbose output during: compilation' option then when you verify the sketch it will print the name of the temporary directory where the files generated by the IDE are stored. These are the files actually passed to the compiler. By comparing these .cpp files with the original sketch .ino files and tabs you can get an idea of how the IDE has modified your code to generate the .cpp which is actually compiled.

For documentation purposes, I needed to know the version as I like to brake down the hardware and software setup to be replicated days, weeks, months, or years later. So for an arduino user after finishing a project, it is VERY important.

I once worked for a Fortune 10 company and they could not make what you are inferring work because a workstation simply needs to be cloned with the tools intact, that is, frozen in time. However, this did not work because some license files expired. Your best best is just to put the Arduino installation ZIP into the local/off-site backup with the source. I agree that you need to document it, and while "months " later may be a reality, "years" later is somewhat unrealistic based upon my experience with Y2K projects.

When your working with power utilities and systems, years is common. Half of the project is interfacing with a machine made in 1995(I am not sure they had repositories or version control back then from the looks of it haha) . I have put the arduino 1.0.5 zip stored in there, but since the board design is likely to be recreated and stripped of most of its... Arduinoness? and most people here just do everything in Eclipse or the like they would not want to touch the Arduino IDE. Thanks for the help! (It does seem to be 4.3.2 or 4.3.3)

When your working with power utilities and systems, years is common. Half of the project is interfacing with a machine made in 1995(I am not sure they had repositories or version control back then from the looks of it haha) .

With middleware and PC software, there is little hope of having a sane Backup and Recovery plan that would past scrutiny years down the road. Just having the ZIP or tar-ball in archive does not mean that you can reconstruct perfectly... there are Windows USB drivers and such that may not be supported years down the road... which was my point about having entire machines in warehouses for DR until someone realized that much of the development software had license keys.

I know personally many of the DR folks in the Atlanta office... they have created safety nets and procedures at great cost to manage such scenarios. They spend hundred of hours a year testing the procedures and fine-tuning them. It makes me glad I'm retired.

All the above being said, if you noted my versions in the post, you will see that my system has been patched ahead of yours if you are running plain vanilla. But worst, outside of the software versions that can be coaxed from executables, there are configuration files such as boards.txt and programmers.txt that can impact a successful build, so good documentation is going to have to document those flat files, too, since the time/date code is not to be overly trusted in a Windows world.

Yes, and no. Having your arduino sketch work depends on having a matched (and "working") set of avr-gcc, binutils, avr-libc, avrdude, AND the arduino libraries. Since the Arduino "package" includes all of those, "Arduino 1.0.2" is the correct level of packaging/versioning to be looking at.

You can get individual version numbers by running the individual tools from their homes within the arduino distribution (.../hardware/tools/avr/bin) with the -v or --version or whatever switches. (exact directory is somewhat dependent on OS and Arduino version.)

That depends. It USED to be the case that the Arduino install procedure for linux-like operating systems included installing the avr-gcc compiler separately from the IDE, using your favorite package manger. This lead to a lot of people running into bugs because the version(s) that their linux installed was buggy, buggy WRT Arduino, or mis-packaged. If you download the LATEST Arduino .tgz file, it includes complete copies of ... avr-gcc 4.3.2...

Well, Arduino is about 5 years old. IIRC, they started out using the latest version that was available packaged for both windows (WinAVR) and Mac (CrossPack), and then got burnt with significant bugs in later versions: avr-gcc, avr-libc compiler and toolchain known bugs Issue #1208 arduino/Arduino GitHub (also, WINavr stopped getting updated as well, and Atmel was pretty slow to adopt/suppprt new versions of gcc) (It doesn't help when bug reports to the gcc community get answers like "you're doing it wrong, and it was never supposed to work the way that you're using it.") NOW, it looks like 4.7.2 would be a fine version to jump to, but that's only been true for a couple of months (ie the same time when Atmel switched Atmel Studio to 4.7.2)

There's also the good old 'strings' utility. Dumps all ascii-ish looking strings it finds in the binary. Different compilers embed different amounts of information in the binaries they produce, but many will actually include obviously identifying strings.

Many compilers/linkers insert a .comment section in the output file which identifies them. There are also a number of more subtle behaviors you could create compiler fingerprints off of, but I know of no existing tools for this.

I suppose the issue is coming from the compiler I use (gcc instead?) or simply its version (as the std lib provided by the compiler could change from the version expected by the library AFAIK it could leads to errors at link step).

3a8082e126