FreeBASIC 1.09.0 Release

[UEZ]

Why does (2 / ((i + k) And 3) Or 1) work and (2 \ ((i + k) And 3) Or 1) not? In both cases division by zero.

For at least x86 targets and gas back-end:
integer division operator '\' uses IDIV instruction. Division by zero causes a hardware exception.
division operator '/' uses floating point division. Division by zero results in special 'infinity' value.

Other targets / backends might may use different instructions or not have hardware exceptions for division by zero.

Thx coderJeff. Would it make sense also add a check for integer division by zero?

[coderJeff]

Would it make sense also add a check for integer division by zero?

For users of most targets/backends, a runtime error is thrown.

Code: Select all

'' compile with '-e'

var n = 1, d = 0
var q = n \ d     '' integer division
    
'' run time output for windows/linux, x86/x86-64, gas/gas64/gcc 
'' Aborting due to runtime error 11 ("floating point error" signal)

Probably for freebsd too. I didn't check dos/arm/aarch64 targets. llvm backend doesn't throw an error - but it has other bugs too.

[coderJeff]

The next major items are still:
- variable length wstring
- locking issues between rtlib & gfxlib2
- broken ON ERROR handling

However, the current fbc-1.09.0 runtime is binary compatible with fbc-1.08.1 runtime. So, I'm contemplating pushing out a fbc-1.09.0 release to capture the most recent compiler changes before tackling the major runtime library changes.

[speedfixer]

I just downloaded and installed FB - ( simple: sudo install -i)

fbc -version:
FreeBASIC Compiler - Version 1.09.0 (2021-10-30), built for linux-x86_64 (64bit)
Copyright (C) 2004-2021 The FreeBASIC development team.


I needed to sudo chmod /usr/local/lib/freebasic/linux-x86_64/ to allow a compile without sudo.

msg was:

fbc test3.bas
ld: cannot open linker script file /usr/local/bin/../lib/freebasic/linux-x86_64/fbextra.x: No such file or directory


david

[coderJeff]

I needed to sudo chmod /usr/local/lib/freebasic/linux-x86_64/ to allow a compile without sudo.

I see this too - on a fresh install of the daily build.
Couple things I noticed:
- the daily build package is not a full package.
- permissions from the ZIP package not set correctly when using ubuntu's archive manager

Install instructions that worked for me:
- download and install latest official package
- download latest daily build
$ sudo unzip -x <daily-packagename>.zip
$ cd fbc_linux64
$ chmod +x install.sh
$ sudo ./install.sh -i

Using archive manager with the .tar.gz / .tar.xz full release packages appears to preserve permissions.

[speedfixer]

Yes, permissions on the install script, also.

Each of these have happened from time-to-time.
Maybe a note could be placed in the install notes to save some traffic here at the forum from future new installers.
(Of course, I haven't read the install notes in years!)

david

[coderJeff]

Yes, permissions on the install script, also.

Each of these have happened from time-to-time.

In the official full release packages too?

I don't make the daily build packages; St_W is graciously providing those.

[speedfixer]

In the official full release packages too?

Good question/good point.
I am not creating as many new systems as I used these last few years, so can't comment, don't remember.

Guess it dosn't matter if I'm not just installing vanilla. I know what to do, so I suppose I should let the newbs report when this happens.
Thanks for the attention/effort, anyway.

david

[St_W]

Regarding the daily build package permissions: this is unfortunately a known issue - the files are packaged on a Windows machine and thus any unix file permission settings are lost. It's not a full package to save disk space - the not-included files are not really necessary to compile a simple application and don't change a lot, thus the decision to leave them out. You can easily make a full package by either copying the daily build into a previous version full build (overwriting existing files) or - the other way round - copy the missing include/library files from a full build (keeping existing files).

[srvaldez]

hello coderJeff, there's correction that needs to be made in tests/quirk/inline-asm.bas line 19, see this post by SARG https://discord.com/channels/4561680068 ... 0351891466
it fails with the latest binutils

thank you :-)

[coderJeff]

hello coderJeff, there's correction that needs to be made in tests/quirk/inline-asm.bas line 19, see this post by SARG https://discord.com/channels/4561680068 ... 0351891466
it fails with the latest binutils

thank you :-)

For context, from the discord channel, in 64-bit programs (windows):

Code: Select all

sub proc()
end sub

dim as any ptr proc_address 
asm
	mov rax, offset proc
	mov [proc_address], rax
end asm

print @proc
print proc_address

Depending on the version of binutils maybe will see this error:
asm1.o:fake:(.text+0x4d): relocation truncated to fit: R_X86_64_32S against `.text'

The immediate cause is:
- when the ASM is compiled in to an object file, space is reserved for a 32-bit sign extended address.
- when the object file is linked, the linker is relocating the code to an address that can't be represented by a 32-bit sign extended address.
- therefore get an error that the address has been truncated

I'm not certain on why there is a change, but here is what I found:
- binutils 2.34 (what is packed with fbc 1.08.1) defaults the executable image base to 0x40000000
- binutils 2.37 (what I downloaded from winlibs) defaults the executable image base to 0x140000000
- it could be a fix / change in binutils, or could be a build / configure option, I don't know
- According to MS documentation, the default image base address should be 0x140000000 for 64-bit executables.

You can see the error in current fbc + binutils 2.34 (which might be helpful to test ASM at the proper base address):
fbc64 asm.bas -Wl "--image-base 0x140000000"

And can work-around it in current fbc + binutils 2.37 (which might be helpful to use new binutils with old ASM):
fbc64 asm.bas -Wl "--image-base 0x40000000"


So, two possible corrections for ASM code are:
1) use a 64-bit immediate so space is reserved for 64-bit address

Code: Select all

	movabs rax, offset proc

2) use relative addressing (with the expectation that the displacement is within 2GB)

Code: Select all

	lea rax, proc[rip]

[miilvyxg]

The ability to target .NET and Java is awesome if available. It's not impossible for an unmanaged language to be able to do so. Check this:

https://github.com/LADSoft/OrangeC/blob ... c/occil.md

[Xusinboy Bekchanov]

@coderjeff, is it possible to make Left, Right, Point, Rect the main, and the rest are secondary as before? Because we can access them through gdiplus.Rect, gdiplus.Point, This.Left, Keys.Left, Keys.Right. Looks better than ..Left, ..Right, ..Point, ..Rect.

[coderJeff]

@coderjeff, is it possible to make Left, Right, Point, Rect the main, and the rest are secondary as before?

I don't know. Can you make a *small* example that shows what you want to change?

Could it be related to https://sourceforge.net/p/fbc/bugs/948/ ?

[j8w344c6]

@coderjeff, is it possible to make Left, Right, Point, Rect the main, and the rest are secondary as before?

I don't know. Can you make a *small* example that shows what you want to change?

Could it be related to https://sourceforge.net/p/fbc/bugs/948/ ?

Might be related to this?

viewtopic.php?f=17&t=29792