Automatic Banking with SX/B
pjv
Posts: 1,903
@Terry;
Hello Terry; I find myself in a somewhat precarious situation in a project where the SX48 is so full, that everytime I need to add or change something, first I have to "write some negative code" to free up some space for the new feature to fit. I am using SX/B, so the efficiency over assembler is not so good, but the "big picture" grasping is way better ...... 4K of assembler with 95 subroutines and over 200 variables·is kinda difficult to keep your head wrapped around; for me anyway.
So I need to compact up what SX/B does for me, and it seems that a better way for me to address variables is to alias them and have the bank for a subroutine set as part of the subroutine declaration, effectively compiling something like:
Subname SubBank, {Paramerter{s}}
into:
__SubName
············· call···· SaveFSROnStack······'need to save the old fsr... readily incorporated in declaration area
············· bank···SubBank················· 'switch to new bank
············· jmp·· ·@SubName·············· 'jump to the called routine
Naturally, on returning from the subroutine, the RET needs the incorporate an fsr resore from the fsr stack.
Now, this can all be done in assmbler, but in trying to mix SX/B into the fray, things get a little messy in the SX/B declaration area, and subroutine calling parameters. So my question is, can a special symbol be used to coax the declaration of a routine to include some user defined (assembler) code, and a special symbol to convince the calling convention to also permit the use of W as a parameter?
I believe for those who are using SX/B together with a good swack of assembler, they will be able to save perhaps as much as 20% code space..... possibly more if a greater amount of assembly is incorporated.
Just a wild shot here, thanks for listening.
Cheers,
Peter (pjv)
Hello Terry; I find myself in a somewhat precarious situation in a project where the SX48 is so full, that everytime I need to add or change something, first I have to "write some negative code" to free up some space for the new feature to fit. I am using SX/B, so the efficiency over assembler is not so good, but the "big picture" grasping is way better ...... 4K of assembler with 95 subroutines and over 200 variables·is kinda difficult to keep your head wrapped around; for me anyway.
So I need to compact up what SX/B does for me, and it seems that a better way for me to address variables is to alias them and have the bank for a subroutine set as part of the subroutine declaration, effectively compiling something like:
Subname SubBank, {Paramerter{s}}
into:
__SubName
············· call···· SaveFSROnStack······'need to save the old fsr... readily incorporated in declaration area
············· bank···SubBank················· 'switch to new bank
············· jmp·· ·@SubName·············· 'jump to the called routine
Naturally, on returning from the subroutine, the RET needs the incorporate an fsr resore from the fsr stack.
Now, this can all be done in assmbler, but in trying to mix SX/B into the fray, things get a little messy in the SX/B declaration area, and subroutine calling parameters. So my question is, can a special symbol be used to coax the declaration of a routine to include some user defined (assembler) code, and a special symbol to convince the calling convention to also permit the use of W as a parameter?
I believe for those who are using SX/B together with a good swack of assembler, they will be able to save perhaps as much as 20% code space..... possibly more if a greater amount of assembly is incorporated.
Just a wild shot here, thanks for listening.
Cheers,
Peter (pjv)
Comments
That really is a bad request:
1. It would double jumptable entries from 2 to 4 codewords,
effectively limiting SUBS from 127 to 64.
2. There is no gain as each entry calls one SUB, so the extra
code can as well be placed at the SUB.
If necessary, you can save fsr upon SUB entry into __PARAM5.
Using byte/word modifiers in the SUB declaration there is no real need
for SUBs with a variable number of arguments (which generates even more code).
Best strategy to save codespace is to declare variables with @
and do the bankswitching yourself. You can use __PARAMx
variables to access variables across banks.
regards peter
You are right; at least about the jump table. At present I have 95 SUBs, and I had not twigged that I would overflow that page... silly me for not doing the math. So it would not have helped in this case.
That said, there is still a good use for a special symbol to cause W to be used as a parameter. Again, to keep code tight, I usually use the calling parameters as variables in a sub (in fact at times all of them plus some shadow stacks) so I won't need to mess with bank switching.
Furthermore, mixing SX/B with assembly, and throwing macros into the mix makes thing very awkward. Again, the special symbol-for-W case would help. At present I use all 5 parameters, and wish I could also pass W without having to revert to assembly. The W and fsr get saved in their respective shadow stacks.
Doing all the bank switching manually is of course possible..... I was hoping to leave some of that tedium to SX/B.
Anyhow, if passing W is not easy, then I will have to live with things the way they are.
Sorry for causing a fuss.
Post Edit:
Peter, in re-reading your explanation·I now realize I had not adequately explained the RETURN issue of what I am trying to do, and that is the automatic return to the bank of the calling routine from the bank stack. So far an elegant way to implement a user friendly way to generate the code has eluded me. The assembler macros do not want to play nicely with SX/B. Being able to pass a parameter in W would help that quite a bit. But I'm still working on it so hopefully something reasonable will fall out. Also, I do find the documentation on the macros to be woefully inadequate; particularly in that it suggests·of the power and capabilities, but lack of specifics.
Cheers,
Peter, (pjv)
Post Edited (pjv) : 5/22/2009 2:42:39 AM GMT