assembly in SF

[janni]

Hi,

While it's convenient to be able to use variable name in assembly directly, respective paragraph in Help only shows haw to use a byte variable. What about multi-byte variables? How can one invoke higher bytes in assembly? Typical <variable name>+n and similar don't seem to work.

[Jerry Messina]

Could you show an example of what you're trying to do that doesn't work?

[janni]

For example, when trying to copy global word variable ww1 to another, ww2

Code: Select all

  asm
    movff    ww1,ww2
    movff    ww1+1,ww2+1
  end asm

compiler accepts the first movff instruction but scorns the second ('Invalid register/symbol name').

EDITED:

Interestingly, the following is accepted

Code: Select all

  asm
    movff    ww1,ww2
    //movff    ww1+1,ww2+1
    movf     ww1+1,W
    movwf    ww2+1
  end asm

but it's hardly a workaround as it not only involves W register but also may require RAM bank switching.

[Jerry Messina]

I'll have to take a look at that and see what's up. MOVFF has some special handling, so maybe that's getting in the way.

[Jerry Messina]

I see where it's going wrong.

Normally, asm statements are just passed along to mpasm "untouched". MOVFF has a range limit of 12-bits (0-4095). When the K42 came out I added special handling in the code generator to detect an asm MOVFF instruction and translate that to the new MOVFFL instruction that can handle 16K of ram.
This was to try and allow existing asm code to work with these devices that moved all the SFR registers up to the top of memory outside the reach of MOVFF.

It only does this if it's required, but it still travels through that code and that's where the issue lies... it doesn't handle expressions in the arguments.
I'll have to see what I can do about that. For the time being about all I could offer is a flag that would let you skip all the "smart" processing and just handle MOVFF like the others.

You might find that SF does a pretty good job in most cases without having to resort to asm. I've done dozens of huge projects and usually I can get by just optimizing things by using some register manipulations.

[Jerry Messina]

Here's a beta version (ICC 1209b1) that allows you to change how MOVFF is handled inside an ASM-ENDASM block.
https://www.sfcompiler.co.uk/wiki/uploa ... _1209b1.7z

Unzip the two files into the compiler's Bin folder, replacing the existing ones (you might want to make a copy of the existing exe as a backup first).
To skip any special processing of MOVFF, edit the SwordfishICC.ini file, scroll to the end and uncomment the line 'asm_movff=0' (remove the ';')

[janni]

Here's a beta version (ICC 1209b1) that allows you to change how MOVFF is handled inside an ASM-ENDASM block.

That did it . Thanks, Jerry.

This was to try and allow existing asm code to work with these devices that moved all the SFR registers up to the top of memory outside the reach of MOVFF.

Yeah, that wasn't a well thought idea on Microchip part.

You might find that SF does a pretty good job in most cases without having to resort to asm. I've done dozens of huge projects and usually I can get by just optimizing things by using some register manipulations.

I don't doubt it, but many of my projects are time and power critical and I need assembly (though mostly in ISRs) to make them as responsive as possible without the option of just increasing clock frequency. SF with its well optimised final code seems perfect for the job but some assembly will still be necessary in code parts where every processor cycle counts.