BBC BASIC
« Misbehaviour at addresses >= &80000000 »

Welcome Guest. Please Login or Register.
Feb 20th, 2017, 12:40am


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Misbehaviour at addresses >= &80000000  (Read 61 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 358
xx Misbehaviour at addresses >= &80000000
« Thread started on: Jan 6th, 2017, 4:13pm »

I've just discovered yet another case of a misbehaviour of BBCSDL when an object (in this case a structure) happens to reside in the upper half of the memory map. It's not the first such example, but I've been fixing them as I've found them.

The problem stems from the fact that addresses above &80000000 (2 Gbytes) are - or should be - negative when represented as a 32-bit signed integer, which is the only 32-bit data type BBC BASIC has. Unfortunately in BBCSDL v0.15a (and BB4W) a structure always has an unsigned (positive) address. This can result in a 'Number too big' error from code like this:

Code:
      address% = struct{} 

This issue doesn't normally show up in BB4W because in most circumstances the upper half of the memory map is reserved for the Operating System, so user memory won't be found there. But that doesn't apply to Linux, Mac OS or Android hence why it is now coming to light.

I will fix this in the next release of BBCSDL, due at the beginning of February. It is not my intention to modify BB4W since, for the reasons given above, it will not normally be affected.

Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 358
xx Re: Misbehaviour at addresses >= &80000000
« Reply #1 on: Jan 29th, 2017, 01:42am »

Would you believe I've found yet another example! It's closely related to the structure-address case: this time it's the 'address-of' operator ^. This returns an unsigned (positive) value so if the variable resides in the upper half of the memory map an assignment such as the following will fail with a 'Number too big' error:

Code:
      address% = ^variable 

Once again this won't manifest in Windows, but it can in other Operating Systems (it was noticed on an Android device). As with the previously reported bug I will fix it in the next release of BBCSDL but probably won't bother to fix it in BB4W.

These bugs reveal an astonishing degree of incompetence on my behalf. I have had to confess before that BB4W and BBCSDL are very poorly coded and this is further evidence.

Richard.
User IP Logged

michael
New Member
Image


member is offline

Avatar




PM


Posts: 36
xx Re: Misbehaviour at addresses >= &80000000
« Reply #2 on: Jan 29th, 2017, 02:45am »

Quote:
These bugs reveal an astonishing degree of incompetence on my behalf. I have had to confess before that BB4W and BBCSDL are very poorly coded and this is further evidence.



I think BBC4W has a pretty good track record and the fact that you are finding these flaws, just shows how skilled you still are.



User IP Logged

I like reinventing the wheel, but for now I will work on tools for D3D
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 358
xx Re: Misbehaviour at addresses >= &80000000
« Reply #3 on: Jan 29th, 2017, 08:33am »

on Jan 29th, 2017, 02:45am, michael wrote:
the fact that you are finding these flaws, just shows how skilled you still are.

There's no skill involved in finding them: programs just fail when run on non-Windows platforms like Android! There's sometimes a little skill involved in fixing them without making the code any bigger.

I'm not so worried about BBCSDL (SDL itself already makes it bloated) but I don't like to increase the size of the BB4W runtime engine because that inevitably makes it run more slowly through less efficient cache usage.

Richard.
« Last Edit: Jan 29th, 2017, 08:34am by Richard Russell » User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls