#14 non-contiguous sections

open
nobody
None
5
2012-08-12
2004-05-10
Gabor Kiss
No

Code, udata, etc. sections should be allowed to
be non-contiguous within a source file.

At this moment there is no way to write a macro
that defines variables and generates code too:

foo macro bar, baz
udata
bar res 1
code
movlw baz, bar
endm

(Actually such a macro can be written but
couldn't be called more than once.)

Gabor

Discussion

  • David Barnett

    David Barnett - 2007-11-21

    Logged In: YES
    user_id=896846
    Originator: NO

    The error message is misleading, but there is actually no restriction on sections to be contiguous. I can't tell whether the use of the word "contiguous" was a complete mistake or the error message was created for one purpose and misused for another. At any rate, the error is actually complaining about multiple sections with the same name (the defaults, ".udata" and ".code").

    In any case, the following macro should do exactly what you need:
    foo macro bar, baz
    bar#v(1)data udata
    bar res 1
    bar#v(1)code code
    movlw baz
    movwf bar
    endm
    Note that gpasm is still braindead when handling #v substitutions, but something like them is necessary here. The sections need to have unique names, so they must be generated somehow from the macro arguments or some assembler variable. If they aren't given names, they will default to ".udata", ".code", etc., and will cause duplicate labels on the second macro invocation.

     
  • Gabor Kiss

    Gabor Kiss - 2007-11-24

    Logged In: YES
    user_id=26828
    Originator: YES

    Sorry, David, probably I was not clear.

    I need this:

    store macro val, addr
    udata
    addr res 1
    code
    movw addr
    endm

      code
      movf   TMR1L,W
      andlw  0xf0
      store  value1
      addlw  0x43
      store  value2
    

    loop goto loop

    Now I hope this code after macro substitution:

      code
      movf   TMR1L,W
      andlw  0xf0
      movw   value1
      addlw  0x43
      movw   value2
    

    loop goto loop

      udata
    

    value1 res 1
    value2 res 2

    However even in best case your macro would produce something like this:

      code
      movf   TMR1L,W
      andlw  0xf0
      addlw  0x43
    

    loop goto loop

    some_named code ; relocated somewhere in memory
    movw value1

    other code ; placed elsewhere in memory
    movw value2

    Can you see that execution order of instructions is very different?

    My wish is: if assembler encounters a segment name that is already
    known it should just continue it instead of complaining.

    Gabor

     
  • David Barnett

    David Barnett - 2007-11-24

    Logged In: YES
    user_id=896846
    Originator: NO

    So, to simplify the example a bit, you want this to work:
    name1 code
    [some instructions...]
    name1 code
    [more instructions...]

    Of course, that alone would be useless if you couldn't start a second section and then resume the first, but if gpasm can't do the above, it definitely can't handle the other examples.

    At any rate, this is something MPASM doesn't support, and it changes how the code directive works from MPASM, so we'll probably have to hold off on it for a good while and figure out how to separate the usage so that users don't get confused switching between gpasm and MPASM.

     
  • Gabor Kiss

    Gabor Kiss - 2007-11-24

    Logged In: YES
    user_id=26828
    Originator: YES

    ...figure out how to separate the usage so that users
    don't get confused switching between gpasm and MPASM.

    This is the general downward compatibility problem gpasm suffers from.
    No way to create a useful and handy tool because Microchip does'n do it.
    It's the time to fork a new project. :-)

    Or a new directive may be enough. E.g.
    MPASM_COMPATIBILITY [ON|OFF] ; default ON

    Gabor

     
  • David Barnett

    David Barnett - 2007-11-24

    Logged In: YES
    user_id=896846
    Originator: NO

    In general I think there's enough to keep us busy without breaking compatibility, but that's probably more of a discussion for the mailing list (gnupic@linuxhacker.org). Most of the features MPASM doesn't support have decent workarounds. In this case, I bet you could get a pretty good solution with some kind of preprocessor to collect the declarations and combine them into udata sections at the top of your code. Maybe it's not ideal, but at least you'll be able to get out an intermediate form that will build in any PIC assembler.

     
  • achdawai

    achdawai - 2012-04-03

    Hello,

    I'm bumping into the same problem now.

    Any news on this?

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks