Pure FB Runtime Library (in progress)
Pure FB Runtime Library (in progress)
So for those who missed it here I am going to attempt to convert the freeBASIC rtlib to FB. I am going to post my progress and questions here, so if anyone is interested or wants to help in any way, this is the place to do it. I plan to make this a stand alone library first. Make small pieces and test them one at a time. This will make progress and testing a bit more manageable.
First things first: I am going to try and work on the error handling/reporting first because EVERY other part of the rtlib uses it in some way.
EDIT:
I have a git repo for this project here: https://github.com/ImortisInglorian/fbrtLib
At this point I have only confirmed that it will compile with what I have. I have been going back and fixing bugs in my translations in older files as they crop up during the compile process. I am using posidenFB as my IDE and the project file for it is in the repo. I am compiling it as a static library as I figured that would make testing it much easier when I have something testable.
It is not in a usable state.
If you want to eye-ball the code and point out how stupid I am or how many errors I have made (please be specific), feel free. I have commented out things that are not yet needed, and left thing in that will not compile on a windows environment since that is what I am working in.
I am getting 5 to 6 files converted a day, which is not great, but it's what I can do and still get work done and have a life outside of work and coding.
First things first: I am going to try and work on the error handling/reporting first because EVERY other part of the rtlib uses it in some way.
EDIT:
I have a git repo for this project here: https://github.com/ImortisInglorian/fbrtLib
At this point I have only confirmed that it will compile with what I have. I have been going back and fixing bugs in my translations in older files as they crop up during the compile process. I am using posidenFB as my IDE and the project file for it is in the repo. I am compiling it as a static library as I figured that would make testing it much easier when I have something testable.
It is not in a usable state.
If you want to eye-ball the code and point out how stupid I am or how many errors I have made (please be specific), feel free. I have commented out things that are not yet needed, and left thing in that will not compile on a windows environment since that is what I am working in.
I am getting 5 to 6 files converted a day, which is not great, but it's what I can do and still get work done and have a life outside of work and coding.
Last edited by Imortis on Sep 28, 2017 13:12, edited 1 time in total.
-
- Posts: 1002
- Joined: Jul 14, 2005 23:41
Re: Pure FB Runtime Library (in progress)
Awesome Imortis, I'm sure that there's many people here that will love to help as much as we can. Good luck!
Re: Pure FB Runtime Library (in progress)
I have already run in to a bit of a conundrum...
When did Solaris support get added to the RTLib, and why is there no __FB_SOLARIS__ define?
When did Solaris support get added to the RTLib, and why is there no __FB_SOLARIS__ define?
Re: Pure FB Runtime Library (in progress)
I had never even noticed Solaris support before. It was added in 2015 by Stefan Schmidt
Don't worry about details like that. You can use __FB_SOLARIS__ even though it doesn't exist yet. Someone can add it to the compiler later.
Don't worry about details like that. You can use __FB_SOLARIS__ even though it doesn't exist yet. Someone can add it to the compiler later.
Re: Pure FB Runtime Library (in progress)
Is there some (public) VCS repository one could follow? (e.g. on GitHub or BitBucket)
Re: Pure FB Runtime Library (in progress)
Not yet. I will make a github repo once Ihave something usable. Right now It is mostly just grunt work of converting all the ground work so other things can work.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Pure FB Runtime Library (in progress)
Do we have provisioning yet for including bas files when compiling the rtlib?
I wouldn't have thought it would be too hard, but feels like an important first step.
I wouldn't have thought it would be too hard, but feels like an important first step.
Re: Pure FB Runtime Library (in progress)
My goal is to make it a standalone lib at first, so I can test it alongside the current to make sure everything works as it did before. That way, I don't have to include single objects to the current, I can include the whole thing all at once when I get it working.counting_pine wrote:Do we have provisioning yet for including bas files when compiling the rtlib?
I wouldn't have thought it would be too hard, but feels like an important first step.
Re: Pure FB Runtime Library (in progress)
This bit is using inline asm. I have never used that part of FB, and while I am sure I could figure it out over time, it would be quicker if someone more familiar could take a look at it.
Code: Select all
/' CPU-dependent macros and inline functions *'/
#ifdef HOST_X86
static __inline__ int FB_MEMCMP( const void *p1, const void *p2, size_t len )
{
int res;
if( len==0 )
return 0;
__asm volatile (
" pushl %%esi \n"
" pushl %%edi \n"
" repe \n"
" cmpsb \n"
" je 0f \n"
" movl $1, %%ecx \n"
" ja 0f \n"
" neg %%ecx \n"
"0: \n"
" popl %%edi \n"
" popl %%esi \n"
: "=c" (res)
: "c" (len), "S" (p1), "D" (p2)
);
return res;
}
static __inline__ void *FB_MEMCPY( void *dest, const void *src, size_t n )
{
__asm volatile (
" pushl %%ecx \n"
" pushl %%esi \n"
" pushl %%edi \n"
" pushl %%ecx \n"
" shrl $2,%%ecx \n"
" rep \n"
" movsd \n"
" popl %%ecx \n"
" andl $3,%%ecx \n"
" rep \n"
" movsb \n"
" popl %%edi \n"
" popl %%esi \n"
" popl %%ecx \n"
:
: "c" (n), "S" (src), "D" (dest)
);
return dest;
}
/'* Same as FB_MEMCPY but returns position after destination string.
'/
static __inline__ void *FB_MEMCPYX( void *dest, const void *src, size_t n )
{
__asm volatile (
" pushl %%ecx \n"
" pushl %%esi \n"
" pushl %%ecx \n"
" shrl $2,%%ecx \n"
" rep \n"
" movsd \n"
" popl %%ecx \n"
" andl $3,%%ecx \n"
" rep \n"
" movsb \n"
" popl %%esi \n"
" popl %%ecx \n"
: "=D" (dest)
: "c" (n), "S" (src), "D" (dest)
);
return dest;
}
static __inline__ const void *FB_MEMCHR( const void *s, int c, size_t n )
{
const void *dst;
if( n==0 )
return NULL;
__asm volatile (
" pushl %%ecx \n"
" pushf \n"
" cld \n"
" repne \n"
" scasb \n"
" jne 0f \n"
" dec %%edi \n"
" jmp 1f \n"
"0: \n"
" xorl %%edi, %%edi \n"
"1: \n"
" popf \n"
" popl %%ecx \n"
: "=D" (dst)
: "c" (n), "a" (c), "D" (s)
);
return dst;
}
/'* Searches for the first ocurrence of a character unequal to c.
'/
static __inline__ size_t FB_MEMLEN( const void *s, int c, size_t n )
{
size_t len;
if( n==0 )
return 0;
__asm volatile (
" pushl %%edi \n"
" pushf \n"
" std \n" /* DF = 1 -> from hi to lo */
" repe \n"
" scasb \n"
" je 0f \n"
" inc %%ecx \n"
"0: \n"
" popf \n"
" popl %%edi \n"
: "=c" (len)
: "c" (n), "a" (c), "D" ((const char*) s + n - 1)
);
return len;
}
#define RORW(num, bits) __asm__ __volatile__("rorw %1, %0" : "=m"(num) : "c"(bits) : "memory")
#define RORW1(num) __asm__ __volatile__("rorw $1, %0" : "=m"(bit) : : "memory");
#else
/' We use memcmp from C because the compiler might replace this by a built-in
* function which will definately be faster than our own implementation in C. '/
#define FB_MEMCMP(p1, p2, len) memcmp( p1, p2, len )
#define FB_MEMCPY( dest, src, n ) memcpy(dest, src, n)
#define FB_MEMCHR( s, c, n ) memchr( s, c, n )
/' We have to wrap memcpy here because our MEMCPYX should return the position
* after the destination string. '/
static __inline__ void *FB_MEMCPYX( void *dest, const void *src, size_t n )
{
memcpy(dest, src, n);
return ((char *)dest)+n;
}
static __inline__ size_t FB_MEMLEN( const void *s, int c, size_t n )
{
const char *pachData = (const char*) s;
while (n--) {
if( pachData[n]!=(char)c )
return n+1;
}
return 0;
}
#define RORW(num, bits) num = (((((num) & &hFFFF) >> (bits) ) | ((num) << (16 - bits))) & &hFFFF)
#define RORW1(num) RORW(num, 1)
#endif
Re: Pure FB Runtime Library (in progress)
The set of functions you posted using raw assembly are guarded by a preprocessor check. They are completely optional; just ignore it.
I have no idea why the rtlib includes asm versions of standard C function calls. Probably they should just be deleted; the C versions, either in libc or a compiler intrinsic, are likely to be many times faster than those naive asm versions.
(That said, sometimes glibc tries to be too clever and has major performance problems. I noticed that a certain x64 cpu-specific memcmp specialisation in glibc is over 10x slower on my AMD CPU than the 32 bit version of memcmp; it seems to be using some fancy new instructions that AMD didn't optimise. I've also seen an intern at Intel try to get a braindead CPU-specific memcpy specialisation into glibc that used a different version of memcpy for every length up to about 256 bytes, icache be damned!)
I have no idea why the rtlib includes asm versions of standard C function calls. Probably they should just be deleted; the C versions, either in libc or a compiler intrinsic, are likely to be many times faster than those naive asm versions.
(That said, sometimes glibc tries to be too clever and has major performance problems. I noticed that a certain x64 cpu-specific memcmp specialisation in glibc is over 10x slower on my AMD CPU than the 32 bit version of memcmp; it seems to be using some fancy new instructions that AMD didn't optimise. I've also seen an intern at Intel try to get a braindead CPU-specific memcpy specialisation into glibc that used a different version of memcpy for every length up to about 256 bytes, icache be damned!)
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Pure FB Runtime Library (in progress)
The asm code was possibly more relevant when we only had a 'gas' emitter. (Thankfully FB has fewer gas emissions now :)
Now seems like a good time to remove the assembly. We could always re-add it at a later date if need be.
Edit: actually, given it's used specifically within the rtlib, I don't think it can have been related to the old emitter.
Either it was actually faster, or someone was just being "clever", and never actually benchmarked it.
Now seems like a good time to remove the assembly. We could always re-add it at a later date if need be.
Edit: actually, given it's used specifically within the rtlib, I don't think it can have been related to the old emitter.
Either it was actually faster, or someone was just being "clever", and never actually benchmarked it.
Re: Pure FB Runtime Library (in progress)
Thanks guys. I will just include the crt versions then.
Re: Pure FB Runtime Library (in progress)
What are the cross-backend asm options?
Re: Pure FB Runtime Library (in progress)
A pure fb runtime library, geared up for a C backend?
I am confused!
Surely I misunderstand something.
I am confused!
Surely I misunderstand something.
Re: Pure FB Runtime Library (in progress)
I don't know what you mean here...dodicat wrote:geared up for a C backend?