Hi there,

For context, I'm trying to write an s-c compatible assembler that can be used on any platform.

I'm curious as to how people generally implement possibly zero-page instructions with forward references: you can't tell immediately whether the instruction will be two or three bytes long, and changing it later will shift everything around (potentially changing other possibly-zero-page instructions).

I can think of a couple of ways to solve the problem (multiple passes, or remembering what needs to be fixed and iteratively adjusting), but I was wondering if there's a usual, clean approach or normal compromise.

Thanks,

Zellyn

Aah. Failure to search.

viewtopic.php?t=1639

I'll mention this since it's hardly mentioned on the linked topic. The easy solution to the usual case is just to always define the variables before using them. In the case of ZP variables, doing them all at once eliminates a lot of ORG directives anyway. If non-ZP variables are to go into the same memory space as the code, ie, the code is in RAM, there's no problem defining those further down the source code, but it should still be before the first reference to them.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I think that assuming zero page, and then extending if required is a nice solution. However, some instructions are zeropage only which is a problem.

ldx $foobar,Y and ldy $foobar,Y comes in mind, but I'm sure they are others.
If you were to have to extend them, it would be impossible without using some extra register (A in this case).

That would depend on the system. In small ones, you could get most, or all, of the variables in ZP; but in cases where there's a pre-installed OS that uses up most of ZP for system variables, they leave you with almost none. Even if most of ZP is avialable, it may still not be anywhere near enough if you have large arrays.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Did I ever said it was required to put everything in ZP ?!?

I just mean, in the assembler point of view, to resolve instruction like

lda label

you don't know if label is ZP or not, so it is elegant to assume ZP, and expand the instruction to 3 bytes if label is outside of ZP as a second step.

The problem would be for instructions like

ldx label,Y

which will fail if label is not in ZP.

As far I know, ldx zp,Y and ldy zp,X would be the only problematic instructions (for indirect loads, it's obvious the pointer has to be in ZP).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hopefully the assembler would do as many passes as necessary to eliminate the phase errors, with of course the option to stop it if the continuously updated progress report on the screen makes it clear that it's going to take way too long or never finish at all. I had one of those "rare and well-rationalized cases" (as BDD put it) once where it took many passes to eliminate all the phase errors. It was ok though because it still took only 10-15 seconds to finish IIRC. That was about 1990 and I can't remember what the situation was, but I know was not about 8- versus 16-bit addressing. I seem to vaguely remember it had something to do with conditional assembly in macros.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

... or provide a way to force a zero page or absolute address in the instruction like the WDC assembler does and make the programmer explicitly fix up problems with unresolved labels without doing extra passes.

LDA <LABEL ; Generate a zero-page
LDA |LABEL ; Generate an absolute

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Is there any real reason to avoid extra passes though? Better to have the computer do more work than make the human add and maintain completely redundant information.

That said, forcing absolute addressing to a $00xx address is required sometimes, but then that's not redundant information.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It'll pretty much always boil down to declaring a variable in one place and then using it by name elsewhere, which is hard to make sloppy. Adding a "good practice" constraint about where in order that must happen can sometimes get more messy than allowing it to reside in the organization the programmer chooses, as compile-time decisions and included files can introduce some complex dependencies.

In that last bit, I was specifically meaning where you'd want LDA $21 to be compiled as AD 00 21, instead of A5 21. It's a legitimate zero page address, but you'd want to override the assembler's optimization decision in a few cases: Need to blow an extra cycle for alignment, selfmod it later to other non-zp addresses, use indexing to reach past $00ff, etc. That is legitimate additional intent to communicate to the assembler.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm not talking about cavalier code structure. I'm talking about designed code structure that hits the limits of assumptions that the tools and environment enforce. Attempting to get good code reusability, enabling flexible feature configuration, and optimizing to those selected features using lots of assembly-time directives to configure itself, is where I've hit issues with this the most.

As one small example, inside AcheronVM, instructions are defined as 1-liner macro declarations at the point of instruction implementation. This is the easiest way to be able to add and remove instructions, and is optimal in the "don't repeat yourself" organizational/maintenance sense. The jump tables, opcode allocations, and even generating the include files defining VM instruction -> byte macros, are all done at assembly time, respecting differing types of instruction allocations and alignment concerns. However, even with ca65's great support I still have to hop out into writing external helper programs to do things that should (intuitively) be expressable with the currently available directives; it's ordering and resolving constraints on those directives that limits what you can do with them.



Assembly is a strict subset of compilation (the transformation of code from one form to another), so the use of "compiled" is still technically correct. (I've got a lot of Lisp on the brain, which regularly and substantially blurs the line.)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Pedantry not pardoned! As soon as anyone says "as soon as you said..." my heart sinks. Are we trying to have a friendly discussion here, or aiming to score points off one another? Do we have so little interest in the 6502 that we're not prepared to put the effort in to understand what someone is saying? Which in this case is blindingly obvious. Yes, some people say "compiled" when they mean "assembled" - and it hurts no-one. Yes, in an ideal world we'd all use the same words in the same sense, but in this world almost all of us get by without blowing a fuse. This isn't a military academy.
Cheers
Ed