{"id":141,"date":"2006-11-09T00:08:00","date_gmt":"2006-11-09T08:08:00","guid":{"rendered":"http:\/\/www.mccambridge.org\/blog\/2006\/11\/huzzah-functional-branching\/"},"modified":"2022-09-11T00:40:45","modified_gmt":"2022-09-11T00:40:45","slug":"huzzah-functional-branching","status":"publish","type":"post","link":"http:\/\/www.mccambridge.org\/blog\/2006\/11\/huzzah-functional-branching\/","title":{"rendered":"Huzzah! Functional Branching!"},"content":{"rendered":"
Dave and I spent all of one late night implementing the first generation (unpipelined) of our 552 project, a 16-bit MIPS processor in Verilog, and then we spent a couple hours this afternoon debugging it. Around 5:15 we ran into a snag:<\/p>\n
The assembler we were provided was for a slightly different instruction set architecture than the one we were required to implement. Specifically, in that other ISA, PC-relative branch offsets assumed a least-significant bit of This is a problem, because Our<\/em> ISA<\/a> is byte-addressable, and says the PC calculation should be <\/code> Those of you familiar with computer architecture will recognize this as a severe problem: The assembler is generating offsets to odd byte addresses, due to the off-by-one-bit error, while all of our instructions are word-aligned.<\/p>\n On the upshot, I was able to hack around this in the assembler source and get a working version. Plug in the new binary, fix a minor bug in the parameterization of our sign extender and voila:<\/p>\n <\/a><\/p>\n This is the (admittedly meaningless out of context) output of running the branchTest test program<\/a> (assembled by my modified assembler).<\/p>\n0<\/code> and thus didn’t waste a bit in the instruction for that zero. As a result, the next PC calculation (for that ISA) would be
PC < - PC + 2 + (sign ext. Immed. << 1)<\/code>.<\/p>\n
PC < - PC + 2 + sign ext. Immed.<\/code> (See beqz instruction for an example.)<\/p>\n