Issues in fbc-1.00

General FreeBASIC programming questions.
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Issues in fbc-1.00

Postby TJF » Sep 19, 2014 8:09

dkl wrote:I've just started a wiki page for binding creation issues:
/wiki/DevBindingCreation

This page is highly appreciated, thanks!

dkl wrote:First thing on there: data types. It might already answer your question regarding Integer vs Long. I'm sure I'll have more ideas what to write on this page ;)

Are you sure regarding the int type in C:
http://www.freebasic.net/wiki/DevBindingCreation wrote:In C, int stays 32bit everywhere, ...

AFAIK it's always the word size of the CPU architecture. See

http://de.wikipedia.org/wiki/Integer_%28Datentyp%29 wrote:Ein Integer besteht in der Regel aus 8, 16, 32, 64 oder 128 Bits (also 1, 2, 4, 8 oder 16 Bytes) – entsprechend der Wortbreite der jeweiligen CPU.
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Issues in fbc-1.00

Postby TJF » Sep 19, 2014 8:51

ENUM seems to get a real problem. We cannot use explicit namespaces that way, and the C documentation won't be usable for FB code any more.

What about implementing a possibility to adjust the ENUM size, like

    ENUM<32> name [EXPLICIT]
or
    ENUM32 name [EXPLICIT]
marcov
Posts: 3116
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Issues in fbc-1.00

Postby marcov » Sep 19, 2014 9:04

Something like that, or use a directive(pragma) to set the default enum size to 1/2/4/8 bytes, "default" (to restore to the target default after change) and native (use the size that fits enum ((highest element+1)/8), though I can't quickly think of a binding that utilizes this, maybe because most must be mappable to C.)

if you regard the default enum size as the minimum size, and any larger size must be a power of two above, you can skip the native option (3 byte enum sizes are rare, even if it dynamically changes, it will be 2,4 etc), since then setting the minimum is enough to have the desired effect.

A directive is easier to switch a whole header to a different default instead of manually changing every enum to specify size.
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Issues in fbc-1.00

Postby dkl » Sep 19, 2014 11:00

Yea, I've thought about adding something like

Code: Select all

Enum MyEnum As Long
    A
    B
End Enum


to allow overriding the default Integer. However, Integer is hard-coded in a lot of places in the FB compiler, so it may not be quite easy. I'll give it another look though.

-----

I am pretty sure about int being 32bit - having worked on the 64bit port with this assumption for over 1 year now. Apparently C's int does not conform to Wikipedia's definition of "Integer".

Here's the table with LP64/LLP64 explained:
http://de.wikipedia.org/wiki/64-Bit-Architektur#Programmiermodell
http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
marcov
Posts: 3116
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Issues in fbc-1.00

Postby marcov » Sep 19, 2014 13:22

dkl wrote: Apparently C's int does not conform to Wikipedia's definition of "Integer"


What do you mean with that?
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Issues in fbc-1.00

Postby dkl » Sep 19, 2014 13:55

Well, the German Wikipedia page on Integer currently contains a sentence stating that an Integer typically corresponds to the CPU's word size. It's just worth noting that C's int is different than that, despite the similarity in names.

(Of course the page actually has a "proper" definition of Integer at the top which does not mention size at all, just that it's a data type for holding "whole" numbers)
marcov
Posts: 3116
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Issues in fbc-1.00

Postby marcov » Sep 19, 2014 14:13

dkl wrote:Well, the German Wikipedia page on Integer currently contains a sentence stating that an Integer typically corresponds to the CPU's word size. It's just worth noting that C's int is different than that, despite the similarity in names.


Ah like that. I think that is a general remark for magnitude only, and not really something to be taken literally.

Basically the common consensus seemed to be making int 64-bit is a waste of bandwidth, since it blows up memory structures without much added benefit.

Already back then when I had my first 64-bit experiences (DEC multia (Alpha architecture) with Redhat 5.x), that was the case, and the LP64 was chosen. (and the contender was LLP64, not ILP64)

(Of course the page actually has a "proper" definition of Integer at the top which does not mention size at all, just that it's a data type for holding "whole" numbers)


Yup. It also mentions that integer arithmetic (like evaluation order etc) isn't standardized across languages.
jcfuller
Posts: 324
Joined: Sep 03, 2007 18:40

Re: Issues in fbc-1.00

Postby jcfuller » Sep 19, 2014 15:24

I don't know how relevant my observations are but....
This is the results I get from this code compiled with 32 and 64 FreeBasic and run on
Win7 64
This has an Integer as 8 Bytes under Win64 which I don't think is correct ???

Code: Select all

Dim a As Byte
Dim b As UByte
Dim c As Short
Dim d As UShort
Dim e As Long
Dim f As ULong
Dim g As Integer
Dim h As UInteger
Dim i As LongInt
Dim j As ULongInt
Dim k As Single
Dim l As Double
Dim m As Integer Ptr

Print "Size of Byte "; SizeOf(a)
Print "Size of UByte "; SizeOf(b)
Print "Size of Short "; SizeOf(c)
Print "Size of UShort "; SizeOf(d)
Print "Size of Long "; SizeOf(e)
Print "Size of ULong "; SizeOf(f)
Print "Size of Integer "; SizeOf(g)
Print "Size of UInteger "; SizeOf(h)
Print "Size of LongInt "; SizeOf(i)
Print "Size of ULongInt "; SizeOf(j)
Print "Size of Single "; SizeOf(k)
Print "Size of Double "; SizeOf(l)
Print "Size of Integer Ptr "; SizeOf(m)
sleep


FreeBasic Win32
Size of Byte 1
Size of UByte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of UInteger 4
Size of LongInt 8
Size of ULongInt 8
Size of Single 4
Size of Double 8
Size of Integer Ptr 4

FreeBasic Win64
Size of Byte 1
Size of UByte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 8 ?????
Size of UInteger 8
Size of LongInt 8
Size of ULongInt 8
Size of Single 4
Size of Double 8
Size of Integer Ptr 8

TDM-GCC-32
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 4

TDM-GCC-64
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 8

VC++ 32
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 4

VC++ 64
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 8

PellesC 32
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 4

PellesC 64
Size of Byte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 8
'==============================================================================
To muddy the waters a bit more this is the results I get From Linux Mint64
gcc 4.8.2
c source:

Code: Select all

#include <stdio.h>

int main(int argc, char** argv)
{
    short    c = {0};
    long     e = {0};
    int      g = {0};
    float    k = {0.0};
    double   l = {0.0};
    int*     m = {0};
    printf("%s% d\n", "Size of Short ", (int)sizeof( c));
    printf("%s% d\n", "Size of Long ", (int)sizeof( e));
    printf("%s% d\n", "Size of Integer ", (int)sizeof( g));
    printf("%s% d\n", "Size of Single ", (int)sizeof( k));
    printf("%s% d\n", "Size of Double ", (int)sizeof( l));
    printf("%s% d\n", "Size of Integer Ptr ", (int)sizeof( m));
    return 0;
}


gcc Linux64 (Mint17)
Size of Short 2
Size of Long 8
Size of Integer 4
Size of Single 4
Size of Double 8
Size of Integer Ptr 8

FreeBasic Linux64 (Mint17)
Size of Byte 1
Size of UByte 1
Size of Short 2
Size of UShort 2
Size of Long 4
Size of ULong 4
Size of Integer 8
Size of UInteger 8
Size of LongInt 8
Size of ULongInt 8
Size of Single 4
Size of Double 8
Size of Integer Ptr 8
TJF
Posts: 3612
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Issues in fbc-1.00

Postby TJF » Sep 19, 2014 15:54

VA_ARG, VA_FIRST and VA_NEXT unsupported in -gen gcc mode?
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Issues in fbc-1.00

Postby dkl » Sep 19, 2014 18:05

D.J.Peters wrote:
dkl wrote:I can't reproduce it; the following code compiles fine
Same here :lol:
I copied the latest version of "ftlk-c.bi" to folder "fltk-ide" and the warnings are gone.
The function BoxtypeAsString() is the same as before
but something was different in the older version of "ftlk-c.bi" and trigers the warning's.

Strange but true.

Joshy


I just remembered something: There's an issue where if a .bas or .bi file was saved in a Unicode format (UTF8, UTF16, UTF32, with BOM) then the "..." string literals are seen as wstrings; this could have made them incompatible to the Const Zstring Ptr return type...

TJF wrote:VA_ARG, VA_FIRST and VA_NEXT unsupported in -gen gcc mode?

That's correct - the C backend currently can't support them (perhaps it could on x86 using inline ASM, but on x86_64 the first 6 arguments are passed in registers, so there is no address which could be returned from va_first()).
fxm
Posts: 10259
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Issues in fbc-1.00

Postby fxm » Sep 19, 2014 18:15

TJF wrote:VA_ARG, VA_FIRST and VA_NEXT unsupported in -gen gcc mode?

IMHO, that has never been supported by -gen gcc!
Kot
Posts: 336
Joined: Dec 28, 2006 10:34

Re: Issues in fbc-1.00

Postby Kot » Sep 21, 2014 20:27

I can do this:

#Include "fbgfx.bi"
ScreenRes 800,600
Dim Arr1 As fb.image Ptr = ImageCreate(200,200)

but not this:

#Include "fbgfx.bi"
ScreenRes 800,600
Dim Shared Arr1 As fb.image Ptr = ImageCreate(200,200)

Is it a bug or a feature?
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Issues in fbc-1.00

Postby dkl » Sep 21, 2014 20:30

Global variables don't allow non-constant initializers yet - that's a missing feature. Would be very nice to have though.
dodicat
Posts: 6883
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Issues in fbc-1.00

Postby dodicat » Oct 05, 2014 15:27

(I'll use this thread for this issue, pardon TJF)

code 1 is a C program to multiply (Bigint fashion)
I compile it from mult.c to mult .o then to libmult.a.

The gcc flags are at the top of the code.

code 2 is in freebasic and includes the above .a file as a library file.

No problem running the freebasic code in fb .90

Doesn't work with fb 1.0

code 1 (mult.c)

Code: Select all

 //call this file mult.c
// gcc -O3 -c mult.c
//then
// ar rcs libmult.a mult.o
#include <string.h>

int mod[99]; int div[99];
void setup()
{
int z;
    for(z = 0; z  <= 99; z++)   
   {mod[z]=(z % 10) +48;
    div[z]=z/10;}
}   
   
void multint( char *num1,  char *num2, char *ans)
{
   
    int i,j,n,carry,ai;
    int lnum1=strlen(num1),lnum2=strlen(num2);
    memset(ans, '0', lnum1 + lnum2);
    ans[lnum1 + lnum2] ='\0';
    for( i  = lnum1-1;  i >=0 ; i--)
    {
        ai=num1[i]-48;carry=0;
        for( j  = lnum2-1;  j>=0 ; j--)
        {
    n = ai * (num2[j]-48) + (ans[i+j+1]-48) + carry;
    carry =div[n];ans[i+j+1]=mod[n];
           
        }
         ans[i]+=carry;
    }
   
    if (ans[0] == '0') memmove(ans, ans + 1, lnum1 + lnum2);
    return;
}

         


code 2 (the freebasic test file)

Code: Select all

 '===============================================
#inclib "mult"

extern "c"
declare function multint(n1 as zstring ptr,n2 as zstring ptr,res as zstring ptr) as integer
declare sub setup()
end extern
setup()
dim shared as zstring  * 10000000 _temp_
 function mult(byval n1 as string,byval n2 as string) as string
    dim as zstring ptr s1=cast(zstring ptr,@n1),s2=cast(zstring ptr,@n2)
    dim as zstring ptr ans=cast(zstring ptr,@_temp_)
    multint(s1,s2,ans)
    return *ans
end function
'===============================================
function factorial(n as string) as string
    var fact="1"
        for z as integer=1 to valint(n)
        fact= mult(fact,str(z))
           next z     
    Return fact
  end function
  '============================================
dim as string m1=string(100,"9")
dim as string m2=string(100,"7")
dim as double t1,t2
t1=timer
var ans= mult(m1,m2)
t2=timer
print ans
print "time ";t2-t1
sleep 50
t1=timer
ans= factorial("1000")
t2=timer
print ans
print "time(fact) ";t2-t1
sleep

 
dkl
Site Admin
Posts: 3221
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Issues in fbc-1.00

Postby dkl » Oct 05, 2014 15:46

The mult() function uses Byval As String whose behaviour has been changed in FB 1.00.0; it no longer works like a Zstring Ptr, so you should change it to something like this now:

Code: Select all

function mult(byval n1 as string,byval n2 as string) as string
    dim as zstring ptr s1 = strptr(n1), s2 = strptr(n2)
    dim as zstring ptr ans = @_temp_


Also the multint() declaration should be fixed to match the C side (it does not return an integer there):

Code: Select all

declare sub multint(n1 as zstring ptr, n2 as zstring ptr, res as zstring ptr)

Return to “General”

Who is online

Users browsing this forum: No registered users and 13 guests