An easy mod to the CPU

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

An easy mod to the CPU

cadet1620
Administrator
The human brain is amazing -- this idea occurred to me out of the blue in the middle of a bike ride today.

One of the things that's a bit inconvenient with the A-instruction is that it cannot handle negative numbers. It's only possible to load -1 directly into the A register by using the C-instruction A=-1.

Since the book specifies that the upper three bits of C-instructions must be 1, other instructions can be added, as has been talked about in other form posts. I propose here the addition of an "N-instruction" which loads a negative number into the A register.

The format of an N-instruction will be 10nn nnnn nnnn nnnn. It will load the value 11nn nnnn nnnn nnnn into the A register. The N-instruction will be able to load negative numbers 1111 1111 1111 1111 (-1) through 1100 0000 0000 0000 (-16384) into the A register.

If you are only using inst[15] to enable the C-instruction control bits, you will need to And inst[14..15] and to get a 'cInst' signal to use. (By the spec in the book, you should already be Anding inst[13..15], but most people don't.)

Make an 'nInst" signal from inst[14..15] then all you need to do is Or 'nInst' into the ARegister.load control signal and use 'nInst to force ARegister.in[14..15] to 1.

In my CPU which already decodes inst[13..15] == 111 for 'cInst' I think that this will only require:
  o  add a Not and an And to make 'nInst',
  o  change an Or to an Or8Way to add 'nInst' to ARegister.load,
  o  add an Or16 to force ARegister.in[14..15] to 1.

--Mark





Reply | Threaded
Open this post in threaded view
|

Re: An easy mod to the CPU

ybakos
Definitely a sane approach. What about the assembly mnemonic?

I feel like this opens up classroom-worthy discussions about design: the tradeoff of having another instruction type just for negative numbers, while A's do everything else including -1, etc.

Reply | Threaded
Open this post in threaded view
|

Re: An easy mod to the CPU

cadet1620
Administrator
ybakos wrote
Definitely a sane approach. What about the assembly mnemonic?

I feel like this opens up classroom-worthy discussions about design: the tradeoff of having another instruction type just for negative numbers, while A's do everything else including -1, etc.
I figured that I'd just extend legal values for the '@' mnemonic to the range [-16384, 32767].

Alternatively, to add to the class discussion, for values in the range [-32768, -16385] the assembler could automagically generate the two instruction sequence @nnn A=~A where nnn is the appropriate positive number. (Consider: why can't you use A=-A?)

This brings up how to handle SYMBOLS that might have negative values. How do you handle the issue that you don't know how long @SYMBOL will be during pass 1?

As another thought, this automatic injection of nots could be added to the generic Hack assembler which would allow the ROM size to be doubled.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: An easy mod to the CPU

emekler0729
Mark,

What advantages do you envision gaining from allowing direct writing of negative numbers to the A register?

I was thinking about how I would use the extra 2 C-Instruction bits in context of extending the Nand2Tetris FPGA project that I've been working on.

First, I only used instruction(15) to indicate a C-instruction, so bits 14 and 13 have been "don't care" bits.

My thoughts on extending them was to add a "page" register to the hardware that is written to using bit instruction(14).

This would allow 10vv vvvv vvvv vvvv commands to set the memory page to be addressed. The hack architecture could then address 512 MB of memory or 16,384 32KB segments.

My next thought was to use the instruction(13) as an extended instruction bit where any values in the 110x xxxx xxxx xxxx range could be used to extend the instruction set. My idea was that this extended range could be used to interface with additional physical peripherals such disc write/read, network write/read, etc.

One of these extended instructions could be used to set the A(15) bit to 1 for negative values.

My next goal after finishing the existing Hack development scope in FPGA is to take a deep dive into OS development. I would like to use the extended functionality that I suggested to be able to develop mroe full featured OS for Hack that deals with memory management, page swapping, etc.

Best Regards,

Eduard
Reply | Threaded
Open this post in threaded view
|

Re: An easy mod to the CPU

cadet1620
Administrator
emekler0729 wrote
What advantages do you envision gaining from allowing direct writing of negative numbers to the A register?
The advantage of being able to load negative numbers (albeit range limited) directly into A is simply that it saves one instruction (A=-A) whenever that functionality is needed.  The most common construction where negative constants are used are in comparisons to positive numbers, as in "if (x<10) ...". One can of course swap the subtraction arguments and use the complementary conditions jump.

This was proposed mostly as an intellectual exorcise. It is a bad trade off to waste so many of the instruction decode bits for such a rare need.
I was thinking about how I would use the extra 2 C-Instruction bits in context of extending the Nand2Tetris FPGA project that I've been working on.

First, I only used instruction(15) to indicate a C-instruction, so bits 14 and 13 have been "don't care" bits.

My thoughts on extending them was to add a "page" register to the hardware that is written to using bit instruction(14).

This would allow 10vv vvvv vvvv vvvv commands to set the memory page to be addressed. The hack architecture could then address 512 MB of memory or 16,384 32KB segments.

My next thought was to use the instruction(13) as an extended instruction bit where any values in the 110x xxxx xxxx xxxx range could be used to extend the instruction set. My idea was that this extended range could be used to interface with additional physical peripherals such disc write/read, network write/read, etc.

One of these extended instructions could be used to set the A(15) bit to 1 for negative values.
I see bits 13-15 as selecting instruction groups. Groups 0-3 must be dedicated to A-instructions, and group 7 is dedicated to existing C-instructions.

The biggest holes I've found in the architecture are
  o  right shift — It takes an amazing number of instructions to do a one-bit right shift. A shift/rotate instruction group would be very useful.
  o  ALU carry status and CPU status latches  — Multiple precision add and subtract are quite tricky since there is no carry status.
  o  XOR  —This is another operation that requires a large number of instructions.
  o  Register bottleneck  — Pointer-based memory-to-memory operations are tough.

Memory limitations, both RAM and ROM, are inherent in the 16-bit architecture. Your extended address instruction is a natural way to extend RAM and ROM. Rather than bank switching, I'd describe it as address extension. The instruction sets the AX register and all memory addresses, including jump targets, are AX:X[0,14].

An instruction similar to Set AX could be added to set register numbers for source and destination An and Dn registers. A set of 4 A and D registers could be handled with 8 bits of space in an instruction sub-group. Should these be "sticky" selects or reset to 0 after each following instruction? One would probably need to write some code to see which mode works better.  

I'd continue to use memory mapped I/O.  Instruction based I/O locks you into specific devices and limits you ability to add more features to the devices.
My next goal after finishing the existing Hack development scope in FPGA is to take a deep dive into OS development. I would like to use the extended functionality that I suggested to be able to develop mroe full featured OS for Hack that deals with memory management, page swapping, etc.
One of the things I really like about this course it that it encourages thinking about issues like this.

--Mark