Author |
Topic: Misbehaviour at addresses >= &80000000 (Read 506 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 803
|
 |
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:
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.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
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:
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.
|
|
Logged
|
|
|
|
michael
Full Member
member is offline
Posts: 157
|
|
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.
|
|
Logged
|
I like reinventing the wheel, but for now I will work on tools for D3D
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
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.
|
|
|
|
|
