I have been working on RiscV Vector extension and I have found this repo as my test processor. But since I have a memory-bound code, for reducing the latency I should change the memory width from 32 to 64 bit. My question is how does this change effect the makefile (for generating .vmem) and linker file of the processor.
Here are both files:
Makefile
Linker
Related
this is my first Stackoverflow question :-)
My background:
2 years Python experience
2 months crystal-lang experience ( websites running with Amber framework )
1 month into C, C++ , assembly
Facts:
- crystal-lang is compiling and running without any problem
- running on x86_64
Please be nice, as i don't have much low-level language knowledge yet.
From my understanding, when we compile and run a basic hello.c file using LLVM, it goes as follow:
hello.c :
#include
int main() {
printf("hello world\n");
return 0;
}
shell :
$ clang -O3 -emit-llvm hello.c -c -o hello.bc
$ llc hello.bc -o hello.s
$ gcc hello.s -o hello.native
$ ./hello.native
this comes from the LLVM examples )
My point is that we can produce a pretty short hello.bc file (128 lines) that can be run in a slower way using:
$ lli hello.bc
but when I tried to generate a similar hello.bc from a hello.cr file and run it like i did with the hello.c file:
hello.cr :
puts "hello world"
shell :
$ crystal build hello.cr --emit llvm-bc --release
$ llc hello.bc -o hello.s
what i noticed:
This hello.bc file is much much bigger than the one generating from the c file (43'624 lines)
This hello.bc can't be run using "lli" as it generates an:
"LLVM ERROR: Program used external function 'pcre_malloc' which could not be resolved!
I can't even compile from hello.s to hello.native
Same problem if i try to use generate and hello.ll file
As i understood, LLVM is portable , and that all front-end languages would produce an intermediate *.bc that can then be compiled to any architecture.
My questions are:
Why are the hello.bc not similar in both cases ?
Am I doing something wrong in the crystal procedure ?
Thank you!
Everything is just as it is supposed to be. Crystal has a runtime library that is always present even if you didn't include anything. This is required to run the Crystal program.
The C example pretty much doesn't contain anything else than a syscall to printf. That's why the compiled ASM is also really tiny.
Crystal's simple puts call has a much more behind it. It is based on libraries for handling asynchronous IO, concurrency, signal handling, garbage collection and more. Some of these libraries are completely implemented in the Crystal standard library, some use other libraries that are either directly embedded into the binary (libgc) or still require dynamic libraries from the system (libpcre, libpthread).
Any Crystal program comes with this runtime library by default. Even an empty program. This usually goes completely unnoticed because larger programs will eventually need those things anyway and the compiled binary size of the runtime library is less than 500 KB (in release mode).
Such a small program like yours doesn't really need all of this just to print a string. But these libraries are required for the Crystal runtime.
NOTE: You can compile a Crystal program without these default libraries. But this means you can't use anything from the Crystal stdlib and you have to essentially write C code with Crystal syntax (or implement your own stdlib):
require "lib_c"
require "c/stdio"
LibC.printf pointerof("hello world".#c)
This can be compiled with --prelude=empty option and it will generate a substantially smaller ASM, roughly similar to the C example.
The normal way to run an OpenCL program is to include the openCL kernel that is compiled at runtime (online compilation).
But I've seen examples of compiling OpenCL to binary before, called offline compilation. I'm aware of the disadvantages (reducing compatibility across hardware).
There used to be an offline compiler at http://www.fixstars.com/en/ but it does not seems to be available anymore.
So is there an offline compiler for OpenCL available, in particular for NVIDIA-based cards?
Someone suggested that nvcc.exe in NVidia's CUDA SDK could compile .cl files with
nvcc -x cu file.cl -o file.out -lOpenCL
...but it says missing cl.exe at least on Windows. This might be worth checking out, however: http://clcc.sourceforge.net/
As well as:
https://github.com/HSAFoundation/CLOC (AMD-maintained offline compiler)
https://github.com/Maratyszcza/clcc (includes also links to above ones and more)
I have been making programs for ages that are under 800K on Linux Fedora 19 using GCC 4.8.1. The readelf utility has reported them as OS/ABI = "UNIX - System V" (byte 8 is zero).
Now suddenly the binaries are turning out over 1MB and readelf is saying they are "UNIX - GNU" (byte 8 is 3). Not my doing! Something is having an influence and I'm not sure what.
For instance, now, using nm, I find that the functions __nss_hosts_lookup2 and openat are being linked in, which weren't there before.
How do I make an executable again that readelf would say is UNIX - System V ?
I found it! All on my own. The linker was picking up the October 2007 versions of libc.a libm.a and libstdc++.a in the library directory I supplied (providing 780K executables). After deleting those files it started picking up the March 2013 versions and so bloated the executable (1.1M). I'll have to leave it bloated unfortunately because I don't want to have to find all the necessary header files (as of course the header files should match the libraries). I don't blame the software writers for not putting one function per source/object file. I blame the linker for still not dragging in function by function granularity and doing cyclic library search as standard.
I use Qt5, msvc2010, windows7 64bit.
I want to test if i can link libpq.lib.
http://www.postgresql.org/docs/9.2/static/libpq-example.html
I build the above example in QtCreator.
And get
error LNK2019: unresolved external symbol _PQconnectdb in function "_main"
I check my libpq.lib use dumpbin libpq.lib /exports
And get
1 PQconnectdb
156 PQconnectdbParams
How to See the Contents of Windows library (*.lib)
so difference is PQconnectdb and _PQconnectdb.
Is that underscore that makes the linker can't find the real symbol PQconnectdb?
Why the compiler add an underscore to the symbol?
How can I solve this problem?
Is that underscore that makes the linker can't find the real symbol
PQconnectdb? Why the compiler add an underscore to the symbol?
This is the __cdecl convention that is still in effect for x86 (32 bits) but has been obsoleted for 64 bits builds.
Since dumpbin libpq.lib /exports shows no underscores, it means that this library comes from a 64 bits build.
To produce a 32 bits program, replace your libraries with the lib directory from a 32 bits PostgreSQL zip archive. The contents will be compatible with your current build configuration that appears to be 32 bits.
On the other hand, to produce a 64 bits program, configure Qt Creator to use a 64 bits "Kit" (e.g. in Qt Creator 3, Projects tab, see Add Kit in the Build & Run panel) with the 64 bits PostgreSQL libraries you already have.
I want to compile a program using the standard ./configure , make, make install.
I am using 64 bits machine but I want the executable to be 32 bits executable.
What is the way to do this, I did ./configure --help but saw nothing on this (it has the --disable-64bit but it does not seem to do the work
What is the platform and compiler?
I'd be inclined to say either:
run configure to get your Makefile and then add then relevant compiler option to the CFLAGS macro, e.g. CFLAGS=${CFLAGS} -m32 for Sun cc, or
add that macro edit to the Makefile.in file being used as a template by configure.
Edit:
Forgot to add that I've done both several times before when I needed to.