I am sure that the order of the vars that appear in the program has great impact on compilation.
Ioannis
I am sure that the order of the vars that appear in the program has great impact on compilation.
Ioannis
I don't know but the way I understand and interpret it is that between user variables that HAVE specific bank requests and those that don't the first ones ARE handled first - but still AFTER the PBP system variables have been allocated space.But this is not what is written in par 7.3 (RAM Allocation) of the manual. One can read in the middle of the page "If specific bank requests are made, those are handed first". Bug or misunderstanding from myself ? I don't know.
So, if PBP needs 74bytes in BANK0 you can specify 22bytes to be in BANK0 (if it happens to be 96bytes). If you try to specify a 23'rd byte in BANK0 it can't do that.
/Henrik.
Same here. And you can confirm that looking at .LST file.
Well, well, well
I have done some screen copies of my disassembly listing.
Unfortunately the version of my program for which I had some warning messages is no more available but, however, we can address the issue with these examples.
On the first page one can see the system variables (Flags, R0, R1, R2 ...) starting at 00H and in my case ending at 32H.
They do not take so much room.
The second page is an extract of the space which should be dedicated to BANK0 variables plus others if room is available.
The BANK0 goes up to FFH. I have no problem with "squatting variables" which feel well there but I am concerned when they stay if other more critical variables with a formal BANK0 declaration need to be there.
And believe me or not when the warning message raised I had some BANK0 variables at 102H and 104H and non BANK0 labelled variables inside the BANK0 space. This is what I have observed.
Anyway, placing some non critical variables in BANK1 or elsewhere looks as being a good solution. In my case it works.
Best regards
MikeBZH
Bookmarks