Very impressive - nice work!
It looks like you can now cope with the working set not fitting within registers - how did you approach register allocation / spillage?

Thank you Robinson ! About the register allocation:

The workspace holds max 16 locals in RAM. At a function call, the workspace pointer WP is incremented by 32, so now the called function
has 16 fresh local variables (but for leaf functions the locals are in zpage, this saves the instructions needed to change WP).
There are 8 registers (4 data and 4 address). PC (A0) and WP(A1) are address registers, and one register is needed for the return address, this leaves 5 registers for parameter passing. So the max nr of parameters is 5. This could be extended by having another parameter pass convention for parameter 6 and higher, for instance they could be directly placed into the next workspace).

Calculations normally are done in register D3. This is also the register for function results and for the first parameter of a function call. Within the code generator, there is a function that returns a new register to use (and reserves it), but it is currently only used one level deep. Address calculations are mostly done in D2 and A2.

For expressions, the code generator will first generate code for the deepest branch of the expression. This minimizes the number of intermediate results. But if intermediate results must be stored, this is generally done in the workspace.

The code generator does several other optimizations that will be described later.

There are no compare instructions in the Kobold instruction set, a subtract must be used (that is an add with the 2's complement). So the register that is compared will be changed after the instruction. But there are also ADD instructions that deliver the result in an address register, like:

MOVC (var),D3 ; variable to D3 and complement it
ADDI 45,D3,A3 ; add and increment. Comparison result comes in carry.

This can used for compare. The D3 value is not changed, and the result in A3 is simply ignored.

You can have a look at the code generator here: http://www.enscope.nl/simas_kobold2/generator.js

Nice - can confirm, 3 is prime, and 9 isn't. (You might find that a fast-forward function will help a lot - allow for multiple steps between GUI updates. Ken's calculator simulator runs a few hundred(?) steps at normal speed and then speeds up. Visualy6502 takes a parameter to adjust the fast-forward button's step length.)

Hi all, I did a benchmark test to check my C compiler in combination with my computer Kobold K2, against a few known systems.

You find my full test description here:
https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer/log/180963-how-fast-is-this-thing-anyway

Ran the Sieve of Eratosthenes: (tests mainly the speed of loops and writing to arrays). result: 3.3 sec

6502 - The 6.25 MHz Kobold K2 programmed sieve in C, is more than 10 times faster as a 2 MHz 6502 programmed in optimized assembler.

68000 - The 6.25 MHz Kobold K2 programmed sieve in C, beats all C, Ada and Pascal compilers (available in 1983) targeting an 8 MHz 68000 !

8086 - The 6.25 MHz Kobold K2 programmed sieve in C, beats all C compilers targeting a 10 MHz 8086 !

Ran the recursive Fibonacci algorithm: (tests mainly the speed of recursive function calls and returns) result: 5 sec

8086 - The 6.25 MHz Kobold K2, programmed Fibonacci in C, beats all C compilers targeting a 10 MHz 8086 with a factor 3 or more !

The source code of the C compiler and editor/assembler/simulator can be found here:

https://hackaday.io/project/167605/files

And the short description here:

https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer/log/182395-c-compiler-assembler-simulator-source-code

Perhaps some of you dare to look at it. I would not be surprised when you see a resemblance to a certain Italian food...

Hi,

At the risk of straying OT but always looking for something to compare my own system to, I gave this a go...

Firstly my system is a BCPL program compiled into a 32-bit VM/bytecode interpreter running on a 16Mhz, 16-bit CPU (65c816) with an 8-bit data bus, so it's never going to be optimal, however, assuming my interpretation (and translation) of the code is correct and you're doing 10 iterations of the inner loop, then I get 13.014 seconds. Not as fast as your C version but I'm pleasantly surprised it's on-par with the AVR at the same clock speed.




Cheers,

-Gordon

My bengol compiler accepts a simple version of c with some code changes for porting purposes.
I get about 10 seconds. on my 20 bit 1.33 us core memory computer. 1899 primes.
Looking at the byte benchmarks, very few tests have same speed and bus width.
4 Mhz z80/IBM pc about the speed.
Ben.

Ok, although I'm a bit late to join, I also accepted the challenge and tried with my CPU74 architecture and compiler

This is the test C code


Resulting assembly code:

[CPU74 assembly]


As you can see the compiler is clever enough to figure out that the initialisation loop can be replaced by a convenient call to memset. As a matter of info, this is my implementation of memset. It's optimised for the word size of the processor (16 bits) but not even programmed in assembler:

[memset function]


And now the results on the CPU74 simulator, that I must recall that it is cycle accurate.

[Simulation results]


Well, I guess this beats them all by an astronomic margin !!

As a continuation of my previous post, I also accepted the Fibonacy challenge, and this is what I got for my CPU74 architecture:

[Source code]



Of course, I had to place the 'main' and 'fib' funcitons in separate files to prevent the compiler optimizing away the entire loop altogether. If both functions are placed on the same file, only one single call is perfomed to 'fib' from, regardless of the loop variable. By compiling these functions separately, the compiler does not have a clue about what possible side effects the fib function may have, so it will call it 10 times as per the source code. I have to do that to show a more comparable result.

So this is the compiled code:

[CPU74]



Now, the results are the following:



It's still significantly faster than anything else, and by a very long extend!. According to Roelth posted figures on the 10 MHz 8086, the CPU74 at just 8 MHz, is 10 times faster than the 10 MHz 8086. Even at only 1 MHz, the CPU74 is able to beat the 10MHz 8086 for all the tested compilers. That's a very impressive result, much better than I had ever imagined.

To be fair, I think to compare to a 68000 would be a better choice.
The intel cpu's have to acess variables from memory, so it is slower.
Ben.

I tried the fib test too, but was too embarrassed to post the results... [1]

The cintcode VM that the BCPL compiler produces is a bytecode for a load/store architecture which has a 2-deep register stack so almost every single operation is from memory to register or register to memory. Running the 32-bit VM on a 16-bit CPU with an 8-bit data bus is somewhat sub-optimal...

-Gordon

[1] ok, here it is:

So 37 seconds to do 10 iterations of this calculation.

The BCPL code is:

And the bytecode (which I commented) looks like:

I think the compiler is doing a good job of the code generation - the bytecode VM is more or less the "ideal" machine for this, but interpreting it on an 65816 is the crux here. If only I had a 32-bit CPU that could do the B := A operation internally in a single cycle for example... currently with 2 x 65816 LDA/STA instructions in 16-bit mode it takes 20 machine cycles (Which is a reason I'm lurking here, hello, and sorry for slightly hijacking the thread, I'm finding I like Retro-BCPL more than I like the 65816 so maybe one day I'll either find a CPU that's a better fit for this bytecode, or adapt some existing core, you never know!)

-G.

I strongly believe that the 68000 processor will rank no better than the 8080 for 16 bit data. The 68000 processor uses many cycles to do its thing, from 4 to even more than 20 in some instructions. It has the advantage of having more general purpose registers than the 8080, which may help to reduce some memory access overhead, but at the end of the day, my guess is that there's should be not that much difference (on algorithms performed with 16 bit arithmetic)

I think I have posted this elsewhere, but there's a lot of reasons why the CPU74 is so fas, here's a summaryt:

The CPU74 is designed as a Harward arquitecture, pure Load/store architecture, with enough registers to avoid a lot of memory accesses. Instruction fetching and initial decoding of the next instruction, happens simultaneously with the execution of the current instruction. Thanks to that:

- Most instructions are executed in 1 cycle.
- Data memory reads of writes, use 2 cycles.
- Unconditional jumps and conditional taken jumps use 2 cycles,
- and calls and returns take 3 cycles.

On the other hand, the instruction set is very optimised for compilers to take full advantage of it, with instructions such as:

- conditional moves and selects that help to avoid branching, and promote the insertion of speculative code
- careful selection of the instructions that depend on status register flags, which gives the compiler freedom to reorder instructions, while the status flags might be used one or two instructions later (This is something that, surprisingly, the original designers of CISC processors failed to understant. The VAX-11 for example, failed completely to get this right, however he 68000 instruction set does a much better job in this regard)

In summary, it's the combination of the Harvard architecture, the LLVM compiler, and the very compiler friendly instruction set that makes it so fast.

To me, the most interesting benchmark against my CPU74 architecture would be the original ARM-V1 from 1985, or even the ARM-V2 processor at comparable clock frequencies. This is a link to the description of the original architecture https://en.wikichip.org/wiki/acorn/microarchitectures/arm1. In effect, the CPU74 borrows a lot of the ideas of the ARM1, and they are architecturally very similar, except that the former is Harvard architecture with simultaneous fetching and execution (exactly 1 cycle per basic instruction), and the later is a 3 stage pipelined Von Newmann architecture (effectively only requiring 1 clock cycle for most sequential instructions).

Among the available processors before or up to 1985, I'm pretty sure that the only one that would beat the CPU74 is the ARM1 (at the same clock frequency). But as noted before, it would be really nice to have actual data with known algorithms to make the comparison. I would really like having that... Also it is interesting to note that the ARM2 processor was released in 1987 with a clock frequency of only 8 MHz, and I believe that should have been a beast compared with anything else available at the time of the same size. Still, I suspect that one possible issue of the original ARM1 at the time, was the availability of quality compilers that would really know how to squeeze the best of it.

Joan

[Edit:]
I just found this list of the Instructions per second data for different processors: https://en.wikipedia.org/wiki/Instructions_per_second As a mater of comparison the fibonacci test execution for the CPU74 resulted in 9096884 instructions executed in 13160704 cycles, so that's 0.6912 instructions per cycle in that particular case. This means that it would give 5.53 MIPS at 8MHz or 11,06 MIPS at 16 MHz, versus the average 4 MIPS of the ARM2 at 8 MHz. But of course the ARM is 32 bits, this is just raw instruction execution data, and for specific algorithm benchmarks the compiler and the instruction set have a strong influence.

I speeded up my cpu by having a faster clock. Looking at my CISC design I found
I could make more decoding don't cares and simplify to 2 logic levels to the rom
lookup tables. Rom tables are 20 x 256 bits. I can get a 420 ns alu cycle using ttl.
74ls and a few 74S for a 20 bit alu. That is the best I can design TTL to, on paper,
or FPGA emulation.
The next project may be a 24 bit register file cpu, if I find dual port memory.
Ben.

Time to bump the thread. I have a new ISA for my cpu. It runs at 5.3 Mhz ~ 1976. 16 bit bus, 32 bit ints.
I get ~ 15 seconds for the sive. Int size is 32 bits.

Probably the wrong thread - this one is called "Some C compilers"