Most ALU operations can optionally set the compare results register (flag register). Since a wide instruction encoding is in use there is a bit in the instruction to control this. It is important to have both kinds of instructions (flag setting and non-flag setting).

Loop mode is entered based on the comparison of the low order 32-bits of the branch target address and addresses in the pipeline. This was done to limit the size of comparators
used to detect a loop, reducing hardware. This means that a loop should not cross a 4GB boundary.

With a little fiddling of what is going on during states, the minimum CPI has been reduced to three when loop mode is active. This makes loop mode a whopping 40% faster than usual.

With adding loop mode and few other fixes, the size budget for the core has been blown.

Something is amiss in the FPGA version. It does not quite get the LEDs lighting. As can be seen from the logic analyzer it does startup. Burst loads the I$ and jumps to a subroutine at $400. Eventually it hangs.

Found a ‘C’ compiler test suite on the web and ran the test programs through the compiler. Needless to say, there were many, many errors that surfaced. A lot of errors due to things I had not planned on supporting, but I guess are now a part of the C standard. For instance, variable declarations in the middle of code. This is now supported. Previously vars had to be declared at the top of a function. The long-long type. Arbitrary statements within a switch statement. Nameless structures. And the list goes on. One can do a lot of nonsensical things in C that are legal for the compiler but are almost never seen in real code.

I fixed up the preprocessor as well. Previously it did not support variable arguments lists for macros and it now does. The basic pre-processor was written over 25 years ago when memory was much more limited. As a result, it croaked on some gigantic macro expansions in the test programs. It previously had a limit of something like 5,000 chars, I bumped it up to 100,000. There was a macro that expanded out to about 20,000 chars in the test program. IMHO this is ridiculous.

An example of what needs to be updated in the compiler. For the following code the compiler outputs three times the required storage because it sees x declared three times. One probably would not write code like this on purpose.

To fix it requires complicating the compiler to record the generated storage location and reuse it.
The compiler successfully error-lessly compiles about 2/3 of the test suite. There are about 220 "programs" in the test suite.

Well I for one am surprised that first line is valid.

Personally, I'd be happy with an old-fashioned C compiler - C89 might be the thing - but then of course I'd need a testsuite for that particular version. It might be interesting to try a modern compiler on the testsuite with a -std=c89 or -ansi, and only match the passes and fails that you get from that.

But good on you for tackling the testsuite as you find it.

Hi Rob,

Please can you provide the link to that 'C compiler suite", I would be interested to have a look at it.

Thanks

Will modern hardware, let you run that thing? I got bitten by windows,
when I lost a bunch of software , when I got forced to use a 64 Bit OS.
(mostly because the help files did not work)


Another question are the libraries thread safe? kernal memory locking work?
As the cpu gets fewer bugs,I suspect muilti-tasking will be next be debuging project.
Ben.

Here is the link
https://github.com/c-testsuite/c-testsuite

I believe it is C11 testing which is a bit newer.


I would be happy if it is easy to port real software, regardless of whether the compiler is 100% C compatible. I wanna play Doom on my own cpu. Most of the issues with compatibility would not be encountered with most software. The CC64 compiler already has several extensions like bit selects that are not a part of C.

The LEDs are now blinking and screen clears ! Running in the FPGA.
Now to update the software.

Running @57MHz with measured CPI of about 8.5. Its got to be at least 3-4 or more times faster than a 8MHz 68000.
Wondering if it will be able to run Doom.

I had a quick look: it looks like each test is tagged, so if you want to run the subset that's C89, or C99, you can. That's handy. (I also notice that clang passes all the tests, although other compilers have some fails, so that tells me that some non-trivial things are being tested.)

Well done! That's certainly a milestone.

It is always tiny steps that get things working.

The system works a tiny bit further now. Clears the screen and displays a single letter ‘A’ on-screen. It is supposed to display three ‘A’s. This is after a software fix in the assembler. The assembler was only outputting six of eight bytes for eight-byte instructions. The two high order bytes were always zero. This messed up some of the larger constants.

The delay routine had to be modified for 16x as long a delay. It was only counting to 300,000 that has been changed to 3,000,000 now. It completes in about 2 seconds. Completing the routine shows the processor can successfully call a routine and return from it. Some part of the stack memory must be working then along with call and ret instructions. This is working with pipeline operation mode; all the instructions for the loop fit in the pipe so there is no instruction fetches taking place.



Forgot to implement the MVSEG instruction in the processor.

The cause of the system hanging in the FPGA has been determined to be software. A number of subroutines did not get included in the build and that caused undefined addresses to be used, resulting in a hang.

Several software glitches have been corrected. For some reason when VS17 was uninstalled nmake which was being used to build the system no longer worked the same. nmake command were embedded in the makefiles themselves, and when run returned an ‘nmake not found’ error. This had worked previously. So, assuming some difference in the system I decided to spend some time looking at cmake again. After being unable to get cmake to build using a cross toolset, the nmake issue was examined more closely. It turns out that using $(MAKE) instead of the actual filename nmake in a makefile is better to do. Especially since it caused things to work again. The issue was outdated directory paths. A newer version of the VS was recently installed, outdating the directory paths setup in the makefiles.

Adding pipeline loop mode broke trace, or did it? Trace traces instructions from the IFETCH2 state which is never entered while in loop mode. I am not sure if this is a good or bad thing. It means not being able to trace through short loops, however that may be a desired behaviour. It is kind of pointless to validate every loop iteration if the loop is known to be working. Some loops contain thousand or millions of instructions. It is probably better if they are not fully traced. It is probably sufficient to know that the loop ran and terminated successfully. In any case skipping over loops after the first iteration is a feature at the moment.

Latest fixes: the call and jump instructions implemented only the low order 22 bits. The instruction format supports 30 bits. The return instruction RET implemented the stack adjustment incorrectly. This led to the RET working, but the next stack operation hung the processor at an invalid address. On flow control ops the pipeline was being NOPped out but the register file was still being updated. This was switched to a single valid bit for each pipeline stage which controls the register updates. Memory access was triggered when a call instruction was decoded even though the pipeline stage was invalid. This caused the pipeline to hang.

Scraped the dust off the ole PTI component. PTI standing for Parallel Transfer Interface, which is a parallel port style interface driven by the USB port of the FPGA board. I had not used it for a while because of lack of room in the FPGA. But it allows transferring information. With a little bit more room in the FPGA I am going to try and get it working. It should make software updates and debugging easier. The PTI transfers data in a streamed fashion using DMA.

I built a little utility making use of vendor’s API’s that can send data from the host workstation through the PTI interface. Previously the interface could not be made to work very well because it was too fast for PIO. But since the last try the interface has been rewritten to use DMA.

On the software side, source code linking does not seem to work very well, it is missing subroutines. This has got me thinking about implementing a real linker and librarian.

Latest fixes: flags results were not being calculated soon enough. This caused loops to loop one extra time. Bypassing did not check if values were being written to the register file. This caused false bypass operations to occur.

After noting that the signals advanced by the pipeline depend only on the pipeline advance signal and not on the state, the signal advancement was moved outside of the state case. This should save a logic gate or two for every signal and reduce the propagation delays.

Well, after updates to the core it now loops forever blinking LEDs instead of stopping after two seconds. It seems to work in simulation. An attempt will be made to run the system at a reduced clock rate to see if that helps.

Got the three 'A's to appear onscreen as expected.

Latest fixes: the Rs1 selection for the gcsub instruction had mixed up blocking versus non-blocking assigns due to a typo. This caused results forwarding to fail. Rs1 was not being set for the stack short forms of load and store instructions. This led to address zero being the target all the time.

Branch validation has moved from the m-stage to the e-stage one stage sooner. This reduces the number of wasted cycles for every mis-predicted branch.

Some work was done to reduce the number of clock cycles required for execution of stages. Register fetch stage was reduced to two cycles from three. Normally it takes two clock cycles to read the register file ram; however, by using an extra bypass mux one of the register files clock can be ignored. The same trick could be applied again making the register fetch stage single cycle if needed. The EX stage was reduced to two cycles from three in cases where the results flags do not need to be updated. The EX stage was split into three cycles to allow the results flags to be calculated after the result is calculated.

The goal now is a minimum CPI of two in pipeline loop mode.

Last Milestone: four ‘A’s on screen

Latest fixes: result flags were not being updated for load operations. This resulted in improper loop termination in the PutString() function. Several functions were not adjusting the stack pointer before returning, the result would be returns to invalid addresses. In the SoC the PTI controller’s ack line was tied low causing the system to hang when the PTI controller was accessed. It had been tied low as the PTI controller was not present in an earlier version of the system. The debug printchar routine was not incrementing the cursor position causing all the characters to be piled up in one corner of the screen. Several routines were found not having the minimum alignment of four for target call addresses.

Ran into an interesting pipeline loop mode bug. There was a pipeline bubble inserted after a load instruction. The instruction in the bubble position, a repeat of the load instruction, was simply marked invalid not to be executed. The bug was that the next time around in loop mode the extra bubble instruction was still there, so there were then two load instructions and another bubble was required. This caused one of the instructions in the loop to be booted out, replace by a load instruction. Then guess what? On the next loop iteration, the same thing happened again, and another instruction got booted out of the loop, then there were four load instructions. Eventually all that was left in the loop were the load instructions and a branch back to the load instruction. This caused an infinite loop as the loop counter no longer changed, having been booted out of the loop. The solution was simple, convert the instruction in the bubble position to a NOP. That way the next time through the loop it is harmless.