arrays in GFA Basic resetting computer

GFA BASIC-related articles in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

arrays in GFA Basic resetting computer

Postby peterlane » Sat Apr 16, 2016 3:13 pm

When writing a small program in GFA Basic on my Firebee, I found that arrays of about size:

Code: Select all

dim x%(80, 55, 2)


will simply reset the computer. The same program compiled works fine.

In the manual, it says arrays should be no larger than 65535 positions. 80x55x2=8800. Is there a lower limit when using the interpreter?
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: arrays in GFA Basic resetting computer

Postby lp » Sat Apr 16, 2016 4:50 pm

It works here on my setup, should have the same limits as the compiled program.

If you have a firebee I can assume you are using GBE. A compiled program by default will use all available ram unless told not to. The interpreter on the other hand uses a fixed memory size, possibly its running out ram and not handling that very well. Might explain the behavior.

In GBE check menu option Setup -> Interpreter and see what value is at MaxMem, maybe increase it and see if the problem goes away.

If that don't work, can you PM me the source file that crashes the interpreter?

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: arrays in GFA Basic resetting computer

Postby peterlane » Sat Apr 16, 2016 11:13 pm

lp wrote:It works here on my setup, should have the same limits as the compiled program.

If you have a firebee I can assume you are using GBE. A compiled program by default will use all available ram unless told not to. The interpreter on the other hand uses a fixed memory size, possibly its running out ram and not handling that very well. Might explain the behavior.

In GBE check menu option Setup -> Interpreter and see what value is at MaxMem, maybe increase it and see if the problem goes away.

If that don't work, can you PM me the source file that crashes the interpreter?


Thanks Lonny. Yes, I'm running GBE. Out of memory does seem the likely explanation. However, adjusting MaxMem does not fix the problem. MaxMem for the interpreter is, on startup, 524288 bytes, MinMem 262144 bytes.

All I'm running, as a test, is:

Code: Select all

dim x%(30,30,2)
openw 1
clearw 1
print "hi"
~inp(2)
closew 1


If I run this as above, the text 'hi' appears in a black filled window.
If I increase the array size to (80,30,2) then the window does not get filled, and only two white squares appear for the text.
If I increase to (80,60,2) then the computer resets.

I get the same behaviour, for the same array sizes, when I add 2 zeros to MaxMem, setting it to 52,428,800. I also tried increasing MinMem with two zeros as well, to 26,214,400 bytes.

If I run a program, which is simply DO LOOP, the XaAES Task Manager says the RO_V4E program has a size 655,360 bytes, on the default memory settings, and 13,377,536 when I add two zeros to both MaxMem and MinMem, so changing those values does seem to affect the memory taken by the interpreter.

I'm not running any other programs alongside, aside from Mint and Teradesk.

Anyhow, as I said, the compiled programs seem to work fine. I'll just be careful with array sizes when testing in the interpreter!
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
Mikefulton
Captain Atari
Captain Atari
Posts: 169
Joined: Sun Nov 29, 2015 10:27 am

Re: arrays in GFA Basic resetting computer

Postby Mikefulton » Sun Apr 17, 2016 12:35 am

Have you tried running it under a debugger?

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: arrays in GFA Basic resetting computer

Postby lp » Sun Apr 17, 2016 2:06 am

peterlane wrote:Anyhow, as I said, the compiled programs seem to work fine. I'll just be careful with array sizes when testing in the interpreter!


It works here with much larger values in the DIM statement, however its not a firebee I'm testing on. The interpreter was heavily patched and maybe a problem remains that I overlooked. I'm wondering if you can get it down to just the DIM statement. There are patches inside DIM, so if it crashes with a single line, that's a good place for me to start looking.

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: arrays in GFA Basic resetting computer

Postby peterlane » Sun Apr 17, 2016 10:30 am

Mikefulton wrote:Have you tried running it under a debugger?


I'm not in the habit of using a debugger. Is there one for the Firebee?
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: arrays in GFA Basic resetting computer

Postby peterlane » Sun Apr 17, 2016 10:44 am

lp wrote:
peterlane wrote:Anyhow, as I said, the compiled programs seem to work fine. I'll just be careful with array sizes when testing in the interpreter!


It works here with much larger values in the DIM statement, however its not a firebee I'm testing on. The interpreter was heavily patched and maybe a problem remains that I overlooked. I'm wondering if you can get it down to just the DIM statement. There are patches inside DIM, so if it crashes with a single line, that's a good place for me to start looking.


Yes, it crashes just with the dim statement.
i.e.:

Code: Select all

dim x%(30,30,2)


If I use 80, 60, 2 then the computer will crash. I can just see the "preprocessing OK" message, and then the machine resets.

Other odd behaviour, if I use 50,30, 2 the program-end dialog has no contents, just the outer frame and an outline for the button. If I use 80,30,2 the interpreter does not seem to run ("Preprocessing OK" shows, but then it's straight back to the editor.)

I get similar behaviour with a single-dimensioned array, though the total numbers are larger:

Code: Select all

dim x%(6000)
and the program-end dialog has no contents.

Code: Select all

dim x%(8000)
and no dialog shows.

Code: Select all

dim x%(20000)
and the computer resets.

These are all with the default memory settings.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: arrays in GFA Basic resetting computer

Postby lp » Sun Apr 17, 2016 11:29 am

That's not good at all. I would say don't use the interpreter at this point, you can rename the binary *.prx just in case you accidentally click run. I would guess some memory leak or pointer is wrong. I applied something like 150+ patches to the interpreter, it was not very cf friendly to begin with. The compiler and linker however seem pretty solid and should be reasonably fast so you can get by without the interpreter. Rajah builds some rather impressive apps with GBE, but I think he never uses the interpreter. Thanks for the reports, I will look into it.

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: arrays in GFA Basic resetting computer

Postby peterlane » Sun Apr 17, 2016 12:43 pm

Thanks for taking a look at this. I've been enjoying coding with GBE this Easter and hope to try some GEM programs in the coming months. Let me know if I can help with testing on the Firebee.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: arrays in GFA Basic resetting computer

Postby lp » Sun Apr 17, 2016 1:08 pm

Well I have two questions. :)

If you add this line: PRINT ERR just before the DIM what value do you get?
0=internal malloc succeeded or 8=malloc failed
Do all variable types fail? DIM x&(...) or DIM x|(...) etc.

User avatar
Rajah Lone
Captain Atari
Captain Atari
Posts: 371
Joined: Wed Aug 07, 2002 12:27 pm
Location: Lyon / France
Contact:

Re: arrays in GFA Basic resetting computer

Postby Rajah Lone » Sun Apr 17, 2016 1:43 pm

DIM works but I have the feeling it should be used on small arrays and 1 or 2 dimensions only. Compiler & linker are fast enough for tests, so interpreter mode is never used.

Recently, for the lastest release of my X2 project, I used a big 3D DIM for levels maps. Bad idea. First thing to code for the next release is to externalize this array outside GFA RAM, in clean mxallocated zone.

peterlane
Atari maniac
Atari maniac
Posts: 94
Joined: Tue Mar 05, 2013 2:44 pm
Contact:

Re: arrays in GFA Basic resetting computer

Postby peterlane » Sun Apr 17, 2016 1:58 pm

lp wrote:Well I have two questions. :)

If you add this line: PRINT ERR just before the DIM what value do you get?
0=internal malloc succeeded or 8=malloc failed
Do all variable types fail? DIM x&(...) or DIM x|(...) etc.


with x% I get 0 for the error message in all cases, including the distorted or missing program-end dialog, until it crashes, when I don't get time to see the error message.

with x! there are no problems, all the way up to 65000 size.

with x& I get the same problems as with x%: program-end dialog is distorted around 9000 and computer crashes at size 30000.
Peter Lane
Firebee | STE (4Mb, TOS 2.06)
http://peterlane.info/firebee.html

User avatar
Mikefulton
Captain Atari
Captain Atari
Posts: 169
Joined: Sun Nov 29, 2015 10:27 am

Re: arrays in GFA Basic resetting computer

Postby Mikefulton » Sun Apr 17, 2016 7:47 pm

peterlane wrote:
Mikefulton wrote:Have you tried running it under a debugger?


I'm not in the habit of using a debugger. Is there one for the Firebee?


I have no idea about Firebee or any specific requirements it might have about debuggers.

My idea was along the lines of, run the debugger, then load and run GFA basic, load your program, then run it. When GFA crashes, the debugger would catch it and you would be able to look at the crash information to get a clue as to the problem.

For example, it might indicate a bus error on a MOVE instruction that specifies an out-of-range address.

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2257
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: arrays in GFA Basic resetting computer

Postby lp » Mon Apr 18, 2016 9:05 am

This issue seems to be resolved, updated interpreter can be found at my public dropbox in folder \gfabasic
https://www.dropbox.com/sh/hk65mapqd3fm ... KqQTa?dl=0

peterlane,
Thanks again for the report and testing. ;)


Social Media

     

Return to “GFA BASIC”

Who is online

Users browsing this forum: No registered users and 1 guest