16bit to 32bit

[hbit93]

The hack archichecture is a 16-bit computer. What are the potential changes would be required to the hack architecture to develop it into 32-bit architecture?

[WBahn]

This sounds like a homework question. Is it?

In either case, what do YOU think would be involved? Take your best shot and we'll go from there.

[MrHacker]

I have the same question, and personally I think it wouldn't be too complicated, since we already have 16 bit components, we just need to use two of each to make the 32 bit versions.

What I don't fully understand is if we have to give them two 16 bit inputs or just one 32 input. Does anyone know the right answer to this?

[WBahn]

In principle you could do it either way. But I'm not sure that the present tools will work with a 32-bit signals. Someone posted a while back that they don't. I haven't verified that.

[rleininger]

I believe this is a bit more complicated than simply enlarging the width of the datapath; that is, the operands and output of the ALU to 32-bits.  There is a question of what to do about data memory.  It could be altered to implement 32-bit addressable words and make the data bus 32-bits wide.  This approach seems reasonably straight-forward since in the Hack computer, the instruction bus is completely separate from the data bus (Harvard architecture) and could remain 16-bit if desired.

There is a difficulty with this approach since the data Memory "chip" created in the final build of the Hack computer utilizes several "built-in" 16-bit chips. so you would probably have to go to the underlying Java code to make the change to 32-bit.  There would probably also need to be changes made to the screen and keyboard I/O internal routines to accommodate the change to 32-bit words and the accompanying bus.

Another approach commonly used in many commercial byte-addressable microprocessors would be to leave the memory alone and handle 32-bit ALU operations in 16-bit chunks.  I think this would be more complicated, but I have not really thought much about it.  This would seem to move the Hack CPU into the CISC realm and would not be in keeping with its KISS design philosophy.

I don't think this is a simple exercise at all.

[pm100]

need to distinguish 32 bit memory address space vs 32 bit data size.

In the same way that a transition from 32 bit to 64 bit addressing did not involve changing most c ints from 32 to 64 bit. In fact not all vendors agree on what integers should be 32 and what should be 64 bit , gcc has long at 64, msvc has it at 32.

The challenge is how big should the a register be. If its 32 bit then the instruction size is now 32 bit. Fine but what do we do with the extra 16 bit on the C instruction? We could add shift and rototate (please). And we could add byte addressing please please. Not being able to address individual bytes makes writing a c compiler for HACK almost impossible

The alternate way to get more memory in there is bank switching

[NotRandom]

I've tried this with FPGA, but abandoned the idea. The surprisingly powerful computer would burn out the chip at higher than 16 bits. At 32 bits it would be possible with heat sinks and fans, and at 64 bit it would pretty much just light on fire, a magical puff of smoke.

[WBahn]

NotRandom wrote

I've tried this with FPGA, but abandoned the idea. The surprisingly powerful computer would burn out the chip at higher than 16 bits. At 32 bits it would be possible with heat sinks and fans, and at 64 bit it would pretty much just light on fire, a magical puff of smoke.

This doesn't make a lot of since. If nothing else, you can manage the heat by slowing the clock rate. But the number of gates in even a 64-bit version should be small compared to the capacity of most modern FPGAs. I implemented a full 32-bit MIPS architecture in a modest FPGA (one of the Xilinx Spartan family, if memory serves) some dozen years ago and it barely got warm.

If you are getting really hot parts, you might need to look for other causes. At one time, FPGAs were notorious for experience latch-up if you had a poor configuration file. I don't know if that's been fully addressed or not (I've been out of that game for some time).

[pm100]

Number of bits makes no difference to heat. Heat comes from speed mainly. What you will find is that the hack architecture needs to be slowed down as you increase the number of bits. The long carry chain that then chains to the a register and hence the ram get is the bottleneck. I had to run my first 16 but version at 25mhz having originally tried at 100, was my first exposure to fpga timing issues. 32 bits would almost double that chain so the clock would have to go down

[NotRandom]

Right. I imagine that it could be implemented differently and it would work. Keeping the same instruction set, designing a different ALU...

[WBahn]

pm100 wrote

Number of bits makes no difference to heat. Heat comes from speed mainly. What you will find is that the hack architecture needs to be slowed down as you increase the number of bits. The long carry chain that then chains to the a register and hence the ram get is the bottleneck. I had to run my first 16 but version at 25mhz having originally tried at 100, was my first exposure to fpga timing issues. 32 bits would almost double that chain so the clock would have to go down

Bit does make a difference in heat, because the heat in CMOS is primarily due to charging and discharging gate capacitances, so it is proportional both to the frequency at which gates switch and to the number of gates that are switching.