non-contiguous sections

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.

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

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.

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

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.

Hello,

I'm bumping into the same problem now.

Any news on this?