Last visit was: Sat Jul 13, 2024 10:04 am
It is currently Sat Jul 13, 2024 10:04 am

 [ 9 posts ] 
 Is there any value in having the program counter accessible? 
Author Message

Joined: Sat Jun 16, 2018 2:51 am
Posts: 50
If the following instructions are provided, is there a need for having the program counter register be accessible to the user/programmer?

  • "jump to subroutine" (JSR) - saves the return address to a hidden link register
  • "return from subroutine" (RTS) - jumps to the address in the link register
  • "get link register" (GLK) - copies the link register value to the register specified
  • "set link register" (SLK) - copies the value from the register specified to the link register

Are there any cases where having direct read and/or write access to the PC register is not catered to by the above instructions?

The only scenario I could think off was that of nested calls. Hence the GLK and SLK instructions that should (I think) allow the called subroutine to push the link register value to a stack before making a call itself and overwriting the link register (return address).

Disclaimer: I don't program a lot in assembly (in fact I've only dabbled with assembly in my attempt to build a CPU) so I am not sure what exactly is useful.

Thu Jan 24, 2019 1:53 am

Joined: Sat Jun 16, 2018 2:51 am
Posts: 50
I just remembered the OPC1 specification, which has just one register (the accumulator) and the three instructions for saving and restoring the PC (JSR, RTS, LXA). So, it seems the answer is no, the PC can be hidden from the user.

Thu Jan 24, 2019 2:15 am

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
And don't forget interrupts' saving and restoring of the PC.

My only experience with a processor that lets you access the PC directly was with the PIC16; but wow, what a mickeymouse system that is! I've brought a lot of products to market with it though since I got started with it in 1996 and made a lot of macros that hide a lot of the ugly details. Still, it's hard to hide the ugly details of, for example, indexing into tables that might be in a different section of memory, which involves writing to the PC.

The other processors I have a lot of experience with are the 65c02 and 65816 which don't give direct access to the PC, nevertheless work much better. The '02 has JSR, RTS, JMP (including indirect, and indexed indirect), RTI, and relative branches; and the '816 adds BRL (branch relative long), JML (jump long, including indirect), JSL (jump to subroutine, long), RTL (return from subroutine, long), TCD and TDC (transfer 16-bit accumulator to direct-page register, and vice-versa), PEA (push effective absolute address), PEI (push effective indirect address), PHB and PLB (push and pull data bank register), PHD and PLD (push and pull direct-page register), PHK (push program-bank register), and PER (push effective relative address). I suppose you could say that none of these give the programmer direct access to the PC; yet they give you what you need to do most anything you could want.

_________________ lots of 6502 resources

Thu Jan 24, 2019 3:07 am WWW

Joined: Sat Jun 16, 2018 2:51 am
Posts: 50
Thanks for the insight! Wiring the PC to be user accessible was proving to be a hassle, so this is good to hear!

Thu Jan 24, 2019 8:22 am

Joined: Tue Jan 15, 2013 10:11 am
Posts: 114
Location: Norway/Japan
The 16-bit Norsk Data computers gave you access to the program counter. They had a link register too. The program counter 'P' register was described as follows:
"P register: Program counter, address of current instruction. The register is controlled automatically in the normal sequencing or branching mode. But it is also fully program controlled and its contents may be transferred to or from other registers."
The 'return from subroutine' instruction was called 'EXIT', but it was in practice just an assembler alias for the 'COPY SL DP' instruction variant (copy from link register to program register - source L, destination P). COPY could copy between any two general registers.

Thu Jan 24, 2019 9:19 am

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
One of the most beloved minis, the pdp-11, had the instruction pointer as a "regular" pointer register. It allowed some really cool behind-the-scenes functionality when combined with the full-featured addressing modes, but was no doubt a barrier to higher execution performance.

Mike B.

Thu Jan 24, 2019 4:24 pm

Joined: Sat Jun 16, 2018 2:51 am
Posts: 50
I've never heard of Norsk Data, will look them up! I keep hearing a lot of good things about the PDP-11, it's definitely on my architectures to study list.

Fri Jan 25, 2019 3:43 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1789
One thing to watch out for if PC is accessible: it exposes something about the pipelining of the machine. I think ARM had a compatibility break when they first changed the pipelining, because programs were assuming which value of PC would be read.

For interrupts, other than the familiar solution of stacking the PC, the PC can be saved to a constant location (and the ISR then deals with putting it somewhere safe if need be) or it can be saved in a shadow register, or (equivalently?) a different PC for the interrupt context can be switched in.

Fri Jan 25, 2019 9:49 am

Joined: Wed Jan 02, 2019 4:10 pm
Posts: 14
A really good example of an ISA with the PC *not* in a general-purpose register is PowerPC. This can be thought of as four relatively loosely-coupled modules:

1: Load-Store Unit, responsible for all data memory accesses and containing the L1 D-cache.

2: Fixed-point Unit, containing a 32-entry integer register file (each 32 or 64 bits) and the ALU pipelines. These registers are used for address computation as well.

3: Floating-point Unit, containing a 32-entry floating-point register file (each 64 bits) and the FPU pipelines.

4: Branch Unit, containing the PC, the Link Register, the Count Register, an 8-entry condition-code register file (each 4 bits), the instruction decoder, the branch prediction unit, responsible for instruction fetches and processing all branches. Conceptually, it is the BU which dispatches instructions to the other functional units.

Originally, the RS/6000 CPU which eventually became PowerPC was physically divided into multiple chips, each containing one of these modules. Sending data from one unit to another was noticeably slower than processing it internally. As it happens, that design is still relevant in a single-chip design, when very high performance is wanted. In particular, the relative independence of the Branch Unit reduces the number of branches that need to be predicted, rather than simply executed with ready information; loops are commonly constructed by loading the Count Register and then using "Decrement and Branch if Not Zero" (DBNZ). Predicted branches are those relying on data that's still working its way through one of the other execution pipelines and hasn't yet been uploaded to the Count Register or one of the Condition Registers - or, for a non-leaf return, to the Link Register.

The equivalent of JSR is "Branch and Link", where the incremented old PC is stored in the Link Register. The Link Register can then be transferred to the FXU (MFLR instruction), and from there to the stack in RAM if need be. The equivalent of RTS is "Branch to Link Register". Indirect jumps can be made from the Link or Count register, and there is a "Branch to Count Register and Link" (BCTRL) for handling virtual function calls (common in C++). The PC is literally unreachable by normal means, which complicates writing position-independent code - it is necessary to perform a relative Branch and Link to the following instruction to determine its value without altering program flow. Some of the newer CPUs specially recognise this idiom and optimise for it, as otherwise it would confuse a return stack branch predictor.

Sat Feb 09, 2019 7:59 pm
 [ 9 posts ] 

Who is online

Users browsing this forum: CCBot and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software