Freebasic 1.20.0 Development

[coderJeff]

I appreciate your testing of fbc 1.20 and patience. Thank-you again.

[coderJeff]

Do you know an '-march' that would be seen as 'generic' across many targets?

What about omitting the -march option?

$ /usr/bin/../bin/gcc -march=armv7-a -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 "1-20.c" -o "1-20.asm"
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ /usr/bin/../bin/gcc -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 "1-20.c" -o "1-20.asm"
$

Regards

Maybe, but only for end user I think. I think for the release I need to choose something otherwise it will just be the default for whatever the gcc on my rPIs are configured for.

If I were to make a comparison to Intel, it would be like making the release for 'i386' but then users can tune it or recompile defaults for whatever their system is and targets will support or have default pentium / i686 or whatever.

Except I have no idea how compatible one instruction set is to any other on ARM.
- armv7-a works for me and TeeEmCee and maybe a few others.
- There's a user (I forget who now, so sorry to that person!) that patches fbc for an armv6 default, because that works better on older hardware.

[TJF]

must now be:

Code: Select all

WITH (*Conf).St_p(Stp)

That's working, thanks!

I think for the release I need to choose something otherwise it will just be the default for whatever the gcc on my rPIs are configured for.

No, I don't think so. No -march option lets gcc work in its default arch (the arch the package is build for, so different archs for rPI or BBB). That should work on all boxes/CPUs for native compiling.

The -march option is only useful for cross-compiling, and you cannot predict the target the user needs.

Regards.

BTW
Which release? I tested the @ST_W builds; those're working on the BBB/am3358. Perhaps we can learn from his build conf.

[coderJeff]

BTW
Which release? I tested the @ST_W builds; those're working on the BBB/am3358. Perhaps we can learn from his build conf.

Which did you test? Looks like there is 2 available:

https://users.freebasic-portal.de/stw/b ... armv6-rpi/
https://users.freebasic-portal.de/stw/b ... hf-debian/

And they are cross-compiled:
viewtopic.php?p=281905#p281905

[TJF]

Which did you test?

The TI am3358 CPU in the BBB is armhf. I tested the debian package

https://users.freebasic-portal.de/stw/b ... ebasic.deb

Regards

[fbfans]

https://users.freebasic-portal.de/stw/builds/
Error: Last modified 2023-11-20
Aborting due to runtime error 3 (file I/O error) at line 66 of src\compiler\lex.bas()

[SARG]

https://users.freebasic-portal.de/stw/builds/
Error: Last modified 2023-11-20
Aborting due to runtime error 3 (file I/O error) at line 66 of src\compiler\lex.bas()

It has been fixed in the last commits (2023/11/26).

[Jattenalle]

As posted on Discord:
FBC crash Version 1.20.0 (2023-11-27), built for win32 (32bit)

Compiling with: '-v'
FreeBASIC Compiler - Version 1.20.0 (2023-11-27), built for win32 (32bit)
Copyright (C) 2004-2023 The FreeBASIC development team.
standalone
target: win32, 686, 32bit
backend: gas
compiling: E:\Gods and Idols\Development\Repository\Experiments\fbList\examples\example-03-udt.bas -o E:\Gods and Idols\Development\Repository\Experiments\fbList\examples\example-03-udt.asm (main module)

Aborting due to runtime error 12 ("segmentation violation" signal)

Version number (If applicable) has not been increased.

The offending code:

Code: Select all

#if isProcedure(__FBLIST_PP_LISTTYPE_GLOBAL.Cast)
    r &= cast(string, n)
#else
    r &= "0x"& n
#endif

FBC does not like that one bit. (Yes, it wouldn't work regardless because the cast might be to a different type, not the point)

Minimal code needed to reproduce:

Code: Select all

type foo
	bar as integer
	declare sub wee()
end type
sub foo.wee()
end sub

#print "Before"
#ifdef foo.Cast
	#print "	Yes!"
#else
	#print "	nope."
#endif
#print "After"

The sub can also be a function. If the sub/function is removed then no crash will occur:

Code: Select all

type foo
	bar as integer
end type

#print "Before"
#ifdef foo.Cast
	#print "	Yes!"
#else
	#print "	nope."
#endif
#print "After"

Only operators in the type, e.g. ``declare operator Let(byval as integer)`` also do not result in an FBC crash.

[coderJeff]

The sub can also be a function. If the sub/function is removed then no crash will occur:

Internally, there are roughly 3 kinds of types. And to be clear, this is internals, so my description may not completely match the vocabulary we present to the user:

1) fields only and can have field names same as keywords

Code: Select all

  type T
    field as long
  end type 

2) types with fields or methods, keywords not allowed as names for fields or methods

Code: Select all

  type T
    n as integer
    declare sub proc()
  end type 

3) more complex types with constructors, destructors, operators, virtual methods, rtti require extra information in the symbol database (i.e. more memory) so it is only allocated if needed.

Code: Select all

  type T
    n as integer
    declare constructor()
  end type 

For type (1) - no crash because keywords are allowed as field names - so 'cast' might be a field name or not. Only the field names are checked.
The extra information pointer is null, but it doesn't matter because we don't use it

For types (2) and (3) the only difference is if the extra information was allocated or not.
For type (2) - crash, because there was no check to determine if the extra information was allocated
For type (3), no crash, because the extra information is allocated, so no problem with the lookup.

[TJF]

Hi Jeff!

Do you know an '-march' that would be seen as 'generic' across many targets?

What about omitting the -march option?

Maybe, but only for end user I think.

Can you please provide a patch to get rid of that option in the gcc call (for a freebasic package in the BBB distro).

Regards

[coderJeff]

Can you please provide a patch to get rid of that option in the gcc call (for a freebasic package in the BBB distro).

I must be missing something here because completely removing the -march option doesn't seem correct.
According to viewtopic.php?p=297332#p297332
Only patch is ARMv6 default is for patched.
So, this still confuses me how there was no issue with St_W's builds.

fbc needs some default arch to be configured and target and only overridden by fbc -arch. Otherwise it seems like would be very easy to have mismatch between what fbc is configured to target by default and what the host gcc might actually support.

[TJF]

Hi Jeff!
Testing your binary on BeagleBone Black (TI am3358 CPU):

Code: Select all

$ uname -a
Linux BeagleBone 5.19.8-bone9 #1bookworm PREEMPT Tue Sep 13 00:43:19 UTC 2022 armv7l GNU/Linux
$ wget http://downloads.sourceforge.net/fbc/FreeBASIC-1.10.0-rpios11-arm.tar.gz?download
$ mv FreeBASIC-1.10.0-rpios11-arm.tar.gz\?download FreeBASIC-1.10.0-rpios11-arm.tar.gz
$ tar -xf FreeBASIC-1.10.0-rpios11-arm.tar.gz 
$ cd FreeBASIC-1.10.0-rpios11-arm/bin
$ ./fbc 
usage: fbc [options] <input files>
input files:
  *.a = static library, *.o = object file, *.bas = source
  *.rc = resource script, *.res = compiled resource (win32)
  *.xpm = icon resource (*nix/*bsd)
options:
  @<file>          Read more command line arguments from a file
  -a <file>        Treat file as .o/.a input file
  -arch <type>     Set target architecture (default: 686)
  -asm att|intel   Set asm format (-gen gcc|llvm, x86 or x86_64 only)
  -b <file>        Treat file as .bas input file
...
$ echo '?"Hello"' > a.bas
$ ./fbc a.bas 
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7 a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7-a+fp a.bas
$ ./a 
Hello
$

Same behavior as in ST_W's builds: executable runs, but doesn't compile out-off-the-box. Compiling needs overriding the default -march for gcc (gcc compiles when -march option is missing) .

I hope that helps. Let me know if you need further testing.

Regards

PS: Does fbc uses FPU internally? (My compilers are interger only.)

[TJF]

I don't know if it's relevant: testing the uname host-arch and all gcc supported armV7

Code: Select all

$ uname -a
Linux BeagleBone 5.19.8-bone9 #1bookworm PREEMPT Tue Sep 13 00:43:19 UTC 2022 armv7l GNU/Linux
$ ./fbc -Wc -march=armV7l a.bas
gcc: error: unrecognized -march target: armv7l
gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a iwmmxt iwmmxt2 native; did you mean ‘armv7’?
gcc: error: missing argument to ‘-march=’
$ ./fbc -Wc -march=armV7-a a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7ve a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7-r a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7-m a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7e-m a.bas
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
$ ./fbc -Wc -march=armV7-a+fp a.bas
$

Regards

[coderJeff]

Same behavior as in ST_W's builds: executable runs, but doesn't compile out-off-the-box. Compiling needs overriding the default -march for gcc (gcc compiles when -march option is missing) .

I hope that helps. Let me know if you need further testing.

It appears that gcc itself is imposing (or simply defaulting to) the `-mfloat-abi=hard` option, because fbc doesn't emit this option.

It should be expected that overriding the default arch will be required on some platforms. There's like a thousand arm target options and I only release one ARM build and one AARCH64 build. (But others are welcome to release their own)

On your box, what is result of?:
`gcc --version`
`gcc -dumpmachine`
`fbc -arch native -v a.bas`
thanks,

I would guess that `-arch native` should use gcc's default, what is given by `gcc -dumpmachine` but I don't know if that is always the case.

Anyway, that might give a little more information what we might do - like maybe check for and allow additional arm extensions on fbc's command line.

[TJF]

It appears that gcc itself is imposing (or simply defaulting to) the `-mfloat-abi=hard` option, because fbc doesn't emit this option.

Yes, that message is emited by gcc, but only when any specific -march=... option is set. When gcc gets no -march option, it compiles fine. That's why I recommend to omit that option for the users (let gcc compile native).

If you need any -march option for building the binary, set it in your makefile. A binary compiled by -march=armV7-a seems to run fine on BBB, but a gcc call with that option does not compile.

On your box, what is result of?:
`gcc --version`
`gcc -dumpmachine`
`fbc -arch native -v a.bas`
thanks,

Code: Select all

$ 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.

$ gcc -dumpmachine
arm-linux-gnueabihf
$ ./fbc -arch native -v a.bas
FreeBASIC Compiler - Version 1.10.0 (2023-05-14), built for linux-arm (32bit)
Copyright (C) 2004-2023 The FreeBASIC development team.
target:       linux-arm, armv7-a, 32bit
backend:      gcc
compiling:    a.bas -o a.c (main module)
compiling C:  gcc -march=native -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/Projekte/fbc_test/FreeBASIC-1.10.0-rpios11-arm/bin/../lib/freebasic/linux-arm/fbextra.x" -L "/home/debian/Projekte/fbc_test/FreeBASIC-1.10.0-rpios11-arm/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/Projekte/fbc_test/FreeBASIC-1.10.0-rpios11-arm/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
$ 

I adapted the third command in order to use your binary (fbc -> ./fbc).

Regards