0

I know that the program counter will always point to the memory location of the next instruction, however at the end of the program, what would be the value of the program counter?

Would the value be the same as the last instruction that was run in the program?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
William
  • 1
  • 1
    You wouldn't have any way of observing it. The answer is moot. (It also will depend on the hardware and the OS / context in which you are running the "program", and how "ending the program" is implemented.) – Stephen C Feb 02 '23 at 00:55
  • Unless the program halts the processor, which most programs don't and can't, "end of program" is a vague concept. There will be the PC value of the last-run instruction of your compiled program, then there will be a "next instruction" that's part of the runtime environment. You could choose to call that "the end." If you get the runtime's code, you can identify it. Many environments compile your code into a function, so the last instruction "owned" by it is a return. The next instruction would be the one following the runtime's call. – Gene Feb 02 '23 at 01:31
  • Programs that run on operating systems stop by invoking some kind of system call. Thus, the last program counter would refer to the syscall instruction (or any other instruction that causes the program to halt, e.g. by seg fault). – Erik Eidt Feb 02 '23 at 01:39
  • 1
    @Gene: If you're talking about things like C `main` being a function, the end of `main` isn't the end of the whole process, the running instance of a program created by the toolchain from your `main`. The code that called `main` also runs in user-space in most OSes, often in a shared library. (Which in turn may have been called by code in `crt0.o` or whatever that was linked into your process.) In that sense, your process isn't over until it makes an exit system call, or until kernel has run instructions that tear down the kernel data structures for the process. – Peter Cordes Feb 02 '23 at 02:28
  • 1
    C doesn't have a program counter; that's a feature of the asm created by the toolchain ("C implementation") for the target system. So IMO that's the relevant level to look on. In abstract language terms, sure, your C program is over once `main` returns (or you call `exit()`) and then the last function registered with `atexit` has returned. Or in POSIX if you call `_exit()` or abort or whatever, or `raise(SIGKILL)`. But again, that's abstract C, not assembly where there's a program counter. – Peter Cordes Feb 02 '23 at 02:31
  • @PeterCordes Right. Know all that. We are in violent agreement. He didn't say "process," but program. As I said it's a vague concept. I interpreted "end of program" to be the last instruction of the _user's_ program and the enclosing runtime that sets up and tears down something else. The exception of course is programs running on bare metal. The fraction in that category is very small. Even if you call _exit(), I'd expect a shim that's not part of the user's program, so at eop, the PC points to the shim, which is also part of the runtime. Of course that's implementation dependent. – Gene Feb 03 '23 at 03:03

1 Answers1

2

It depends on what you mean by "end". In a multitasking system the program, as far as the CPU is concerned, is probably still going, having moved on to whatever the next task is. In this particular case, the PC will contain the address which the routines have loaded into it to move onto the next task.

If you are talking about the giant program which is the OS, or whatever single program you might be running on a small chip like an ATMEL, it will likely contain an address somewhere in memory which happened to be one containing a HALT instruction. Depending on the chip, it might then power off, or just hang, doing nothing until an external signal resets the chip, whereupon it'll contain whatever value the chip defaults to on startup.

Hack Saw
  • 2,741
  • 1
  • 18
  • 33
  • 1
    On bare metal, when there's no OS to return to, a program can't truly "end" except by powering off the machine. An infinite loop, perhaps containing a power-saving instruction like `halt` (sleep until next interrupt) is common in toy programs to be run in emulators. Otherwise yeah, under an OS, an `exit` system call will result in the program counter pointing into some OS code. – Peter Cordes Feb 02 '23 at 01:13
  • 2
    All good, but it's not a multi-tasking thing. MSDOS, CP/M, and Apple DOS all eventually end up in busy wait loops when the user isn't running a program. The processor can't halt. There are interrupts to handle. – Gene Feb 02 '23 at 01:43
  • Thank you for your help. This was just an assignment question and it was just a five line program, so that's why I was confused as to where the pc would point to. – William Feb 02 '23 at 02:49
  • five line program and if the last instruction is an infinite loop branch/jump then the pc will point at the next instruction then when the branch executes it will point back at itself, forever. If the whole or part of the five lines is a loop then there is no end it just loops forever. – old_timer Feb 02 '23 at 07:54
  • 2
    Ever played an old video game where all user input was disabled at the "The End" screen and you had to reset the console? That was most likely implemented with an infinite loop (usually a label with a branch to that label directly underneath.) Even so, there's a good chance there were still hardware interrupts for screen redraw going on. – puppydrum64 Feb 02 '23 at 10:56
  • It occurs to me that in the simplest of situations, where the five line program is sitting starting at 0x0000, and the rest of the memory beyond the program is all zeros, the PC will be incremented forever, because on many system 0x0000 is NoOp. When it hits the end of RAM, if RAM equals the full addressable space in a flat memory system, it'd just wrap around and run the program again, since increment an unsigned Int automatically turns it to 0x0 again. Of course, if the memory didn't match, it'd fall off the end of the world, and prolly crash at that point. – Hack Saw Feb 02 '23 at 15:59
  • 1
    @HackSaw, yes, that could happen. Also, could get a seg fault before wrapping if some portion of instruction memory is invalid for the program. – Erik Eidt Feb 02 '23 at 17:10