Some C compilers emit assembly language and allow snippets of assembly to be placed inline in the source code to be copied verbatim to the output, e.g. https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html
Some compilers for higher-level languages emit C, ranging from Nim which was to some extent designed for that, to Scheme which very definitely was not, and takes heroic effort to compile to efficient code that way.
Do any such compilers, similarly allow snippets of C to be placed inline in the source code, to be copied verbatim to the output?
I'm not sure I understand what you mean by "be copied verbatim to the output," but all C compilers (msvc, gcc, clang, etc...) have preprocessor directives that essentially allow snippets of code to be added to the source files for compilation. For example, the #include directive will pull in the contents the specified file to be included in compilation. An "effect" of this is that you can do weird things such as:
printf("My code: \n%s\n",
#include "/tmp/somefile.c"
);
Alternatively, creating macros with the #define directive allows you to supplant snippets of code by calling a macro name. This all happens at the preprocessor stage before turning into the compile "output."
Other languages, like c# with roslyn, allows runtime compilation of code. Of course, you can also implement the same within c by calling your compiler as via something like system() and then loading the resulting library with dlopen.
Edit:
Now that I come back and think about this question, I should also note that python is one of those C-targeting "compilers" (I guess technically a interpreter on top of the python runtime). Python let's you use native C compiled code with some either some py API code to export functions or directly with some dlopen-like helpers. Take a look at the inlinec module that does what I described above (call the compiler then load the compiled code). I suppose you should have the ability to do similar functionality with any language that can call c compiled code (c#, java, etc...).
Related
I am trying to learn C and I have this C file that I want view the macros of. Is there a tool to view the macros of the compiled C file.
No. That's literally impossible.
The preprocessor is a textual replacement that happens before the main compile pass. There is no difference between using a macro and putting the code the macro expands to in its place.*
*Ignoring the debugger output. But even then you can do it if you know the right #pragma to tell it the file and line number.
They're always defined in the header file(s) that you've imported with #include, or that those files in turn #include.
This may involve a lot of digging. It may involve going into files that make no sense to you because they're not written for casual inspection.
Any macros of any importance are usually documented. They may use other more complex implementation-specific macros that you shouldn't concern yourself with ordinarily, but if you're curious how they work the source is all there.
That being said, this is only relevant if you have the source and more specifically a complete build environment. Once compiled all these definitions, like the source itself, do not appear in the executable and cannot be inferred directly from the executable, especially not a release build.
Unlike Java or C#, C compiles directly to machine code so there's no way to easily reverse that back to the source. There are "decompilers" that try, but they can only really guess as to the original source. VM-based languages like Java and C# only lightly compile the code, sot here are a lot of hints as to how that code was generated and reversing it is an easier process.
I want to write some inline assembly in a DOS program which is compiled using Turbo C 2.01. When I write
asm {
nop
}
the compiler claims that in-line assembly is not allowed in function .... See:
Any ideas?
See the Turbo C user manual page 430:
Inline assembly not allowed
Your source file contains inline assembly language statements and you are compiling it from within the
Integrated Environment. You must use the TCC command to compile this
source file.
I believe that you need also to pass the -B option to TCC (page 455).
Alternatively you can use __emit__ (page 103) for relatively simple code entered as machine code rather than assembler mnemonics.
It seems an odd restriction to not allow inline assembly in the IDE. You might consider "upgrading" to Turbo C++ 3.0 which I believe does allow it. I would imagine that TC++ will compile C code when presented with a .c file, or that the IDE can be set to compile C explicitly. There's a manual for that too.
Turbo C converts C code directly into machine code without using an assembler phase, and thus cannot include assembly language source within a program. What it can do, however, is use the __emit directive to insert machine code. The cleanest way to use that is probably to use a separate assembler (or perhaps DEBUG) to process the code of interest by itself into a COM file, and then enter the byte values therein into an __emit directive. Parameters are stored in ascending order left to right, starting at either BP+4 (in tiny, small, or compact model) or BP+6 (medium, large, or huge). Local variables are stored at addresses below BP.
When using Turbo Pascal, it's possible to use a handy program called "inline assembler" to convert assembly-language source into a Turbo Pascal literal-code directive. Turbo Pascal's directive is formatted differently from C's (I like Pascal's better) and can accommodate labels in ways Turbo C's cannot. Still, using __emit may have far less impact on build times than trying to use inline assembly code.
I am modifying some code for a Blackfin processor using VisualDSP++ v. 5.0. I have noticed that all of the header files in this project utilize the following convention:
#ifdef _LANGUAGE_C
/* All of the code associated with this header file. */
#endif
After searching through the documentation for this compiler I found the following:
_LANGUAGE_C - Always defined as 1.
So my question is two-fold.
What is the purpose of using #ifdef _LANGUAGE_C?
Wouldn't this just keep your code from running on a different compiler that may not have a macro defined for _LANGUAGE_C?
You have to look at how it is used in context, however I believe that in this case it is used in headers that are used in both C code and assembler where the assembler code utilises the C pre-processor. It allows C headers to be included in assembler code, and have the preprocessor remove the C code specific elements.
For example it is useful in assembler code to have the same #define ... constant macro values as the C code to avoid duplication and inconsistency, but a struct definition or function prototype for example would be meaningless.
I would expect perhaps:#if defined(_LANGUAGE_C) || defined(_LANGUAGE_C_PLUS_PLUS), but if the documentation says that it is always defined, perhaps it is defined for both C and C++ compilation in your case.
To answer your compound question, the answer is yes, for the most part. This is part of some pre processor directives that allow you to build for different environments using the same code. If you look through the windows driver kit for example, you see this convention utilized all over the place to ensure that the most efficient code is build depending on the target environment and compiler. I hope this is helpful. The could have potentially added code in there after the #ifdef with another for _LANGUAGE_CPP and put C++ specific code in there etc etc.
It is called a compilation constant, such compilation constant must be added to your build environment, you should check your build environment. It is to tell the compiler that the code it going to compile are to compiled with C specific checks and will generate outfut file(hex or bin) depending on that.
I always read things about how certain functions within the C programming language are optimized by being written in assembly. Let me apologize if that sentence sounds a little misguided.
So, I'll put it clearly: How is it that when you call some functions like strlen on UNIX/C systems, the actual function you're calling is written in assembly? Can you write assembly right into C programs somehow or is it an external call situation? Is it part of the C standard to be able to do this, or is it an operating system specific thing?
The C standard dictates what each library function must do rather than how it is implemented.
Almost all known implementations of C are compiled into machine language. It is up to the implementers of the C compiler/library how they choose to implement functions like strlen. They could choose to implement it in C and compile it to an object, or they could choose to write it in assembly and assemble it to an object. Or they could implement it some other way. It doesn't matter so long as you get the right effect and result when you call strlen.
Now, as it happens, many C toolsets do allow you to write inline assembly, but that is absolutely not part of the standard. Any such facilties have to be included as extensions to the C standard.
At the end of the road compiled programs and programs in assembly are all machine language, so they can call each other. The way this is done is by having the assembly code use the same calling conventions (way to prepare for a call, prepare parameters and such) as the program written in C. An overview of popular calling conventions for x86 processors can be found here.
Many (most?) C compilers do happen to support inline assembly, though it's not part of the standard. That said, there's no strict need for a compiler to support any such thing.
First, recognize that assembly is mostly just human (semi-)readable machine code, and that C ends up as machine code anyway.
"Calling" a C function just generates a set of instructions that prepare registers, the stack, and/or some other machine-dependent mechanism according to some established calling convention, and then jumps to the start of the called function.
A block of assembly code can conform to the appropriate calling convention, and thus generate a blob of machine code that another blob of machine code that was originally written in C is able to call. The reverse is, of course, also possible.
The details of the calling convention, the assembly process, and the linking process (to link the assembly-generated object file with the C-generated object file) may all vary wildly between platforms, compilers, and linkers. A good assembly tutorial for your platform of choice will probably cover such details.
I happen to like the x86-centric PC Assembly Tutorial, which specifically addresses interfacing assembly and C code.
When C code is compiled by gcc, it's first compiled to assembler instructions, which are then again compiled to a binary, machine-executable file. You can see the generated assembler instructions by specifying -S, as in gcc file.c -S.
Assembler code just passes the first stage of C-to-assembler compilation and is then indistinguishable from code compiled from C.
One way to do it is to use inline assembler. That means you can write assembler code directly into your C code. The specific syntax is compiler-specific. For example, see GCC syntax and MS Visual C++ syntax.
You can write inline assembly in your C code. The syntax for this is highly compiler specific but the asm keyword is ususally used. Look into inline assembly for more information.
I'd really like to get more into D, but the lack of good library support is really hindering me. Therefore I'd like to create some D bindings for existing C libraries I'd like to use. I've never done any binding, but it doesn't look too difficult either.
I'm planning to do this for D2 (not specifically D1, but if it could be for both, even better). I am using the DMD2 compiler.
What conventions should be used (I noticed version statements, aliases and regular constants / function definitions)?
What would be the difference between binding to a static library (and thus linked against) or a dynamic library? Is there any difference in the binding?
For binding a static library, the DMD compiler doesn't seem to accept .a or .o files, only .lib and .obj. Does this mean the libraries must be compiled with the DMC compiler (as opposed to the GCC compiler), and then linked through the DMD compiler?
If someone had a very short example of how a binding would be accomplished, I would be great full. Currently I can compile C code with DMC, link the object files and run functions from the C code in D. However, most C libraries just need a header file inclusion AND need to be linked against in C. I'm uncertain how to make bindings that work for that...
Thanks!
A few things to note:
DMD and its linker Optlink work with the older OMF object file format, not COFF. This means that the C files you link against need to also be OMF. If you don't want to use DMC, there are tools that will convert COFF to OMF, though I don't know the details about them.
As far as translating .h files to .d files, a utility called htod is packaged with DMD, and will do this translation for you, albeit somewhat imperfectly if you severely abuse the preprocessor. Generally, you use const, immutable, or enum for manifest constants, version statements for conditional compilation, and regular (possibly templated) functions for macro functions.
As far as examples, one place to look would be in druntime, which contains bindings for the entire C standard library.
You may have a look at how Aldacron does with Derelict2.