spitbol / x64

SPITBOL x64 provides raw power and speed for non-numeric computation on the x86_64 architecture
GNU General Public License v3.0
256 stars 23 forks source link

"ln" function fails #21

Open prof55 opened 1 year ago

prof55 commented 1 year ago

Dear Sir, I admire your work. I want to contribute bug-hunting with the following issue. Look please at this small test:


1 x = 3 2 y = ln(x) 3 output = y "= ln(" x ")" 4 end err.sbl(2) : error 307 -- ln produced real overflow


Obviously, the error reported does not fit. I have an older version of spitbol (3.81) which runs normally. Could you please investigate this issue? Thank you in advance. prof55

CheyenneWills commented 1 year ago

Thanks for the report. I'll take a look at it.

CheyenneWills commented 1 year ago

I see the problem, will have to dig a bit to figure out the proper fix.

Basically the math_op macro that wraps the floating point functions isn't checking for overflow correctly.

CheyenneWills commented 1 year ago

I believe I have a fix for this, but I need to run some tests to verify the floating point functions as well as the floating point arithmetic functions, specifically at some of limits (e.g. overflows, underflows, etc.)

CheyenneWills commented 1 year ago

I have a fix for the specific problem, but in setting up a test suite to verify, I've ran into another problem that will need to be fixed as well.

CheyenneWills commented 1 year ago

I believe that I have figured out the problem, and I'm in the process of creating a test suite for the math operations and functions.

CheyenneWills commented 1 year ago

Just a quick status update..

Fixing this specific problem has exposed several other issues that I am working through. I'm still stepping through individual tests for the different math related functions / operators.

CheyenneWills commented 1 year ago

I've pushed a development branch that should address this problem.

I'll be asking some folks to see if they can test this and provide any feedback before promoting it to the main branch

prof55 commented 1 year ago

 

I am very sorry to report this one:

 

@.***:/opt/x64/bin$ ./sbl40b Illegal instruction (core dumped)

 

this was the binary version downloaded from the development branch. The name should not bother you. To be on sure side, there is an old-fashioned cksum report:

  @.***:/opt/x64/bin$ cksum sbl40b 4013480051 1477840 sbl40b

 

Thank you for your resilience!

 

KR

dr. Imre Bartfai

Sent: Thursday, June 15, 2023 at 3:56 AM From: "Cheyenne Wills" @.> To: "spitbol/x64" @.> Cc: "prof55" @.>, "Author" @.> Subject: Re: [spitbol/x64] "ln" function fails (Issue #21)

 

I've pushed a development branch that should address this problem.

I'll be asking some folks to see if they can test this and provide any feedback before promoting it to the main branch

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

CheyenneWills commented 1 year ago

Thanks for the report.

Can you provide information about your system: what type of processor, which os distribution and what level it is, and could you do a 'ldd sbl40b' ?

Also if you have the ability can you try rebuilding spitbol on your machine?

You will need nasm and gcc.

make bootsbl make BASEBOL=./bootsbl spitbol

This should create a new sbl file in the top directory of the source tree.

(and yes .. the makefile needs to be cleaned up more)

Thanks

prof55 commented 1 year ago

 

Hi,

 

below are the answers inserted, I tried to do my best. The current test report is attached. Please look at the version number. Btw I do not understand why the version number is 4.0a. I cloned the development branch as it seemed the most actual for me. Sorry I am not such aficionado to apply the patches (?) regarding v 4.0b.

 

Cheers,

 

dr. Imre Bartfai

 

Sent: Saturday, June 17, 2023 at 4:03 PM From: "Cheyenne Wills" @.> To: "spitbol/x64" @.> Cc: "prof55" @.>, "Author" @.> Subject: Re: [spitbol/x64] "ln" function fails (Issue #21)

 

Thanks for the report.

Can you provide information about your system: what type of processor, which os distribution and what level it is, and could you do a 'ldd sbl40b' ?

** inxi -C reports:

CPU:   Info: dual core model: Intel Core i7-6500U bits: 64 type: MT MCP cache: L2: 512 KiB   Speed (MHz): avg: 494 min/max: 400/3100 cores: 1: 466 2: 500 3: 500 4: 513

 

** lsb_release -a reports:

 

No LSB modules are available. Distributor ID:    Ubuntu Description:    Ubuntu 22.04.2 LTS Release:    22.04 Codename:    jammy  

** uname -a reports:

 

Linux LXLE-BU203UA 5.15.0-75-generic #82-Ubuntu SMP Tue Jun 6 23:10:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

 

* I have rebuilt sbl and the new sbl is told as "not a dynamic executable" by ldd. However file* says:

 

/opt/x64/sbl: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=08e2b651783307bcd21c9c75be0e27257f5fd904, for GNU/Linux 3.2.0, not stripped

 

**

 

Also if you have the ability can you try rebuilding spitbol on your machine?

You will need nasm and gcc.

make bootsbl make BASEBOL=./bootsbl spitbol

This should create a new sbl file in the top directory of the source tree.

(and yes .. the makefile needs to be cleaned up more)

Thanks

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

CheyenneWills commented 1 year ago

I've been unable to reproduce the problem using an ubunutu 20 virtual machine (only difference is the actual processor type).

Make sure that you are checking out the development branch.

git clone https://github.com/spitbol/x64.git     -- creates a clone of the git repo (if you haven't already done this)
cd x64
git fetch                     -- just make sure you have the lastest from github (not needed if you do a fresh git clone
git checkout development
# You can try the './bin/sbl' at this point 
# or rebuild (assuming you have nasm and gcc)
make bootsbl
make BASEBOL=./bootsbl spitbol
# Then try the './sbl'
CheyenneWills commented 1 year ago

Dr. Imre Bartfai,

I'm wondering if you are still having a problem with the above instructions?

If you are still having problems, could you possibly produce a core file and attach it?

ulimit -c unlimited {run the file that is causing the segfault}

prof55 commented 1 year ago

Reply to previous letter: thank you for your detailed instructions. Now I was able to have a local spitbol 4.0b. The "ln(" error is disappeared, however I can report now another bug (look at the attachment). The small program runs with spitbol 3.8.1 without problem. The reported error does not fit. An interesting background information: if you comment out the statement #9 -- which actually a floating point comparison -- the error disappears. Look also at the statement count, as it is very small.

Thank you in advance. KR Imre

Obviously, my previous letter is not arrived. Such way here is the reply:

I attached another very simple test file. It causes an overflow, too. Segfault did not happened. If I comment out line #6 (floating point comparison), the error disappears. KR Imre test2.lst.gz

CheyenneWills commented 1 year ago

1st, glad to hear that you were able to get 4.0b "working", and 2nd, thanks for the error report.

There are several problems within floating point that I'm still picking through. I suspect the error you reported will be a fairly simple fix (and highlight more floating point problems).

CheyenneWills commented 8 months ago

I know it's been a bit of time, but I just pushed version 4.0c for spitbol that contains a very large rework of the floating point support.

If you can give that version a try to see if you have any additional problems.

Thanks

prof55 commented 8 months ago

Hello Cheyenne,

 

I am very grateful you give away your precious time to do something I hardly would able. (No irony!).

The binary in the repo has been crashed, but -- thanks to INSTALL.md -- I could recompile a local version which ran without problem.

I made some tests, and I did not experience any problems regarding FPU directly. However, there is another point found I think it could be remedied.

The built-in function date() does not return the right value, instead gives a constant: "01/01/70 01:00:00". It would be nice if it worked.

 

Thank you in advance.

 

KR

dr. Imre Bartfai

 

   

Sent: Monday, October 23, 2023 at 11:16 PM From: "Cheyenne Wills" @.> To: "spitbol/x64" @.> Cc: "prof55" @.>, "Author" @.> Subject: Re: [spitbol/x64] "ln" function fails (Issue #21)

 

I know it's been a bit of time, but I just pushed version 4.0c for spitbol that contains a very large rework of the floating point support.

If you can give that version a try to see if you have any additional problems.

Thanks

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

aksr commented 8 months ago

As it is easily confirmed, DATE() doesn't work. It would be nice, though.

CheyenneWills commented 8 months ago

I've confirmed the date() problem and opened a new ticket for that. If you could follow issue #24

And for the crash, I need more information, I've opened an issue for that as well. I'll put in the issue what the information is that I need. See issue #25.

I would like to close this specific issue since the math functions seem to be working okay now, if that's okay with you.

Thanks

prof55 commented 8 months ago

@.:/opt/x64/bin$ ./_sbl Illegal instruction (core dumped) @.:/opt/x64/bin$ strace ./_sbl execve("./_sbl", ["./_sbl"], 0x7fff8c0ef060 / 60 vars /) = 0 --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x423250} --- +++ killed by SIGILL (core dumped) +++ Illegal instruction (core dumped) @.:/opt/x64/bin$ file _sbl _sbl: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, with debug_info, not stripped @.:/opt/x64/bin$ inxi -C CPU: Info: quad core model: Intel Pentium Silver N5000 bits: 64 type: MCP cache: L2: 4 MiB Speed (MHz): avg: 2010 min/max: 800/2700 cores: 1: 2346 2: 1950 3: 2008 4: 1737 @.***:/opt/x64/bin$ ^C