absolute

[janni]

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]

> 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:

Code: Select all

Public Sub Access test(a As Byte)
   Dim value As Byte
   value = a
End Sub
test(10)

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.

[janni]

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.

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.

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.

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 .

[Jerry Messina]

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.

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

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.

[janni]

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.

Having the frame variables move out of the access bank will likely be self-defeating

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 .
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.

[janni]

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)

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

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.

[Jerry Messina]

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.

[Jerry Messina]

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:

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

[janni]

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.

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.

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.

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.

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.

[Jerry Messina]

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.

In most cases that actually helps to reduce bank switching. There's no one-size-fits-all strategy with these banked memory parts!

Small code change or introduction of new variable may adversely affect variables distribution

It may, but allowing manual placement is probably more fragile. 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.

[janni]

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.

In most cases that actually helps to reduce bank switching.

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.

There's no one-size-fits-all strategy with these banked memory parts!

Exactly my point .

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.

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 .

[Jerry Messina]

Well, if SF is regarded a finished project then the discussion ends here

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.

[janni]

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.