How do I compile for 64K RAM? Is it as simple as adding "_runtimeStart_ &hFFFF" ? It seems so.
Edit: it works with v0.9.9B, but latest release crashes when I try to compile a 5000 words array. Without the _runtimeStart_ directive, max array that it could fit was 512 words.
gtBASIC
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: gtBASIC
Last edited by jurkstas on 06 Jan 2021, 00:07, edited 1 time in total.
Re: gtBASIC
Yup, that's all you need to do. Per Marcel's convention, throw a "64K" somewhere into the name so that they know why it will crash on a standard 32K Gigatron.
Single dimensioned arrays use sequential memory, (non segmented), the largest sequential area of RAM is 512 bytes on a 32K system, unless you disable the audio channels.
I'm not sure why 5000 words crashes on a 64K system, it shouldn't. I'm checking for you now on my current internal build, (1.06R).
Single dimensioned arrays use sequential memory, (non segmented), the largest sequential area of RAM is 512 bytes on a 32K system, unless you disable the audio channels.
I'm not sure why 5000 words crashes on a 64K system, it shouldn't. I'm checking for you now on my current internal build, (1.06R).
Last edited by at67 on 06 Jan 2021, 05:16, edited 2 times in total.
Re: gtBASIC
Hi at67, didn't see (nor expect in 2 minutes, haha) your reply and made an edit to my previous message. v0.9.9B would crash in 32k mode and v1.0.1B would crash in either mode. I will look into what is going on.
Re: gtBASIC
Hehe I just happened to scan the website when you posted.
1: You need to specify the "_arraysStart_" pragma as well as "_runtimeStart_", this allows the programmer to confine arrays in the bottom half of a 64K system so that code/images/midi/etc has full access to the much more efficient top half, (by not specifying "_arraysStart_"). But in your case as you are defining large arrays that don't fit in the bottom half, then you need to specify the pragmas like this:
2: The compiler shouldn't crash, it should give you an out of memory error in the console. On my internal build it gives you out of memory errors for your examples without using "_arraysStart_".
3: Use code like this to get the start address and length of the array, (if you need them):
4: gtBASIC arrays always allocate (n+1) * 2 bytes for the default signed word scheme, so dim wordArray(512) will try and allocate 1026 bytes, dim byteArray%(512), would allocate 513 bytes; this is because gtBASIC arrays start at index 0 and the n in dim(n) specifies the last index not the total number of elements.
5: I know I need to work on the documentation and I am
1: You need to specify the "_arraysStart_" pragma as well as "_runtimeStart_", this allows the programmer to confine arrays in the bottom half of a 64K system so that code/images/midi/etc has full access to the much more efficient top half, (by not specifying "_arraysStart_"). But in your case as you are defining large arrays that don't fit in the bottom half, then you need to specify the pragmas like this:
Code: Select all
_runtimeStart_ &hFFFF
_arraysStart_ &hFFFF
3: Use code like this to get the start address and length of the array, (if you need them):
Code: Select all
print hex$(@oneDimArray, 4);" ";len(oneDimArray)
' multi-dimensioned arrays or finding the address of an array at a specific index have to use the addr() function rather than '@'
print hex$(addr(threeDimArray(2, 3, 4), 4);" ";len(threeDimArray)
5: I know I need to work on the documentation and I am
Re: gtBASIC
Hi, just a quick reply. Item 1 makes sense after spending a few hours browsing code. _arrayStart_ was added to in one of the latest versions, right? v0.9.9 vorks with _runtimeStat_ only.
2. Compiled does not crash with the memory issue, but throws the error as supposed to. I think there is something in my code that causes the crash. I will try to make a minimal crashing example and create a bug report.
3. thanks, that might come handy.
4. that is documented somewhat and was clear. I found there is an array inside the compiled that holds all the free memory locations and sizes.
5. Your toolchain is awesome. I looked at your code a bit and it is amazing. I only got to look at it because something was not documented and I did not pick it up from examples quick enough, haha. I should document whatever is not documented, but I figured it out somehow for you to confirm if it is supposed to be that way. Contribute.
2. Compiled does not crash with the memory issue, but throws the error as supposed to. I think there is something in my code that causes the crash. I will try to make a minimal crashing example and create a bug report.
3. thanks, that might come handy.
4. that is documented somewhat and was clear. I found there is an array inside the compiled that holds all the free memory locations and sizes.
5. Your toolchain is awesome. I looked at your code a bit and it is amazing. I only got to look at it because something was not documented and I did not pick it up from examples quick enough, haha. I should document whatever is not documented, but I figured it out somehow for you to confirm if it is supposed to be that way. Contribute.
Re: gtBASIC
Opened an issue regarding the crash: https://github.com/kervinck/gigatron-rom/issues/182
Re: gtBASIC
Yup, also the pragma is _arraysStart_, note the plural arrays, the compiler should warn you about the incorrect speelling though.
Thanks for the bug report, there is already a solution to it in the current internal build and I posted the relevant code fix in a response to your issue.
Yeah there is a free RAM list vector that keeps track of every last byte free in the Gigatron's RAM, doing it's best to maximise efficiency and prevent collisions, page overlaps, (for code), etc. A lot of time was spent on the memory handler, it's one of the better parts of the code base.
Cheersjurkstas wrote: ↑06 Jan 2021, 17:41 5. Your toolchain is awesome. I looked at your code a bit and it is amazing. I only got to look at it because something was not documented and I did not pick it up from examples quick enough, haha. I should document whatever is not documented, but I figured it out somehow for you to confirm if it is supposed to be that way. Contribute.
This was my first real compiler project, so it was a learning process, frustrating at times, but also amazingly fun and satisfying as well. Don't worry too much about documentation, I am about 80% the way through complete documentation for the entire tool-chain, (almost as monumental as the code itself).Re: gtBASIC
Would you consider publishing the internal build? It would be a lot easier to contribute. Especially now that you mention the documentation has progressed so far already. And making commits smaller would make it easier to understand what is happening. For example, https://github.com/kervinck/gigatron-rom/pull/178 had 50k lines changed in a single commit. Amazing!
Re: gtBASIC
I've been committing regularly to a local branch and as you have noticed been completely slack in updating my remote repo and the main repo. Honestly the reason was that there didn't seem too be much interest in the compiler until Delpozzo and yourself came along, so I had resigned myself to just pottering along in my own sandbox.
I'll update remote and main repos shortly with something that is going to make that 50k change seem tiny
I'll also stick to a more regular update cycle from now on.
P.S. The vast majority of those changes are contained within the example and test .gbas source and generated assembly files, I generally rebuild and test all of them with each new change to the compiler and that causes a massive change in each commit; even if the commit itself in terms of compiler changes is tiny.
P.P.S. But this one will legit be large.
One last thing, if you're going to contribute to the compiler codebase specifically, (which is awesome btw), please make pull requests and issues at this repo https://github.com/at67/gigatron-rom rather than the main repo. Once the changes have been verified and tested I'll merge them into the main repo.
The reason for this is to keep the main repo as clean and pristine as possible, one of my main aims is to time capsule Marcel's work as a testament to his ingenuity and engineering skill. You can of course still do whatever you want under your own Contrib section on the main repo and there is always the backlog of main repo Issues that we as a community can hopefully one day fully clear.
I'll update remote and main repos shortly with something that is going to make that 50k change seem tiny
I'll also stick to a more regular update cycle from now on.
P.S. The vast majority of those changes are contained within the example and test .gbas source and generated assembly files, I generally rebuild and test all of them with each new change to the compiler and that causes a massive change in each commit; even if the commit itself in terms of compiler changes is tiny.
P.P.S. But this one will legit be large.
One last thing, if you're going to contribute to the compiler codebase specifically, (which is awesome btw), please make pull requests and issues at this repo https://github.com/at67/gigatron-rom rather than the main repo. Once the changes have been verified and tested I'll merge them into the main repo.
The reason for this is to keep the main repo as clean and pristine as possible, one of my main aims is to time capsule Marcel's work as a testament to his ingenuity and engineering skill. You can of course still do whatever you want under your own Contrib section on the main repo and there is always the backlog of main repo Issues that we as a community can hopefully one day fully clear.
Re: gtBASIC
Initially I was going to open the issue on your fork, but I couldn't. Disabled or maybe I don't have necessary role for it? See here: https://github.com/at67/gigatron-rom/issues it just redirects to pulls.