Can I edit the program counter value ?
help me!

> Can I edit the program counter value ?

In a sense, yes, using a JMP, JSR, or any of the branch instructions (BNE, BEQ, BMI, BPL, BVC, BVS, BCC, BCS, BRA, BBS, & BBR). Other instructions that alter the program counter are RTS, RTI, and BRK. The three hardware interrupts (including reset) will also affect the program counter.

Using JSR and then pulling the return address off the stack, you could do more direct editing, but it's very inefficient and the usefulness is pretty limited. It might be used, for example, in writing relocatable code, but this is not done much with the 6502. The 65816 has more capabilities in this area.

Garth

No it doesn't. It has the exact same set of (basic) primitives available for manipulating the PC as the 6502 did. The only new additions are support for indirect JSRs and some new branch modes.

Other than that, the 65816 is as static as the 6502.

That being said, relocatable code and position-independent code (PIC) are generally considered to be separate things in the field of computer science, and it's important to distinguish between them (unless you explicitly define what you mean).

Relocatable code is basically static code emitted by an assembler or linker, but with additional "meta-data" (as it's called) informing the code loader where things need to be relocated. So, if you have the following instructions:



The resulting opcodes will probably be emitted like this:



Note that, if left unmodified, the CPU would see these instructions as targetting location 0 in all cases. To prevent this, the loader needs to know three things for each relocation "fixup":

1. Where in the loaded image do I relocate,
2. What value do I add to what's already there, and,
3. How big is the field I'm modifying?

Executable formats like this are said to be "relocatable file formats," because relocation occurs at load-time. Such a relocation table might look like this (assuming the above code started at offset zero):



Position-independent code, however, is software that is written expressly to be dynamically repositioned at run-time. This requires the software to constantly determine where things are because it doesn't know whether or not it's been moved. Therefore, you'll see instruction sequences such as this quite often:



It's ugly, it's slow, and on the 6502, it's overwhelmingly more efficient to NOT do this. It's actually better to keep a table of fix-ups for the binary in the binary itself, and when dynamic relocation is necessary (the rules for adding offsets to what's there are going to be different of course), it's done at the time of relocation, rather than run-time.

Note that CPUs with lots of registers can get around this, since they usually have at least the following addressing modes:



where regA is used as some pointer relative to regB (which I'll define to be the "base" since it's assigned regB), which in turn is further offset by the constant, if given. Such CPUs can usually do this math in a single clock, maybe two at most (now-a-days at least).

For example, in AmigaOS Classic (68000-based environment), register A6 is used as the shared library base pointer, from which all library-related data can be accessed (including system information).

--
Samuel A. Falvo II

hjlin apparently is just getting into this stuff and I expect the question probably came from a class assignment. I tried to keep the answer simple and appropriate for that level.

As to relocatable code however, I was not so much thinking of the situation where you have a program that might get moved around after it has already started running, but rather that it is written such that it can be loaded at different starting addresses, depending on what's available at the time, without assembling or linking again, and without much complication at all in a loader.

The '816 does have several nice things that make this more practical.

> No it doesn't. It has the exact same set of (basic) primitives available
> for manipulating the PC as the 6502 did. The only new additions are
> support for indirect JSRs and some new branch modes.

It does have a branch-relative-long and more indexed modes too; but beyond what you're mentioning here, what I was especially thinking of things like the PER instruction. For the 6502, figuring out an address relative to where the program counter is at the time is a complex, inefficient process; but the 65816's PER instruction adds the operand to the address of the next instruction (regardless of where you started loading the program), and pushes the result on the stack. From there, you can use it to get to data or program addresses (like with a simulated JSR-relative) that might be different each time you run the program. Stack-relative addressing further expands the possibilities.

Garth

OK, I'll agree with this. I completely forgot about this instruction.

I agree that position-independent code has advantages, and that a register-poor chip like the 6502 is handicapped in this regard.

Any of you worked with CDP1802s? Early CMOS uPs from RCA.

When I decided to take a look at getting back into "microcontroller scale" stuff like 6502-based machines I vacillated between the 6502 and the 1802. These two are radically different beasts to program. The 1802 doesn't even have a fixed program counter per se, you designate a general purpose 16-bit register. Structures such as coroutines are trivial to implement at a low level then, just swap p-counters.

But the 1802 is a bizarre thing to work with, and hard to come by - even though I think there are 16Mhz versions around now. Most of the support chips from the family have disappeared (Intersil owns the 1802 right now I think and all I find on their site is the 1802 itself). Still, it was the 1st rad-hard uP (in the silicon-on-sapphire model) and several are still working out at the fringes of the Solar system. Several deep-space probes used (use?) 1802s: Voyager, Pioneer, etc.

Pretty cool. But I'm back looking at 6502s again.

> I agree that position-independent code has advantages, and that a
> register-poor chip like the 6502 is handicapped in this regard.

I would have to say however that what it lacks in registers, it more than makes up for in its low clocks-per-instruction count and in the fact that the entire zero page is, in a way, like 256 processor registers. These come into play when we see how favorably the 6502's performance compares to that of something like the Z80 which had a lot more registers, and 16-bit to boot!. (See my post, the 9th post under "6502.org Forum Index" --> "Programming" --> "please help me!")

> Any of you worked with CDP1802s? Early CMOS uPs from RCA.

I have a friend who did his BSEE senior project in 1982 with an 1802. Advantages for his project included low current (since it was CMOS when few processors were), and with all the on-board registers, he didn't need external RAM.

However, referring to some books here, I was amused to find that the 1802 took 24 and 36 clocks to carry out many of its instructions, and some were even more. The interrupt sequence was 72 clocks!!! The entire interrupt latency could easily be over 100 clocks by the time you include the time to finish an already started instruction. It appears that it was about 1/10th as fast as the 6502 at a given clock speed, and its max clock speed at 5V was 2.5MHz, which was less than 6502's were doing back then.

Yeah, I should have added "it was a dog."

Still, not too many other micros running out there past Neptune!