Extern or extrn in B? - extern

I have a confusion between two B keywords.
The official B reference manual uses extrn keyword, while Wikipedia and C use extern.
As I don't know any good B compiler for x86, I can't spellcheck using a compiler.
So, what's the correct way of writing extern keyword in B - extern or extrn?

I'm no B programmer, but I would say extrn is right.
Sources: here and here.
Source 1 even explicitly states:
What’s different compared to C?
extrn keyword instead of extern keyword.

Related

What is the semantics of langtypes C and STDCALL for .MODEL in MASM assembly?

What is the semantics of langtypes C and STDCALL for .MODEL in MASM assembly?
.MODEL memorymodel [[, langtype]] [[, stackoption]]
https://msdn.microsoft.com/en-us/library/ss9fh0d6.aspx
I notice that I can only call a .asm function from C++ code, if the .MODEL includes the C langtype.
But what does these langtypes mean?
I've tried Googling around, but even thus the above link mentions the possible langtypes, no description is provided.
Can someone clarify the semantics of langtypes and provide a link for proper documentation?

Inline assembly __sync_fetch_and_add and __sync_add_and_fetch

The GCC builtin __sync_fetch_and_add is an implementation of the x86 inline assembly:
asm("lock; xaddl %%eax, %2;"
:"=a" (val)
: "a" (val), "m" (*ptr) : )
How can I implement this inline assembly using the addl instruction instead of xaddl?
And another question that I have is how would be the x86 inline assembly of the builtin __sync_add_and_fetch ?
Thanks.
Builtins do not necessarily correspond with a single well defined chunk of assembly code. In particular both __sync_add_and_fetch and __sync_fetch_and_add will generate lock addl instead of lock xaddl if the result is not live out of the builtin, and they may generate lock incl if the result is not live out and the second argument is known to have the value 1.
It is not clear what you mean by "how can I implement this inline assembly". Assembly is something that you write or generate, not something that you implement (unless you are writing an assembler).

Equivalent for GCC's naked attribute

I've got an application written in pure C, mixed with some functions that contain pure ASM. Naked attribute isn't available for x86 (why? why?!) and my asm functions don't like when prologue and epilogue is messing with the stack. Is it somehow possible to create a pure assembler function that can be referenced from C code parts? I simply need the address of such ASM function.
Just use asm() outside a function block. The argument of asm() is simply ignored by the compiler and passed directly on to the assembler. For complex functions a separate assembly source file is the better option to avoid the awkward syntax.
Example:
#include <stdio.h>
asm("_one: \n\
movl $1,%eax \n\
ret \n\
");
int one();
int main() {
printf("result: %d\n", one());
return 0;
}
PS: Make sure you understand the calling conventions of your platform. Many times you can not just copy/past assembly code.
PPS: If you care about performance, use extended asm instead. Extended asm essentially inlines the assembly code into your C/C++ code and is much faster, especially for short assembly functions. For larger assembly functions a seperate assembly source file is preferable, so this answer is really a hack for the rare case that you need a function pointer to a small assembly function.
Good news everyone. GCC developers finally implemented attribute((naked)) for x86. The feature will be available in GCC 8.
Certainly, just create a .s file (assembly source), which is run through gas (the assembler) to create a normal object file.

Do I have to specify extern "C" when exporting symbols?

I am wondering if extern "C" is a must or not?
Only if you want to call your code from C (or a different C++ compiler, which you should treat like C).
It is to disable name-mangling.
See this article on the C++ FAQ: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
No, you use extern "C" to provide a C-linkage to your C++ functions, so they won't be 'decorated' like normal C++ functions and to allow them to be called from C (or Objective-C).
Function decoration is used to implement the C++ function overloading feature and gives each variation of the function a different signature while allowing the developer to use the name he assigned.
Your C++ functions will be exported automatically by simply not using the static keyword. However if you have implemented your C++ functions within a Windows DLL it's necessary to use the declspec dllexport/dllimport keywords to access them externally.
Use of extern "C" switches off name mangling. If you don't do this you may make if hard for a client of your DLL to import your symbols.
Remember that different C++ compilers have different name mangling rules and so your mangled exported names may differ from the names used on import.
However, since it is wrong to import a class from a DLL if you are using a different compiler than that used for the DLL, this is rather a moot point.
So, if you are exporting classes (usually a bad idea anyway) it is easier to leave mangling on. Otherwise switch it off with extern "C".

Calling a C++ function from a C program

How can I call a C++ function from a C program, is it possible?, and if it is how can I do it?. Thank you.
If you are trying to call a C++ function from C, then you are probably running into name mangling issues. The compiler does this in order to support function overloading and other features of C++.
You can use extern "C" to inform the C++ compiler that the function CMACInit() will be called from C code:
extern "C" CMACInit() { ... }
When declared in this way, the C++ compiler will not mangle the name and will set everything up so the function can be called from C code.

Resources