It is a good result: that's a good CPI you're getting. I see the great majority of your instructions are single byte, not needing a prefix or nfix, so that's a good statement about the encoding. If your instruction count ends up on the high side, I suppose that's a statement about the expressiveness of the instruction set.

Revaldinho and Hoglet have been exploring Fibonacci programs with similar structure, to see what we can learn about the different architectures and different microarchitectures: we have the vanilla OPC5 with 8 instructions, the load-store variant with 16 instructions, and a more clock-cycle efficient flavour of the 8 instruction variant which uses more slices. And of course we're making a few coding errors and learning a few coding tricks at the same time.

You can see our sources here:
https://github.com/revaldinho/opc/blob/ ... 5/robfib.s
https://github.com/revaldinho/opc/blob/ ... s/robfib.s

The results, as a snapshot, looked like this:



The "slightly different approach" here is hoglet's idea, to check for termination using the main addition, instead of a separate comparison, and also to unroll the loop a bit which allows better register use by ping-ponging between two:


I think it's interesting that we're exploring freedoms in
- instruction set architecture (more powerful opcodes)
- microarchitecture (pipelining, removal of dead cycles)
- coding optimisations (choosing best instruction sequences)
- algorithm (different loop termination strategies)

Coming next, I think, is an xp version of the ls machine, because the 16 instruction variation does seem to be a win, and the xp microarchitecture is not too costly in slice count. Also we've added a sign bit flag and two corresponding predicates, which makes some things a little easier to code and faster to run.

Those are interesting results. I particularly like the way that you guys unrolled the loop, and used the predicated move instruction to terminate the loop at an odd number.

The transputer-inspired encoding has some benefits in the sense that the MiniCPU's 8-bit ALU (isn't the OPC5-series cheating a bit with an internal 16-bit ALU ) requires loading and unloading each half of the sum of the Fibonacci series recurrence equation. The encoding provides a very compact representation of the program in a very competitive total of 45 bytes, but the number of operations required is higher than the OPC5 and BFLY16 are achieving because of number of load/store operations required by its 8-bit ALU for a 16-bit operation. There is also an obvious architectural limitation: the indirect mechanism to access the right operand register, B. That architectural limitation reduces the MiniCPU's computational efficiency even for 8-bit operations. The compact instruction encoding makes it less noticeable, but it has an impact on the program I provided above.

I am particularly intrigued by the predicated instruction feature included in the OPC5. I don't do much low level programming work with the ARM, nor have I needed to examine the assembler output of its C compiler. Therefore, I was not really aware of the technique and its applicability until Rob Finch started including predicated instructions on one of his projects.

All that being said, can the c.mov PC, r5 instruction used above not be aliased as bcs PC, r5? In reality, I think all valid combinations of the predicates to the OPC5 move instruction should be counted as separate instructions; the special purpose terminal registers of the instruction may also need to be counted as distinct instructions.

You're right, on several counts! The OPC5s have an unfair advantage on the Fib task through being 16 bit machines. We're only arguably qualified for the 8 bit challenge, in that we expect finally to implement a shim to interface to an 8 bit memory system. Rather like the COSMAC, we're seeing what we can do within the implementation constraints, without fully embracing the architectural constraint.

And yes, the conditional moves to the PC could be aliased as branch instructions, and that would be convenient and an improvement. When we drop the one-page-source limitation on the assembler, no doubt we'll do it. Note though that other instructions can also be predicated, and that can be an advantage. At least, I think it can. (But I'm not sure I'd count these variations as separate instructions - they are more mnemonics for a programmer to learn, but still the machine is not made more complex. I'd still call it a 16 instruction machine.)

Where an 8-bit machine could shine, compared to a 16-bit machine, is in handling 8-bit data. The likes of string searches, for example. We don't have example code for that. We do now have a byte swap instruction and support in the assembler for packed strings. I expect it will be a bit messy to deal with packed strings, but a bit memory-inefficient to use non-packed strings.

Got a C-based simulator, one that does not include handling of Reset or Interrupts, going this weekend. Will update the github repository for the MiniCPU with this code in the next day or so. Found a couple of minor bugs in the code for emulating the BNC/BPL and LDL/LDN/LDY instructions which were easy to fix. The simulator successfully executes the fibonacci test program published above. That program does not use all of the instructions in the MiniCPU instruction set, but many of those instructions are single cycle ALU operations that can be easily verified.

Also over the weekend extended the ALU to 16-bits and modified the microprogram to support double reads and writes. In addition, added registers for all three flags not just the C flag, and added a registered V flag to support the single signed comparison, BGE, previously discussed. In the process of adjusting the fibonacci series test program for this 16-bit implementation of the MiniCPU to determine the cycle count. It should reduce the cycle count dramatically given all of the loading and unloading required to compute 16-bit extended precision numbers using an 8-bit ALU.

The ALU's architecture is not changing, so there's still the limitation that the B register, the right operand for any two operand ALU operations, must still be loaded through the A register, the left operand and destination of two operand ALU registers. Even by increasing the register and ALU operations from 8 to 16 bits, the slice count increases only marginally from 80-84 Spartan 6 slices to 105-107 Spartan 6 slices. That implies that there may be room to make the ALU a 3 register stack like the transputer with automatic pushing and popping of the registers. Additional instructions would be needed, however, to provide better access to the registers. Without the additional instructions, the slice count of a three 16-bit register stack version of the ALU is around 125-127 Spartan 6 slices. This means that this solution would be at the limit for the challenge, and although, it uses a 16-bit address bus and an 8-bit data bus, it would not have direct support for 8-bit data.

The lure of 16 bits! Interesting update, thanks.

How many fibbonaci numbers does it go up to?

The current test is for the first 25 Fibonacci numbers: 0, 1, 1, 2, 3, 5, 8, ....

How are you getting on with your CPU project Michael? In particular I'm interested to know what test programs or projects you might have managed to run. Are you still in the world of hand-assembly?

Thanks for the update. A self-checking testbench is a good idea. I'm not too surprised you haven't yet modelled interrupts. Presumably it would be relatively easy to add subroutine calls into the Fib program? It's true that we haven't yet written (and probably won't write) an actual instruction-testing suite for the OPC-5 which tries to exercise most of the common behaviour of the machine. But we do know from 6502 land that when Klaus Dormann did that, it very much helped several HDL cores and emulators.

What's with the huge font, Michael? Did you wind up with the same eye affliction that BDD had/has?

Mike B.

Mike:

I am having a bit of an issue with one eye, but it was mostly due to losing the video card for the laptop that I've used for the past 8-10 years. I am bringing up a new laptop with roughly twice the screen resolution. I was warned that the additional resolution might make it hard to see some pages, but I like the smoothness to the displayed text that the additional resolution provides. I've found that smooth edges reduces eye strain for me. So I generally use large display fonts for most editors such as MS Word, Ultra Edit, Xilinx ISE Editor, etc.

I normally zoom most pages, but when preparing the response to Ed's question, I just tried increasing the font size instead. In the response prep window, the increased font size was not as big as it appears after posting the response.

It does make it easy to read, but it does seem as if I was shouting the response back. Good thing I did not also use all caps.

I managed to convert my functioning 8-bit CPU model into a 16-bit CPU with an 8-bit bus. I've also added some code to make measurements of some performance parameters. Interestingly, 1000 loops to calculate 25 Fibonacci numbers using the 8-bit implementation produces the following results:

The same test using the 16-bit version of the CPU produces the following results:

These are interesting results that, in some ways, support the idea that processors like the 68008 and 8088 operated at a significant handicap because of their 8-bit data buses. The number of data memory access went up, which I attribute to fact that 16-bit CPU utilizes a 16-bit loop counter. Since the loop counter is really an 8-bit quantity, there are many unnecessary data memory read/write cycles to access a byte that has no information. Adding instructions to the 16-bit CPU to support 8-bit data operations would alleviate this inefficiency. I suspect that adding those instructions will blow out the processor's 128 slice limit. In RTL, the 16-bit CPU uses about 110 slices compared to the 80 slices of the 8-bit CPU.

In the final analysis, the 16-bit CPU with an 8-bit data bus does not appreciably improve the performance for the MiniCPU architecture. The improvement is only about 9% in total number of cycles, and 11 bytes of program length.

Interesting finding. You did get a gain, but not so much as you might like.

(I've posted an update on our adventures in another thread. We're still in the intersection of the one page challenge and the 128 slice challenge. We have now got a story for using 8 bit memory, which of course gives us a performance hit compared to the 16 bit story, and can run it in a real implementation. We have an interrupt too - will probably need to exceed the one page limit to add a second nestable interrupt.)

BigEd:

It was a bit disappointing. I had expected better performance due to the computation of the Fibonacci number in a single cycle. However, after tabulating the results, and giving it some additional thought, I realized I had not taken my analysis of the change far enough.

It does set the stage for additional explorations using pre-fetch queues and/or internal caches. I read your report in the OPC thread with interest this morning because your cache selections match the ones I was considering applying to the MiniCPU. I had concluded that adding cache to the core when running with internal memory probably would not improve performance too much unless the path from cache to the processor core increased the bus width to at least 16 bits. An external 8-bit data bus would provide a performance bottleneck that cache may alleviate somewhat, but your results indicate that, for even these simple processors, larger caches are needed to provide reasonable performance.