absolute
Moderators: David Barker, Jerry Messina
absolute
It appears that the keyword absolute was not intended as a directive for compiler to reserve space for a variable. It apparently acts only as another way to overlay a variable on another one(s) . I wish I was mistaken, but any attempts at declaring a variable in access bank ends with it being overwritten by other variables. Is there any way to place a variable in the access bank and make the compiler to reserve space for it?
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: absolute
> It apparently acts only as another way to overlay a variable
> on another one(s)
Incorrect. It places a variable at an absolute address. If it overlays another variable, then that may / may not be an unintended consequence. Generally though, it is used to map a variable onto a microchip SFR.
You cannot force variables to use access bank at the module level. You can use it with the compile time stack for subs and functions. For example:
with place any params / local variables / return in access bank space. However, this is a very early compiler keyword that worked well with older devices. I'm not sure how well it would cope with some newer devices.
> on another one(s)
Incorrect. It places a variable at an absolute address. If it overlays another variable, then that may / may not be an unintended consequence. Generally though, it is used to map a variable onto a microchip SFR.
You cannot force variables to use access bank at the module level. You can use it with the compile time stack for subs and functions. For example:
Code: Select all
Public Sub Access test(a As Byte)
Dim value As Byte
value = a
End Sub
test(10)
Re: absolute
This just confirms what I've stated. Apart from declarations of SFRs (which compiler is restricted from overwriting) in definition files, keyword absolute turns variable declaration into declaration of an alias. Compiler neither reserves space for such alias nor takes it into account when estimating memory use.David Barker wrote: ↑Fri Sep 23, 2022 1:49 pmIncorrect. It places a variable at an absolute address. If it overlays another variable, then that may / may not be an unintended consequence. Generally though, it is used to map a variable onto a microchip SFR.
Which means that with larger programs all space in access bank will be taken . Thanks for the example but compiler places subroutine params, variables and results in access bank as a rule and uses higher RAM only when there's not enough space. Anyway, forcing one routine over others to use access bank won't help in reserving space in access bank for global variables .You cannot force variables to use access bank at the module level. You can use it with the compile time stack for subs and functions.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: absolute
If you're really hell-bent on trying to use the access bank, there's a hack that seems to work...
it requires you to edit the device file, and should work with SF 2231 and later.
Totally unsupported, so caveat emptor.
I would limit this to the absolute minimum. Having the frame variables move out of the access bank will likely be self-defeating,
and the system variables MUST be located there.
it requires you to edit the device file, and should work with SF 2231 and later.
Code: Select all
// edit device file and change '#option org_ram' to reserve the desired amount
// of access bank ram
// ie change '#option ORG_RAM = $0000' to '#option ORG_RAM = $0000 + 16'
// NOTE: you are completely on your own here... you MUST ensure that the
// access bank has enough space to hold the system variables
// set amount of reserved access bank ram used (must be <= amount added above)
#option RESERVE_BYTES = 10
// check to ensure 'org_ram' has been set large enough
#if ((org_ram - _accessbank_start) < RESERVE_BYTES)
#error "option ORG_RAM < number of reserved bytes"
#endif
// declare the reserved block (absolute)
const ARRAY_SIZE = RESERVE_BYTES
dim res_block(ARRAY_SIZE) as byte absolute _accessbank_start
I would limit this to the absolute minimum. Having the frame variables move out of the access bank will likely be self-defeating,
and the system variables MUST be located there.
Re: absolute
Thanks Jerry,
I actually thought about doing that, but continued thinking how to reserve upper part of access bank rather than the initial one. And it's obviously not a convenient method as it requires making changes to definition file for every project.
In my comparatively small math test program, code savings due to placing few variables in access bank exceeded 200 bytes and, most importantly, noticeably sped up the execution. That's quite important when the code needs a week to execute.
I actually thought about doing that, but continued thinking how to reserve upper part of access bank rather than the initial one. And it's obviously not a convenient method as it requires making changes to definition file for every project.
Not really. Apart from the fact that good programmer should be better in optimising RAM use than a compiler, SF switches bank before using any variable in access bank - at least for parts with access bank moved above 0. It's hard to make things worse by using part of this bank, even for an average programmer .Having the frame variables move out of the access bank will likely be self-defeating
In my comparatively small math test program, code savings due to placing few variables in access bank exceeded 200 bytes and, most importantly, noticeably sped up the execution. That's quite important when the code needs a week to execute.
Re: absolute
To illustrate the need of being able to distribute variables in a smart way here's a comparison of final code of just one Basic code line:
- when compiler manages the variables distribution
- and when some crucial variables are forced into access bank (just one in this case)There are 7 bank switching instructions missing on the right side because there's simply no need for bank switching (thus reducing the code by about 40%). Now, this particular line of code is executed 'only' 65536 times (there are much bigger loops in the test program) which means savings of almost half a million cycles just on this single line.
So I wish SF had an option to declare variables at specific positions in memory, not just aliases, because it can have real impact on final code.
- when compiler manages the variables distribution
- and when some crucial variables are forced into access bank (just one in this case)
Code: Select all
?I000585_F000_000256_P000255 ; L#MK ii2 =ii-ii2-temp
// compiler distribution // ii2 forced in access bank
MOVLB 5 MOVF II2_ADF_M12_S16,0,0
MOVF II2_M1056_S16,0 SUBWF II_F114_S16,0
MOVLB 0 MOVWF F140_S16
SUBWF II_F114_S16,0 MOVF II2_ADF_M12_S16H,0,0
MOVWF F140_S16 SUBWFB II_F114_S16H,0
MOVLB 5 MOVWF F140_S16H
MOVF II2_M1056_S16H,0 MOVF TEMP_F118_S16,0
MOVLB 0 SUBWF F140_S16,0
SUBWFB II_F114_S16H,0 MOVWF II2_ADF_M12_S16,0
MOVWF F140_S16H MOVF TEMP_F118_S16H,0
MOVF TEMP_F118_S16,0 SUBWFB F140_S16H,0
SUBWF F140_S16,0 MOVWF II2_ADF_M12_S16H,0
MOVLB 5
MOVWF II2_M1056_S16
MOVLB 0
MOVF TEMP_F118_S16H,0
SUBWFB F140_S16H,0
MOVLB 5
MOVWF II2_M1056_S16H
So I wish SF had an option to declare variables at specific positions in memory, not just aliases, because it can have real impact on final code.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: absolute
I think it's safe to say that any code/variable placement hand-optimized by a human is going to beat the compiler 99% of the time.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: absolute
A few things I do in cases like this where there are multiple banks involved is to try and re-write the code to reduce the creation of any temp variables, if possible.
Also, I try and keep all the variables as either module-level or frame variables (which hopefully end up in the access bank, but there's no guarantee of this). If you're in a sub then making a copy of a module-level static and using that can greatly reduce code. That's especially true for things like arrays of structures.
Something like this completely useless example:
Also, I try and keep all the variables as either module-level or frame variables (which hopefully end up in the access bank, but there's no guarantee of this). If you're in a sub then making a copy of a module-level static and using that can greatly reduce code. That's especially true for things like arrays of structures.
Something like this completely useless example:
Code: Select all
dim ii2 as integer
sub mysub()
dim ii, temp as integer
dim t_ii2 as integer // local copy of module level var
t_ii2 = ii2 // get a copy
t_ii2 = ii - t_ii2 - temp
ii2 = t_ii2 // update module-level static
end sub
Re: absolute
Probably depends on the human but even best compiler cannot produce optimal code for every conceivable case. That's why leaving a way to pass control over variables and code distribution to a programmer is necessary and implemented in most compilers for small processors.I think it's safe to say that any code/variable placement hand-optimized by a human is going to beat the compiler 99% of the time.
Yes, that is one way of reducing bank switching, but one can only hope that all variables in a routine will fit within the same bank. Small code change or introduction of new variable may adversely affect variables distribution. Still, in programs that use just two or three memory banks and not too many global variables, it's a plausible solution.If you're in a sub then making a copy of a module-level static and using that can greatly reduce code. That's especially true for things like arrays of structures.
Problems start when there are many global variables, and especially if there are big ones among them. If compiler places large variable between the smaller ones (which usually happens), bank switching instructions multiply. It also doesn't help that the compiler uses the lowest part of memory (including access bank) for local variables, subroutine parameters and results thus pushing global variables higher in memory. Without the possibility of controlling variables placement there's no sure way of eliminating resulting excessive RAM bank switching.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: absolute
In most cases that actually helps to reduce bank switching. There's no one-size-fits-all strategy with these banked memory parts!It also doesn't help that the compiler uses the lowest part of memory (including access bank) for local variables, subroutine parameters and results thus pushing global variables higher in memory.
It may, but allowing manual placement is probably more fragile. At least the code works, which I think is the point for most users.Small code change or introduction of new variable may adversely affect variables distribution
For the more advanced situations there are almost always work-arounds. YMMV.
Re: absolute
Indeed, it's a good strategy for programs with small memory requirements and maybe that's all that is needed for most users. The fact that nobody noticed the error that you fixed lately and which showed up only when more memory was in use may even corroborate that.Jerry Messina wrote: ↑Sat Sep 24, 2022 2:43 pmIn most cases that actually helps to reduce bank switching.It also doesn't help that the compiler uses the lowest part of memory (including access bank) for local variables, subroutine parameters and results thus pushing global variables higher in memory.
Exactly my point .There's no one-size-fits-all strategy with these banked memory parts!
Well, if SF is regarded a finished project then the discussion ends here . At least the feedback is excellent and speed in fixing errors astonishing .At least the code works, which I think is the point for most users.
For the more advanced situations there are almost always work-arounds. YMMV.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: absolute
I don't think we're ever "finished"... for example SF is typically the first (if not only) third-party BASIC compiler to add support for new pic18 devices. But we have to be careful changing the way an existing feature works, even with what appears to be a simple change.Well, if SF is regarded a finished project then the discussion ends here
Re: absolute
My intention was not to imply that SF is not maintained, on the contrary, I did compliment the way it is. But there's a difference between product maintenance and expansion and last sentences of your previous message directly suggested that you see no need for changes. Even now, you write about changes to existing features...
Please do not doubt that, like everybody else, I do not wish SF to become unstable due to careless modifications. Intending to work with SF, I'd be the first checking that nothing untoward happened after addition of any new feature and pointing out any problems. And there's always the option of beta version release that's a surest way to avoid exactly the kind of problems you expect.
Anyway, it's your product and your vision of SF's future and if you don't see a point in the changes I suggest, you may simply ignore my opinion.
BTW, if there are some future changes planned for SF, it would be nice to know about them.
Please do not doubt that, like everybody else, I do not wish SF to become unstable due to careless modifications. Intending to work with SF, I'd be the first checking that nothing untoward happened after addition of any new feature and pointing out any problems. And there's always the option of beta version release that's a surest way to avoid exactly the kind of problems you expect.
Anyway, it's your product and your vision of SF's future and if you don't see a point in the changes I suggest, you may simply ignore my opinion.
BTW, if there are some future changes planned for SF, it would be nice to know about them.