Freebasic 1.20.0 Development

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

Re: Freebasic 1.20.0 Development

Post by coderJeff »

TJF wrote: Dec 09, 2023 16:04 Just to remember:
I got myself a beaglebone black. Debian 12 is still quite new, so I am working on setting it up.
The rpios builds are also arm-linux-gnueabihf and so as discussed (or I read) it is changes in gcc's arguments
I think it would be good to pass a correct desired argument than to leave it out and assume it all works.
-target native is the workaround

But I will go ahead with a 1.10.1 release soon anyway even if this build isn't ready - it's turning out to be just a bit more time consuming than I had wanted.
UEZ
Posts: 1079
Joined: May 05, 2017 19:59
Location: Germany

Re: Freebasic 1.20.0 Development

Post by UEZ »

coderJeff wrote: Dec 22, 2023 18:33
UEZ wrote: Dec 12, 2023 12:21 When I'm using the DrawLineAAWu function instead then it works without crashing.
Many other things replaced too: floats instead of integers, no line clipping (pset does pixel clipping instead, different expressions (smaller values), singles instead of doubles, a smaller image scaled up, etc. (and the alpha blending function seems incorrect).

One of these is a problem statement regardless:

Code: Select all

        z = Cos(t) + 1 + IIf(t < 6, 1, 0)
        x = iw2 + Sin(t) * iw2 / z
        y = ih2 + (((i Mod 4) \ 2 Shl 9) - 280) / z
If 'z' is very small then |x| and |y| can become very large, or a divide by zero. Depending on 'const _t = 1/60' can affect if there is a crash or not.
UEZ wrote: Dec 12, 2023 20:29 Regarding the internal line function I assume that a pixel is set outside the image boundaries without the needed check which causes the crash (Exception code: 0xc0000005).
half correct. The line clipping algorithm that clips the line to the current target (screen or image) uses all integer math. However, part of the line clipping math is something like (x2-x1)*(y2-y1) and if difference of values are too large, then and overflow introduces bad values in line drawing algorithm, causing pixels to be specified outside the target area. The intent of line clipping is so that only the pixels that are in the target area are calculating instead of checking every pixel.
No clue for the different output (x86 <-> x64). :?:
Appears to be a bug; 32-bit x86 by default will use the assembly encoded procedures using MMX registers and there is a difference between MMX and C implementation.

This is the C implementation:
Image
You mean the alpha blending function from the DrawLineAAWu is incorrect? If yes, what is incorrect?

Btw, what is rst, qst, wst and yst?

Thanks for your research!
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

UEZ wrote: Dec 23, 2023 19:49 You mean the alpha blending function from the DrawLineAAWu is incorrect? If yes, what is incorrect?
Yes, but I look again and I think is ok. This seemed weird, but I forget you have ALPHA_PRIMITIVES enabled
Pset pImage, (x, Floor(intery)), (a * f) Shl 24 Or _rgb
I thought was something wrong but I think is because of the artifacts of the multiple PUT image2,(),image2
Btw, what is rst, qst, wst and yst?
src := source
dst := destination
rst := result of PUT dst <- src ALPHA
qst := rst, loop( PUT qst <- qst ALPHA )
wst := window
yst := result of PUT wst <- qst PSET

I made a fix for the ALPHA problem in fbc-1.20.0.
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

coderJeff wrote: Dec 23, 2023 20:43 I made a fix for the ALPHA problem in fbc-1.20.0.
Here is the test program I used to generate the images testing ALPHA. A latest build of fbc 1.20 is required.

Code: Select all

#include once "fbgfx.bi"

const MAXSIZE = 64
dim shared gradient( 0 to MAXSIZE-1 ) as ulong = _
{ _
	000, 001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 012, 013, 014, 015, _ 
	020, 025, 030, 030, 035, 040, 050, 060, 070, 080, 090, 110, 120, 123, 126, 127, _ 
	128, 129, 132, 140, 150, 160, 170, 180, 190, 200, 210, 215, 220, 225, 230, 235, _ 
	240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255 _
} 

sub plot _ 
	( _
		byval xc as single, _
		byval yc as integer, _
		byval img as fb.image ptr, _
		byref title as const string _
	)

	const HGUTTER = 32
	const VGUTTER = 64
	const LEFTMARGIN = 32
	const TOPMARGIN = 32

	dim xx as integer = LEFTMARGIN + xc*(MAXSIZE+HGUTTER) 
	dim yy as integer = TOPMARGIN + yc*(MAXSIZE+VGUTTER) 

	put (xx,yy), img, pset

	dim yt as integer = yy - 16
	draw string (xx, yt), title

	dim x1 as integer = xx - 2
	dim x2 as integer = xx + MAXSIZE + 1
	dim y1 as integer = yy - 2
	dim y2 as integer = yy + MAXSIZE + 1

	line (x1,y1)-(x2,y2),rgba(255,255,255,255),b
end sub

function getAlphaPrimitives( ) as ulong
	dim value as ulong
	ScreenControl fb.GET_ALPHA_PRIMITIVES, value
	return value
end function

sub setAlphaPrimitives( byval value as ulong )
	ScreenControl fb.SET_ALPHA_PRIMITIVES, value
end sub
		
sub InitRGBA _
	( _
		byval dst as fb.image ptr, _
		byval r as ulong, _
		byval g as ulong, _
		byval b as ulong, _
		byval a as ulong _
	)

	var ap = getAlphaPrimitives()
	setAlphaPrimitives( 0 )

	for y as integer = 0 to MAXSIZE-1
		for x as integer = 0 to MAXSIZE-1
			pset dst, ( x, y ), rgba( r, g, b, a )
		next
	next

	setAlphaPrimitives( ap )

end sub

sub InitChnl _
	( _
		byval dst as fb.image ptr, _
		byval src as fb.image ptr, _
		byval channel as integer _
	)

	var ap = getAlphaPrimitives()
	setAlphaPrimitives( 0 )

	dim psrc as ulong ptr = cast( ulong ptr, fb.__pixels( src ) )
	dim pdst as ulong ptr = cast( ulong ptr, fb.__pixels( dst ) ) 
	for y as integer = 0 to MAXSIZE-1
		for x as integer = 0 to MAXSIZE-1
			dim c as ulong = psrc[y*src->pitch\4 + x]
			c = (c shr (8 * channel)) and &hff
			c = rgba( c, c, c, 255 ) 
			pset dst, ( x, y ), c
			'' pdst[y*dst->pitch\4 + x] = c 
		next
	next

	setAlphaPrimitives( ap )

end sub

sub InitGrad _ 
	( _
		byval dst as fb.image ptr, _
		byval r0 as ulong, byval g0 as ulong, byval b0 as ulong, byval a0 as ulong, _
		byval rdx as single, byval gdx as single, byval bdx as single, byval adx as single, _
		byval rdy as single, byval gdy as single, byval bdy as single, byval ady as single _
	)

	dim as ulong r, g, b, a

	var ap = getAlphaPrimitives()
	setAlphaPrimitives( 0 )

	for y as integer = 0 to MAXSIZE-1
		for x as integer = 0 to MAXSIZE-1
			r = r0 + gradient(x) * rdx + gradient(y) * rdy
			g = g0 + gradient(x) * gdx + gradient(y) * gdy
			b = b0 + gradient(x) * bdx + gradient(y) * bdy
			a = a0 + gradient(x) * adx + gradient(y) * ady
			pset dst, ( x, y ), rgba( r, g, b, a )
		next
	next

	setAlphaPrimitives( ap )

end sub
 

const flags = fb.GFX_ALPHA_PRIMITIVES
screenres 512, 768, 32, 1, flags
ScreenControl fb.SET_X86_MMX_ENABLED, 0

dim src as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE ) 
dim sc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim sc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim sc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim sc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

dim dst as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim dc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim dc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim dc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim dc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

dim rst as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim rc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim rc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim rc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim rc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

dim qst as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim qc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim qc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim qc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim qc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

dim wst as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim wc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim wc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim wc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim wc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

dim yst as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim yc0 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim yc1 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim yc2 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )
dim yc3 as fb.image ptr = imagecreate( MAXSIZE, MAXSIZE )

do
	cls

	InitRGBA( src, 0, 0, 0, 0 )
	InitRGBA( dst, 0, 0, 0, 0 )
	InitRGBA( rst, 0, 0, 0, 0 )
	InitRGBA( wst, 255, 255, 255, 1 )
	InitRGBA( yst, 255, 255, 255, 1 )
	
	InitGrad( src, 0, 0, 0, 0, 1.0, 1.0, 0.0, 0.5, 0.0, 0.0, 1.0, 0.5 )
	InitGrad( dst, 0, 0, 0, 0, 1.0, 0.0, 1.0, 1.0, 0.0, 1.0, 0.0, 0.0 )
	
	put rst, (0, 0), dst, pset
	put rst, (0, 0), src, pset

	put qst, (0, 0), dst, pset
	put qst, (0, 0), src, pset

	for i as integer = 15 to 0 step -1
		put qst, (0, i), qst, alpha, 255
	next

	put yst, (0, 0), wst, pset
	put yst, (0, 0), qst, alpha, 255
	
	InitChnl( sc0, src, 0 ) 
	InitChnl( sc1, src, 1 ) 
	InitChnl( sc2, src, 2 ) 
	InitChnl( sc3, src, 3 ) 
	
	InitChnl( dc0, dst, 0 ) 
	InitChnl( dc1, dst, 1 ) 
	InitChnl( dc2, dst, 2 ) 
	InitChnl( dc3, dst, 3 ) 
	
	InitChnl( rc0, rst, 0 ) 
	InitChnl( rc1, rst, 1 ) 
	InitChnl( rc2, rst, 2 ) 
	InitChnl( rc3, rst, 3 ) 

	InitChnl( qc0, qst, 0 ) 
	InitChnl( qc1, qst, 1 ) 
	InitChnl( qc2, qst, 2 ) 
	InitChnl( qc3, qst, 3 ) 

	InitChnl( wc0, wst, 0 ) 
	InitChnl( wc1, wst, 1 ) 
	InitChnl( wc2, wst, 2 ) 
	InitChnl( wc3, wst, 3 ) 

	InitChnl( yc0, yst, 0 ) 
	InitChnl( yc1, yst, 1 ) 
	InitChnl( yc2, yst, 2 ) 
	InitChnl( yc3, yst, 3 ) 

	plot 0, 0, src, "src"
	plot 1, 0, sc0, "srcB"
	plot 2, 0, sc1, "srcG"
	plot 3, 0, sc2, "srcR"
	plot 4, 0, sc3, "srcA"
	
	plot 0, 1, dst, "dst"
	plot 1, 1, dc0, "dstB"
	plot 2, 1, dc1, "dstG"
	plot 3, 1, dc2, "dstR"
	plot 4, 1, dc3, "dstA"
	
	plot 0, 2, rst, "rst"
	plot 1, 2, rc0, "rstB"
	plot 2, 2, rc1, "rstG"
	plot 3, 2, rc2, "rstR"
	plot 4, 2, rc3, "rstA"

	plot 0, 3, qst, "qst"
	plot 1, 3, qc0, "qstB"
	plot 2, 3, qc1, "qstG"
	plot 3, 3, qc2, "qstR"
	plot 4, 3, qc3, "qstA"

	plot 0, 4, wst, "wst"
	plot 1, 4, wc0, "wstB"
	plot 2, 4, wc1, "wstG"
	plot 3, 4, wc2, "wstR"
	plot 4, 4, wc3, "wstA"

	plot 0, 5, yst, "yst"
	plot 1, 5, yc0, "ystB"
	plot 2, 5, yc1, "ystG"
	plot 3, 5, yc2, "ystR"
	plot 4, 5, yc3, "ystA"

	dim value as long
	ScreenControl fb.GET_X86_MMX_ENABLED, value
	if( value ) then print "X86_MMX_ENABLED ";
	ScreenControl fb.GET_ALPHA_PRIMITIVES, value
	if( value ) then print "ALPHA_PRIMITIVES ";

	dim as string k
	do	
		k = inkey
		sleep 50, 1
	loop until k > ""

	select case k
	case chr(27)
		exit do
	case "x", "X"
		dim value as long
		ScreenControl fb.GET_X86_MMX_ENABLED, value
		ScreenControl fb.SET_X86_MMX_ENABLED, iif(value,0,1)
	case "a", "A"
		dim value as long
		ScreenControl fb.GET_ALPHA_PRIMITIVES, value
		ScreenControl fb.SET_ALPHA_PRIMITIVES, iif(value,0,1)
	end select

loop
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

coderJeff wrote: Dec 23, 2023 17:07 -target native is the workaround
From my point of view, native should be default. In my CLI software I do not force the users to set an option to get default behavior.

Marry Christmas!
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

TJF wrote: Dec 25, 2023 6:59
coderJeff wrote: Dec 23, 2023 17:07 -target native is the workaround
From my point of view, native should be default. In my CLI software I do not force the users to set an option to get default behavior.

Marry Christmas!
Happy Holidays!

While I agree some default for fbc that works without specifying extra command line options is a worthwhile goal, 'native' can only be a workaround for getting something working on that very specific board. Making a binary that is expected to work on a number of boards will need to have some target arch/cpu/fcpu/float-abi/etc in mind, which means that even if fbc has a default, it should be passing specific arguments to gcc. I found this article helpful https://s-o-c.org/arm-gcc-compiler-flag ... explained/
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

coderJeff wrote: Dec 25, 2023 22:52 I found this article helpful https://s-o-c.org/arm-gcc-compiler-flag ... explained/
This article is helpful for users that want to compile optimized binaries. In most cases, fbc users don't care about maximum speed. They first want working binaries. I don't want to force a programmer to care about CPU optimization before he can prove his concept. And most of my users do not care about the armV7 binary at all; they focus on the real-time firmware running on the PRUs.

fbc currently doesn't compile because it's setting an -march option for a specific CPU. That option doen't match TI am3358 CPU (and OSD3358-SM and perhaps a bunch of further armV7 CPUs). Do you want to patch fbc source for each of this armV7 targets and provide matching binaries?

Take a deep breath, step back and try to stay on top of things: the simple way for you and the users is just omiting that specific -march option and let gcc work in it's native mode. If the user needs optimized code, he'll care about -mcpu, -mfpu and -march options for his specific target.

Regards
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

TJF wrote: Dec 26, 2023 4:20 Take a deep breath, step back and try to stay on top of things: the simple way for you and the users is just omiting that specific -march option and let gcc work in it's native mode. If the user needs optimized code, he'll care about -mcpu, -mfpu and -march options for his specific target.
ok.

Users making binary distributions of fb? Or users using binary distributions made by another?

Are you bootstrapping fbc from sources and building your own fbc executable, rtlib*, and gfxlib* libraries?
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

coderJeff wrote: Dec 26, 2023 12:26 Are you bootstrapping fbc from sources and building your own fbc executable, rtlib*, and gfxlib* libraries?
Yes, I did so, since Joshi and me did the first tests on arm. Later dkl implemented our results in the mainstream source. It worked fine, until the -march option gets set in the gcc call. Now it only works when I explicitely set native target. For me that's no problem. I just set this option in my CMake scripts and I am fine for all my projects. But how should I explain in the user-docs that they need to care about a special version of CMake scripts that sets an option for the default (native target)? And what should users think about a compiler that requires an option to get the default?

If you realy feel like setting an option in your binary builds, then use -march=armV7-a+fp. You wont measure any speed difference in the fbc binary, but it works on all armV7.

And for the users, do not set any option in the gcc call. Let gcc work in its native mode. Please go back to the working solution we had in the beginning.

Regards
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

TJF wrote: Dec 26, 2023 15:19 Later dkl implemented our results in the mainstream source. It worked fine, until the -march option gets set in the gcc call. Now it only works when I explicitely set native target.
-march=armv7-a has been passed to gcc since year 2014. Have you had to explicitly set native target all this time? That seems unlikely, but you let me know.

It looks to me (and I was hoping you would confirm the same for BBB) that:
gcc 12 configured with --with-march=armv7-a+fp
gcc 11 and earlier configured --with-march=armv7-a, and hard float was implied
If you realy feel like setting an option in your binary builds, then use -march=armV7-a+fp
lol, how I 'feel' about it is irrelevant. It's a binary. It has to be something. And pre-built libraries can't be 'native'. Otherwise, yes, this is what needs to happen. I'm checking to see if this works same on other older gcc's on RpIOS. So far, gives correct results on gcc 10 RpIOS-11.
TJF wrote: Dec 26, 2023 15:19 And for the users, do not set any option in the gcc call. Let gcc work in its native mode. Please go back to the working solution we had in the beginning.
I plan to add a makefile build option so anyone building fbc from sources can configure the default arch. gcc can only reliably work in native mode if the rtlib and gfxlib libs were also built from sources in native (so arch will match).
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

coderJeff wrote: Dec 26, 2023 16:30 -march=armv7-a has been passed to gcc since year 2014. Have you had to explicitly set native target all this time? That seems unlikely, but you let me know.
I don't focus on testing each new feature and version. My target is to provide working solutions for my users. So I use tools that users can easily install. I managed to get a freebasic package in the mainstream BBB repos: https://github.com/rcn-ee/repos-jessie- ... -freebasic

This package worked fine for years. Here're some (your) test results on an old (2019) kernel
$ uname -a
Linux beaglebone 4.14.146-bone29 #1 PREEMPT Mon Dec 2 13:34:51 UTC 2019 armv7l GNU/Linux
$ dpkg -l freebasic
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========================-=================-=================-=====================================================
ii freebasic 1.05.0-git2016013 armhf Compiler for FreeBASIC
$ gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -dumpmachine
arm-linux-gnueabihf
$ fbc -v a.bas
FreeBASIC Compiler - Version 1.05.0 (09-21-2018), built for linux-arm (32bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
target: linux-arm, armv7-a, 32bit
compiling: a.bas -o a.c (main module)
compiling C: /usr/bin/../bin/gcc -march=armv7-a -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables "a.c" -o "a.asm"
assembling: /usr/bin/../bin/as --strip-local-absolute "a.asm" -o "a.o"
linking: /usr/bin/../bin/ld -m armelf_linux_eabi -o "a" -dynamic-linker /lib/ld-linux-armhf.so.3 "/usr/bin/../lib/freebasic/linux-arm/fbextra.x" -s -L "/usr/bin/../lib/freebasic/linux-arm" -L "." -L "/usr/lib/gcc/arm-linux-gnueabihf/6" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crt1.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crti.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/crtbegin.o" "/usr/bin/../lib/freebasic/linux-arm/fbrt0.o" "a.o" "-(" -lfb -ltinfo -lm -ldl -lpthread -lgcc -lgcc_eh -lc "-)" "/usr/lib/gcc/arm-linux-gnueabihf/6/crtend.o" "/usr/lib/gcc/arm-linux-gnueabihf/6/../../../arm-linux-gnueabihf/crtn.o"
$
So gcc 6.3 compiles with -march=armv7-a option on TI am3358 CPU.

Now we try to get a more recent version of the freebasic package for the later kernels, see https://git.beagleboard.org/beagleboard/ci-freebasic

This fails, since fbc doesn't compile on current kernels (perhaps due to a change in gcc defaults, I don't know).
coderJeff wrote: Dec 26, 2023 16:30 I plan to add a makefile build option so anyone building fbc from sources can configure the default arch. gcc can only reliably work in native mode if the rtlib and gfxlib libs were also built from sources in native (so arch will match).
This may be a solution, when the option can be used in the (package building) debuild -b -us -uc command. But I fear there can be still a bootstrap issue.

Regards
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

TJF wrote: Dec 27, 2023 7:35
Hopefully this can work for you:
- FreeBASIC-1.10.2 (ARM only) release

If you can test and it works, I can add to the news release, thanks

----
I looked at allowing fbc to default to 'native' but fbc is not well suited to work this way to have 'native' specifically as a default.

Background information:
fbc binary has baked in:
- a default host for itself
- a default cpu type
- a default cpu type for all the hosts fbc can cross compile to

These defaults decide just about everything that fbc will do.

Not impossible to default 'native', but I think quite a few internals have to be reworked and tested to allow this without breaking old builds or making unduly complicated. And even if native option could be set by default, it's not useable by fbc releases since there's no guarantee that pre-built libraries would be suitable for system being run on unless also having built fbc from sources. I am not going to puruse native as a default further.

----
To provide something useable to help move forward I have added options to fbc's makefile and fbc sources that will allow building it with a user specified default cpu type without having to patch the fbc sources.

Build a bootstrap source with armv7-a+fp as default:
$ make bootstrap-dist DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP

Build just ARM bootstrap sources in their own package
$ make bootstrap-dist-arm DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP

Build fbc
# make DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP

Other possible options for ARM:
DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV
DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV6_FP
DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A
DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP

I sometimes have issue building for X86 on DOS so select a default that matches the prebuilt libraries, so added this too:
DEFAULT_CPUTYPE_X86=FB_CPUTYPE_386
DEFAULT_CPUTYPE_X86=FB_CPUTYPE_486
DEFAULT_CPUTYPE_X86=FB_CPUTYPE_586
DEFAULT_CPUTYPE_X86=FB_CPUTYPE_686
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

First of all, thanks for caring about the issue patiently!
coderJeff wrote: Dec 29, 2023 0:18
TJF wrote: Dec 27, 2023 7:35
Hopefully this can work for you:
- FreeBASIC-1.10.2 (ARM only) release

If you can test and it works, I can add to the news release, thanks
As far as I understand, I should now manually download, install and test the binary package

https://downloads.sourceforge.net/fbc/F ... z?download

and report my results. Once testing is OK, you'll prepare the final

https://downloads.sourceforge.net/fbc/F ... arm.tar.xz

package, so that (updated) command

Code: Select all

freebasic/contrib/release/build.sh linux-arm 1.10.2
will work for the new build option. Then, in the BBB CI build directory, we need to patch the file freebasic/debian/rules by appending

Code: Select all

override_dh_auto_build:
	make DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP
so that all binaries get build for the matching target in the DEB package.

Please note when I got something wrong.

Regards
coderJeff
Site Admin
Posts: 4386
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Freebasic 1.20.0 Development

Post by coderJeff »

That sounds about right - with maybe one step that needs to get worked out differently in the future (see below), but I think your steps should work for you now with the assets uploaded to sourceforge.

I appreciate you working on getting freebasic to a distro with a properly maintained package. I didn't realize anyone else was using contrib/release/build.sh, so I'm rather cavalier about changing it. In future I will keep in mind others (like you) could be using it too.

For the packages:
By default, when making a release: 'FreeBASIC-1.10.2-linux-arm.tar.xz' is produced by the build scripts.
But because it is built on a specifc OS I repackage it as: 'FreeBASIC-1.10.2-debian12-armhf.tar.xz' with only name and directory changed.
The idea is that `FreeBASIC-1.10.2-linux-arm` hopefully works on many systems but if not, there can be a more specific package (having a different name).
TJF wrote: Dec 29, 2023 12:17 As far as I understand, I should now manually download, install and test the binary package
re: FreeBASIC-1.10.2-debian12-armhf.tar.xz
Yes, just want to make sure we have a decent starting point and confirmation is nice because this will need to be used to bootstrap newer versions (like fbc-1.20). However, I have recursively built and re-built this package from sources/bootstrap and run the test-suite, so it should be good.
TJF wrote: Dec 29, 2023 12:17 Once testing is OK, you'll prepare the final ... package
re: FreeBASIC-1.10.2-linux-arm.tar.xz
ok, I uploaded to sourceforge.net, though need to think about this package a little bit.
For relase/build.sh to work as-is on debian 12 (due gcc 12), *linux-arm* package contents needs to be same as what was built for *debian12-armhf* package.
And I predict that *linux-arm* package will no longer work on older linux using gcc 7 or earlier.
I probably won't test on raspberrypi OS' until fbc-1.20 release time but I think only raspbian9 will fail with this package; but I can make special steps for that release, because I think I am the only one still making relases for that OS.
TJF wrote: Dec 29, 2023 12:17 freebasic/contrib/release/build.sh linux-arm 1.10.2
...
... Then, in the BBB CI build directory, we need to patch the file ...
I think so. Maybe need to tweak this in a later fbc releases, not sure. Trying to walk a path that doesn't break (too many) old things but lets us do new things.

Overall, I think all the pieces are there. I find the challenge is having well named ports / packages that are reliable for build automation. I tried to make a new "linux-armhf" kind of target just to deal with these new builds but it caused havoc with *every* existing script, makefile, and fbc. Maybe can work towards something like that in future though.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Freebasic 1.20.0 Development

Post by TJF »

coderJeff wrote: Dec 29, 2023 13:36 That sounds about right - with maybe one step that needs to get worked out differently in the future (see below), but I think your steps should work for you now with the assets uploaded to sourceforge.
Found some time to test, here's what I did:

burned a fresh SD card with image am335x-debian-12.2-minimal-armhf-2023-10-07-2gb.img.xz and booted from that card and logged in

$ uname -a
Linux BeagleBone 5.10.168-ti-r72 #1bookworm SMP PREEMPT Sat Sep 30 03:40:45 UTC 2023 armv7l GNU/Linux
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 214M 0 214M 0% /dev
tmpfs 49M 1.3M 48M 3% /run
/dev/mmcblk0p1 1.7G 1.1G 513M 69% /
tmpfs 242M 0 242M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 49M 0 49M 0% /run/user/1000
$ sudo reboot
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 214M 0 214M 0% /dev
tmpfs 49M 1.3M 48M 3% /run
/dev/mmcblk0p1 29G 1.1G 27G 4% /
tmpfs 242M 0 242M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 49M 0 49M 0% /run/user/1000
$ gcc --version
gcc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mkdir bootstrap
$ cd bootstrap/
$ wget https://downloads.sourceforge.net/fbc/F ... mhf.tar.xz
--2023-12-31 07:01:54-- https://downloads.sourceforge.net/fbc/F ... mhf.tar.xz
Resolving downloads.sourceforge.net (downloads.sourceforge.net)... 204.68.111.105
Connecting to downloads.sourceforge.net (downloads.sourceforge.net)|204.68.111.105|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://downloads.sourceforge.net/proje ... mhf.tar.xz [following]
--2023-12-31 07:01:55-- https://downloads.sourceforge.net/proje ... mhf.tar.xz
Reusing existing connection to downloads.sourceforge.net:443.
HTTP request sent, awaiting response... 302 Found
Location: https://master.dl.sourceforge.net/proje ... xz?viasf=1 [following]
--2023-12-31 07:01:57-- https://master.dl.sourceforge.net/proje ... xz?viasf=1
Resolving master.dl.sourceforge.net (master.dl.sourceforge.net)... 216.105.38.12
Connecting to master.dl.sourceforge.net (master.dl.sourceforge.net)|216.105.38.12|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4695916 (4.5M) [application/octet-stream]
Saving to: 'FreeBASIC-1.10.2-debian12-armhf.tar.xz'

FreeBASIC-1.10.2-debian12-armhf.tar.xz 100%[==================================================================================================================================================================>] 4.48M 1.25MB/s in 4.0s

2023-12-31 07:02:02 (1.11 MB/s) - 'FreeBASIC-1.10.2-debian12-armhf.tar.xz' saved [4695916/4695916]

$ tar xf FreeBASIC-1.10.2-debian12-armhf.tar.xz --strip-components=1
$ sudo ./install.sh -i /usr # no default PREFIX since $FBC environment variable doesn't work
$ echo '?"Hello"' > a.bas
$ fbc -v a.bas
FreeBASIC Compiler - Version 1.10.2 (2023-12-28), built for linux-arm (32bit)
Copyright (C) 2004-2023 The FreeBASIC development team.
target: linux-arm, armv7-a+fp, 32bit
backend: gcc
compiling: a.bas -o a.c (main module)
compiling C: gcc -march=armv7-a+fp -S -nostdlib -nostdinc -Wall -Wno-unused -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -Wno-format "a.c" -o "a.asm"
assembling: as --strip-local-absolute "a.asm" -o "a.o"
linking: ld -m armelf_linux_eabi -o "a" -dynamic-linker /lib/ld-linux-armhf.so.3 -T "/usr/local/bin/../lib/freebasic/linux-arm/fbextra.x" -L "/usr/local/bin/../lib/freebasic/linux-arm" -L "." -L "/usr/lib/gcc/arm-linux-gnueabihf/12" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crt1.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crti.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/crtbegin.o" "/usr/local/bin/../lib/freebasic/linux-arm/fbrt0.o" "a.o" "-(" -lfb -ltinfo -lm -ldl -lpthread -lgcc -lgcc_eh -lc "-)" "/usr/lib/gcc/arm-linux-gnueabihf/12/crtend.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crtn.o"
$
so the bootstrap compiler installs and works fine on the fresh image. (Perhaps we don't need the script freebasic/contrib/release/build.sh at all, what do you recommend?)

Then I build the freebasic debian package

Code: Select all

$ cd ~
$ sudo apt install devscripts
...
$ sudo apt install libffi-dev libgl1-mesa-dev libx11-dev libxext-dev libxrender-dev libxrandr-dev libxpm-dev libgpm-dev
...
$ git clone -b fbc-1.10 https://github.com/freebasic/fbc.git ./src/ --depth=1
$ rsync -av ~/freebasic/debian/* ~/src/debian/
$ cd ~/src
$ debuild -b -us -uc
...
Now running lintian freebasic_1.10.0-0_armhf.changes ...
E: freebasic: debian-revision-is-zero 1.10.0-0
E: freebasic changes: debian-revision-is-zero 1.10.0-0
E: freebasic buildinfo: debian-revision-is-zero 1.10.0-0
W: freebasic: groff-message 10: warning: macro 'F' not defined [usr/share/man/man1/fbc.1.gz:1]
W: freebasic: hardening-no-pie [usr/bin/fbc]
W: freebasic: national-encoding [usr/include/freebasic/X11/extensions/Xge.bi]
W: freebasic: national-encoding [usr/include/freebasic/dos/sys/farptr.bi]
W: freebasic: national-encoding [usr/include/freebasic/gsl/gsl_complex_math.bi]
Finished running lintian.
$
The package builds fine after patching (appending) the file src/debian/rules by

Code: Select all

override_dh_auto_build:
	make DEFAULT_CPUTYPE_ARM=FB_CPUTYPE_ARMV7A_FP
So testing the binary results in

Code: Select all

$ cd ~/src/debian/freebasic/usr/bin/
$ echo '?"Hello"' > a.bas
$ ./fbc -v a.bas 
FreeBASIC Compiler - Version 1.10.2 (2023-11-28), built for linux-arm (32bit)
Copyright (C) 2004-2023 The FreeBASIC development team.
target:       linux-arm, armv7-a+fp, 32bit
backend:      gcc
compiling:    a.bas -o a.c (main module)
compiling C:  gcc -march=armv7-a+fp -S -nostdlib -nostdinc -Wall -Wno-unused -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -Wno-format "a.c" -o "a.asm"
assembling:   as --strip-local-absolute "a.asm" -o "a.o"
linking:      ld -m armelf_linux_eabi -o "a" -dynamic-linker /lib/ld-linux-armhf.so.3 -T "/home/debian/src/debian/freebasic/usr/bin/../lib/freebasic/linux-arm/fbextra.x" -L "/home/debian/src/debian/freebasic/usr/bin/../lib/freebasic/linux-arm" -L "." -L "/usr/lib/gcc/arm-linux-gnueabihf/12" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crt1.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crti.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/crtbegin.o" "/home/debian/src/debian/freebasic/usr/bin/../lib/freebasic/linux-arm/fbrt0.o" "a.o" "-(" -lfb -ltinfo -lm -ldl -lpthread -lgcc -lgcc_eh -lc "-)" "/usr/lib/gcc/arm-linux-gnueabihf/12/crtend.o" "/usr/lib/gcc/arm-linux-gnueabihf/12/../../../arm-linux-gnueabihf/crtn.o" 
$ ./a
Hello
$ 
So from my point of view, building the DEB package seems to work now (with manually installing the bootstrap binary).

Regards

BTW: It seems that we can (at least on LINUX) auto-detect the -march value by evaluating the output from lscpu | grep Flags for value fpa (floating point acceleration)
  • When present => -march=armv7-a
  • When not present => -march=armv7-a+fp
Post Reply