Can I directly use the __attribute__((section)) directly as I did in arm gcc or is there any equivalent for the same.. My code has functions utilizing the above construct (which is defined through macro)..
#define PLACE_IN_REGION1 __attribute((section(".section1")))
void function( int ) PLACE_IN_REGION1;
If a similar equivalent is present, I could replace the same without any hassle..
You can use location pragma, in preprocessor macro form:
#define PLACE_IN_REGION1 _Pragma("location=\"section1\"") // section1 is region you have defined in the linker file
PLACE_IN_REGION1 void function(int);
Only difference is that it needs to be at the beginning of the declaration, so you'll need to edit your code a bit.
Related
I run the following ccall's:
status = ccall((:ioperm, "libc"), Int32, (Uint, Uint, Int32), 0x378, 5, 1)
ccall((:outb, "libc"), Void, (Uint8, Uint16), 0x00, 0x378)
After the second ccall I receive the following Error message:
ERROR: ccall: could not find function outb in library libc
in anonymous at no file
in include at ./boot.jl:245
in include_from_node1 at loading.jl:128
in process_options at ./client.jl:285
After some research and messing around I found the following information:
ioperm is in libc, but outb is not
However, both ioperm and outb are defined in the same header file <sys/io.h>
An equivalent version of C code compiles and runs smoothly.
outb in glibc, however on the system glibc is defined as libc
Same problem with full path names /lib/x86_64-linux-gnu/libc.so.6
EDIT:
Thanks for the insight #Employed Russian! I did not look closely enough to realize the extern declaration. Now, all of my above notes make total sense!
Great, we found that ioperm is a libc function that is declared in <sys/io.h>, and that outb is not in libc, but is defined in <sys/io.h> as a volatile assembly instruction.
Which library, or file path should I use?
Implementation of ccall.
However, both ioperm and outb are defined in the same header file <sys/io.h>
By "defined" you actually mean "declared". They are different. On my system:
extern int ioperm (unsigned long int __from, unsigned long int __num,
int __turn_on) __attribute__ ((__nothrow__ , __leaf__));
static __inline void
outb (unsigned char __value, unsigned short int __port)
{
__asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
}
It should now be obvious why you can call ioperm but not outb.
Update 1
I am still lost as to how to correct the error.
You can't import outb from libc. You would have to provide your own native library, e.g.
void my_outb(unsigned char value, unsigned short port) {
outb(value, port);
}
and import my_outb from it. For symmetry, you should probably implement my_ioperm the same way, so you are importing both functions from the same native library.
Update 2
Making a library worked, but in terms of performance it is horrible.
I guess that's why the original is implemented as an inline function: you are only executing a single outb instruction, so the overhead of a function call is significant.
Unoptimized python does x5 better.
Probably by having that same outb instruction inlined into it.
Do you know if outb exist in some other library, not in libc
That is not going to help: you will still have a function call overhead. I am guessing that when you call the imported function from Julia, you probably execute a dlopen and dlsym call, which would impose an overhead of additional several 100s of instructions.
There is probably a way to "bind" the function dynamically once, and then use it repeatedly to make the call (thus avoiding repeated dlopen and dlsym). That should help.
I'm trying to clarify some structs and syntax in OpenCL. Currently I'm working with VS2013 and OpenCL Emulator-Debugger. I started working with the demo project which comes with the emulator and stuck into this:
__Kernel(hello)
__ArgNULL
{
...
}
Just two lines above there is this:
//__kernel void
//hello()
What's the difference between them? As far as I understand from the documentation (here: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/OpenCL-Emu-Documentation-2.pdf
and here: https://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf) the first one is just a Macro definition in the OCL-Emu environment for the second one, but there isn't a clear and definite answer. Is this right?
Yes, it is right, the first one is a macro.
__Kernel() is a macro, and __kernel is a special CL flag to declare a C99 function as a GPU code entry function (kernel function).
So this __Kernel(hello) expands to __kernel hello
And __ArgNULL expands to ().
Giving you normal CL code: __kernel hello() { ... }
In this Emu-CL case, the macros are probably needed, since it doesn't internally expand to CL code. The macros are a way to simplify and adapt the language to a CL-like expressions.
I'll use a simple specific example to illustrate what I'm trying to do.
file main.c:
#include <stdio.h>
unsigned int X;
int main()
{
printf("&X = 0x%zX\r\n", &X);
return 0;
}
I want to know if it's possible (using a linker-script/gcc options) to manually specify an address for X at compile/link time, because I know it lies somewhere in memory, outside my executable.
I only want to know if this is possible, I know I can use a pointer (i.e. unsigned int*) to access a specific memory location (r/w) but that's not what I'm after.
What I'm after is making GCC generate code in which all accesses to global variables/static function variables are either done through a level of indirection, i.e. through a pointer (-fPIC not good enough because static global vars are not accessed via GOT) or their addresses can be manually specified (at link/compile time).
Thank you
What I'm after is making GCC generate code in which all accesses to
global variables/static function variables … their addresses can be
manually specified (at link/compile time).
You can specify the addresses of the .bss and .data sections (which contain the uninitialized and initialized variables respectively) with linker commands. The relative placement of the variables in the sections is up to the compiler/linker.
If you need only individual variables to be placed, this can be done by declaring them extern and specifying their addresses in a file, e. g. addresses.ld:
X = 0x12345678;
(note: spaces around = needed), which is added to the compiler/linker arguments:
cc main.c addresses.ld
I'm trying to write some Rcpp code using Netbeans, primarily using the IDE for the method look-up / code completion. I've set up the project to include the R/include and R/library/Rcpp/include folders, and it seems this -almost- works. For example, if I write
#include <Rcpp.h>
Rcpp::CharacterVector x;
x. // hit CTRL+SPACE to pop-up methods available to x, no hits
However, if we look at what a CharacterVector is, we see:
typedef Vector<STRSXP> CharacterVector
which is defined in Rcpp/include/vector/instanstiation.h, so it should (?) just be inheriting all the methods available to the Rcpp::Vector class. Equivalently, if I write
Rcpp::Vector<STRSXP> x;
x. // hit CTRL+SPACE, and I do see a bunch of methods available
it does work. Furthermore, if I just copy the typedef declaration into my current source file, then the auto-completion does work.
So, I guess my question is - why does Netbeans struggle in finding the methods available to Rcpp::CharacterVector but not Rcpp::Vector?
Ultimately, it's not a big problem, but I am curious...
I really like using the _countof() macro in VS and I'm wondering if there is an OS-generic implementation of this in Qt.
For those unaware, _countof() gives you the number of elements in the array. so,
wchar_t buf[256];
_countof(buf) => 256 (characters)
sizeof(buf) => 512 (bytes)
It's very nice for use with, say, unicode strings, where it gives you character count.
I'm hoping Qt has a generic version.
_countof is probably defined like this:
#define _countof(arr) (sizeof(arr) / sizeof((arr)[0]))
You can use a definition like this with any compiler and OS.
If there is no such macro provided by Qt you can simply define a custom one yourself in one of your header files.
sth's code will work fine, but won't detect when you're trying to get the size of a pointer rather than an array. The MS solution does this (as danielweberdlc says), but it's possible to have this as a standard solution for C++:
#if defined(Q_OS_WIN)
#define ARRAYLENGTH(x) _countof(x)
#else // !Q_OS_WIN
template< typename T, std::size_t N >
inline std::size_t ARRAYLENGTH(T(&)[N]) { return N; }
#endif // !Q_OS_WIN
A more detailed description of this solution is given here.