Program Counter strangeness

[Ty]

Hi,
I may have the wrong idea about this but it seems like there is a bug in this architecture.  The PC we created is built for 16bit incrementing; however, the A instruction can only support a 15bit address because the 15th bit is a flag defining whether the instruction is an A instruction (bit 15 == 0) or a C instruction (bit 15 == 1).

So when the counter gets to 0x7FFF it will increment to 0x8000 and be running code that cannot be addressed by the A register.  Is this correct or do I have some fundamental misunderstanding?

[WBahn]

It is not a bug; this is a limitation of all architectures. You only have so much memory. What happens when you increment beyond that? In most architectures, you wrap back around to the start of the memory space. Some architectures have deliberately exploited this behavior, but usually it is a bad thing. Some architectures detect this occurrence and take some kind of action (what type of action varies).

[Ty]

Thanks for the reply.  I get it.  It just doesn't seem to all fit together nicely.  The RAM16K chip supports a 14bit address, the PC increments up to 16bit and the instructions support 15bit addresses.  However, it probably would have been much harder for students to create a 15bit PC and a 15bit RAM.

[WBahn]

Ty wrote

Thanks for the reply.  I get it.  It just doesn't seem to all fit together nicely.  The RAM16K chip supports a 14bit address, the PC increments up to 16bit and the instructions support 15bit addresses.  However, it probably would have been much harder for students to create a 15bit PC and a 15bit RAM.

Don't confuse the RAM with the ROM.

The program you are running is loaded into a 32 kword ROM, it is NOT loaded into RAM.

The Program Counter's output is the address value for the ROM, not the RAM. The address for the RAM always comes from the A-register (while the address for the ROM always comes from the program counter).

[Ty]

oh yes; absolutely.  I think I was confusing that.  thanks again.