FreeBASIC 1.10.1 Release Discussion

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.10.0 Development

Post by coderJeff »

I think the purpose of TYPE() should be to create a temporary instance as advertised.

Only if there is no constructor/destructor/function calls, then I think we would like to optimize out the temporary instance variables.

Therefore, similarly, should have a temporary variable:

Code: Select all

type t1            : dim as integer i : end type
type t2 extends t1 : dim as integer j : end type
type t3 extends t2 : dim as integer k : end type
type t4 extends t3 : dim as integer l : end type

function f() as integer
	static i as integer = 0
	print "f()"
	i += 1
	function = i
end function

Dim As T2 a = Type<T4>(f(),f(),f(),f())
print a.i, a.j  '' 1, 2
Dim As T2 b = Type<T4>(f(),f(),f(),f())
print b.i, b.j  '' 5, 6

But for 'type<a>(type<d>(type<c> ....' where all the discarded initializers are constants only, then it would be nice to avoid the temporary variables.

Anyways, continuing to work on this today.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.10.0 Development

Post by coderJeff »

coderJeff wrote: Jan 03, 2023 14:05 But for 'type<a>(type<d>(type<c> ....' where all the discarded initializers are constants only, then it would be nice to avoid the temporary variables.
I updated fbc/master that should give some better code generation. In some cases, instead of creating a temporary instance, the initializers are directly assigned to the variable / array.

I didn't add any new tests for this update since the idea is that it should work with everything we've covered so far. Only the backend code generation should be better - which is hard to test other than looking at the raw emitted c/asm code.

With this last update:
- '-w upcast' again will generate warnings if constant initializers are discarded.
- If the type has a destructor or any of the initializers would call a function or any constructor, then the initializer will (should) fully create a temporary instance before up-casting.
- if no-upcasting is involved, then there should be no new bugs with old code (I truly sincerely hope) since all of the changes (in theory) only have to do with up-casting.

There is certainly more cases where temporary variables could be removed, but I would like to work with and improve what we have right now before trying to optimize it further. Especially within the compiler and make the logic a little more efficient, check for some weird cases, like structs with padding, or initializing a type with fields that are derived types (nested up-casting?) which haven't even tried yet.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

coderJeff wrote: Dec 25, 2022 17:53 .....
Here is a case that didn't work in fbc 1.09.0 and is currently not allowed in fbc 1.10.0:

Code: Select all

type parent
    dim as integer i
end type
type child extends parent
	dim as integer j
end type
type B
	p1(0 to 0) as parent
	p2 as parent	
end type

dim y1 as B = type<B> _
( _                         ''  fbc 1.09   1.10
	{ type<parent>(1) }, _  ''        ok     ok
	type<parent>(3) _       ''        ok     ok
)

print y1.p1(0).i
print y1.p2.i

dim y2 as B = type<B> _
( _                          '' fbc 1.09   1.10
	{ type<child>(1,2) }, _  ''     *bad   up-cast not allowed  
	type<child>(3,4) _       ''     *bad   up-cast not allowed
)

print y2.p1(0).i
print y2.p2.i
.....
This case works in fbc 1.09.0 !
In fbc 1.10.0, the error message is not very relevant !
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.10.0 Development

Post by coderJeff »

fxm wrote: Jan 06, 2023 12:10 This case works in fbc 1.09.0 !
In fbc 1.10.0, the error message is not very relevant !
I will look at the case in fbc 1.10.0 to understand why is not allowed or if can be fixed.

While it may compile in fbc 1.09.0 without error, it did not "work" correctly and wrong code is generated.

Code: Select all

type parent
    dim as integer i
end type
type child extends parent
	dim as integer j
end type
type B
	p1(0 to 0) as parent
	p2 as parent	
end type

dim y2 as B = type<B> _
( _
	{ type<child>(1,2) }, _  
	type<child>(3,4) _
)

'' backend code generated in fbc 1.09.0
var p = cast( integer ptr, @y2 )

'' p[0] = 1
'' p[1] = 2  '' bad
'' p[1] = 3
'' p[2] = 4  '' bad

print p[0] '' 1
print p[1] '' 3
print p[2] '' 4
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.10.0 Development

Post by coderJeff »

coderJeff wrote: Jan 06, 2023 13:31 I will look at the case in fbc 1.10.0 to understand why is not allowed or if can be fixed.
The goal is that initializing tries to match the closest base. When matching the initializer to the UDT, first try is without up-casting, and if that fails, fall-back to a conversion. To make this work, we need to parse the entire initializer expression first and then find the best base.

So by default the initializer expression is parsed without allowing up-casting.
And because we are nested in a UDT parsing the initializers for the array elements doesn't allow up-casting. (I'm sure I had a note about allowing up-casting for array element initializers even when nested in a UDT, but I guess I lost it and forgot about it).

With a small fix to allow up-casting on array elements, the example from last post seems ok, but then we get a new issue (last case of y3):

Code: Select all

type parent
    dim as integer i
end type
type child extends parent
	dim as integer j
end type
type B
	p1(0 to 0) as parent
	p2 as parent	
end type

dim y1 as B = type<B> _
( _                         ''  fbc 1.09   1.10
	{ type<parent>(1) }, _  ''        ok     ok
	type<parent>(3) _       ''        ok     ok
)

'' with fix-applied
dim y2 as B = type<B> _
( _                          '' fbc 1.09   1.10
	{ type<child>(1,2) } _   ''     *bad     ok  
)

'' with fix-applied
dim y3 as B = type<B> _
( _                          '' fbc 1.09   1.10
	{ type<child>(1,2) }, _  ''  
	type<child>(3,4) _       ''     *bad    invalid data type
)
I'm trying to figure this last case out. I don't know if it is a simple detail missed, or will need major revisions.
----
I need to return to regular work next week, so I won't be starting any major revisions this weekend. I will try to understand the problem and update with a small fix, but if it is anything major, it will have to wait.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

Using the last build fron SARG:
SARG wrote: Mar 27, 2023 8:05 So I made again mine (only 32/64bit Windows) https://users.freebasic-portal.de/sarg/ ... astest.zip
Last fix:
gfxlib2: sf.net # 569: gfxlib2: GetMouse/SetMouse scaling problem in QB modes Screen 2 & 8

- Adjust GETMOUSE and SETMOUSE by scanline size (screen modes 2 and 8)
- internally, gfxlib2 uses single scan lines in memory for modes 2 and 8 and then blits to the device doubling the scan lines
- adjust the GetMouse 'y' return value by dividing by number of scanlines
- adjust the SetMouse 'y' parameter by multiplying by number of scanlines

Compared to the test code attached to the bug report "#569 GetMouse/SetMouse scaling problem in QB modes Screen 2 & 8", I do not see any improvement in the observed defect?
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeBASIC 1.10.0 Development

Post by SARG »

@fxm
Only fbc.exe is provided not RTlib/gfxlib2 so it's normal that there is no change.

Currently you can only test #cmdline issue (-RR, -R, etc).
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeBASIC 1.10.0 Development

Post by SARG »

@fxm
I just remembered that a few months ago I compiled gfxlib2 to test my pmap changes.
So I am able to provide a version with Jeff's latest changes.
The archive is a bit bigger because I don't use make but a simple batch file without all the necessary options.

gfxlib2 64-bit Windows only : https://users.freebasic-portal.de/sarg/libgfx_win64.zip
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

'libgfx.a':
I have not such a file in my 'lib\win64' directory ?
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeBASIC 1.10.0 Development

Post by SARG »

Rename it to libfbgfx.a :D
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

THANKS. I'll try.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

fxm wrote: Mar 27, 2023 12:31 Compared to the test code attached to the bug report "#569 GetMouse/SetMouse scaling problem in QB modes Screen 2 & 8", I do not see any improvement in the observed defect?
With your new 'libfbgfx.a', it works now.
Thank you so much.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

Extending PROCPTR() to return a pointer/vtable_offet to a member procedure non_virtual/virtual

@Jeff,

I am waiting a fbc build to test this new advanced feature, but I already have two remarks:

- I think that a comma misses in the below syntax definition for a virtual procedure member (compared to the example):
PROCPTR( UDT.member [VIRTUAL] [,signature] )

- When returning the offset in the vtable for a virtual member procedure, why return a Byte offset and not a pointer offset (because it is a pointer table) ?
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeBASIC 1.10.0 Development

Post by SARG »

fxm wrote: Apr 24, 2023 5:52 I am waiting a fbc build
You wake up earlier than me. :wink:

https://users.freebasic-portal.de/sarg/ ... astest.zip

BTW In the same way I did for gfxlib2, now I'm able to compile the rtlib. :)
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

@SARG,
Thanks.

fxm wrote: Apr 24, 2023 5:52 - I think that a comma misses in the below syntax definition for a virtual procedure member (compared to the example):
PROCPTR( UDT.member [VIRTUAL] [,signature] )

Maybe:
PROCPTR( UDT.member [, signature|VIRTUAL] )

To get the procedure pointer value of a non-virtual or virtual member procedure:
PROCPTR( UDT.member [, signature] )
(0 returned for an abstract member procedure)

To get the vtable offset of a virtual or abstract member procedure:
PROCPTR( UDT.member, VIRTUAL )
(-2147483648 returned if the procedure is neither virtual nor abstract)

Note:
For a non-static member procedure, the provided signature (to solve an eventual overload) is always the user signature at declaration/definition level, but not the real signature of the type which returns from PROCPTR (which has a first additional parameter 'byref as UDT').
To take into account if we use DIM and not VAR to declare the non-static member procedure pointer.
Post Reply