import/export of zeropage symbols using pragmas in C does not work as expected

[mrdudz]

what i did was exporting a symbol in one C file, using pragmas to make it a zeropage symbol and also pushing it into a custom segment. and then i import it in another file, again using pragma to make it a zeropage symbol (as described in the docs):

extern char foo;
#pragma zpsym ("foo")
int n;
int main(void) {
    n = foo;
    return 0;
}

//#pragma bss-name (push,"ZEROPAGE")            /* no warning */
#pragma bss-name (push,"MYZEROPAGE")            /* warning */
char foo;
#pragma zpsym ("foo")
#pragma bss-name (pop)

now the odd thing is, the assembler gives this warning:

zpsym2.s(18): Warning: Symbol `foo' is absolute but exported zeropage

...which seems wrong (and is a bit irritating). also the generated code is correct (uses zeropage adressing).

whats interesting is that the warning goes away when putting the symbol into the regular "ZEROPAGE" segment (without changing anything else) - that seems to imply that its actually a bug, because for extra zeropage variables using an extra segment is pretty much required.

[fo-fo]

Earlier discussion (for people who were not involved): http://sourceforge.net/p/cc65/mailman/message/34776608/

IMO it's still more of a limitation rather than a bug, though. That said, it would be good to see the bss-name and other similar pragmas extended to accept an address size specifier, which would remove the limitation.

[greg-king5]

I agree with "fo-fo". Uz said that we are supposed to create the variables in Assembly files; then, link and use them in C files. We aren't blocked from using our own zero-page variables in C code; we just cannot do it with pure C and most of the supplied configurations.
So, I think that this should be labeled "enhancement".

This reminds me about a complaint that I have about Uz's design: the compiler steals .zeropage from us! A much nicer design would put cc65's pseudo-registers in their own named segment (e.g., "CC65REGS"). Then, the easier-to-type .zeropage directive would be left free for Assembly programmers to use. (And, groepaz could use it in his pure C projects.)

[mrdudz]

A much nicer design would put cc65's pseudo-registers in their own named segment (e.g., "CC65REGS"). Then, the easier-to-type .zeropage directive would be left free for Assembly programmers to use. (And, groepaz could use it in his pure C projects.)

i dont agree, its equally ugly and just hiding the actual problem (which is that the name of the actual zeropage segment is hardcoded into the assembler). and... wouldnt that require to hardcode that CC65REGS segment the same way? yuck
another thing: there are scenarios where you might want more than one zeropage segment even when just using assembly, eg when you keep using some kernal functions on the c64.

[greg-king5]

Some of the supplied configurations already have several zero-page segments (look at "lynx.cfg"). "CC65REGS" would be another one of them. It always would be first in the list (so that dynamically-loaded modules can find the pseudo-registers). But other than that, it would be like all of the other zero-page segments. It doesn't need to be hardcoded (the others aren't hardcoded).

The .zeropage line in "libsrc/runtime/zeropage.s" would be changed to .segment "CC65REGS":zp. In most of the cc65 project's configuration files, the "ZEROPAGE" name would be changed to "CC65REGS". Those are the only changes that would be needed in the project itself.

The "sticking point" is that it wouldn't be backward-compatible with people's existing projects that have their own configuration files -- users would be forced.to edit those files before they could build those projects.

I agree that we would have a problem if we wanted our pure C project to spread its zero-page variables among several different segments -- currently, it can't be done without the warning message.

[cogwheel]

@oliverschmidt #1282 did not fix this issue. Exporting definitions as zeropage works but importing extern declarations does not.

#pragma bss-name (push, "ZEROPAGE")
extern char foo;
#pragma bss-name (pop)

void bar() {
	++foo;
}

Compiles to:

;
; File generated by cc65 v 2.19 - Git ce3bcad
;
	.fopt		compiler,"cc65 v 2.19 - Git ce3bcad"
	.setcpu		"6502"
	.smart		on
	.autoimport	on
	.case		on
	.debuginfo	off
	.importzp	sp, sreg, regsave, regbank
	.importzp	tmp1, tmp2, tmp3, tmp4, ptr1, ptr2, ptr3, ptr4
	.macpack	longbranch
	.import		_foo            ; <<<<<<<< This should be .importzp <<<<<<<<<<
	.export		_bar

; ---------------------------------------------------------------
; void __near__ bar (void)
; ---------------------------------------------------------------

.segment	"CODE"

.proc	_bar: near

.segment	"CODE"

	ldx     #$00
	inc     _foo
	lda     _foo
	rts

.endproc

[oliverschmidt]

@cogwheel: I'm not maintaining cc65 anymore. It's not useful to mention me in comments.