Added a nano-cache to the core for instructions. Eight-entry fully associative. It does a wonderful job of speeding up small loops and things are noticeably faster. However, the screen display is now corrupt. It must be sending back-to-back writes through the network too quickly now. So a delay routine was added. Adding the delay routine fixed up the screen issues even on the other core too.

Been working on the string handling. Had to update things to take into account strings contained by local variables. Which means digging into the stack to find them. As it is the code updates variables on the stack when it is extremely likely a string. That means if data on the stack looks like a string it might get updated incorrectly. I am leaving it this way as it is TinyBasic. The data type is checked on the stack, then the pointer is checked to see if it is into the string area. If both those are true then it is assumed to be a string var.

This has led me into thinking of developing a processor with the data type tagged on the stack. If it were always know that a certain portion of the stack indicated the data type then it would be easy to do garbage collection. Keeping the stack 128-bit aligned for instance, a 32-bit data type and a 96-bit value could be stored on it.

It's quite remarkable to what degree cache size is a matter of diminishing returns. I recall we did very well with a tiny (direct-mapped, I think) cache in our OPC adventures.

Do you have cache for each style of memory acess, program counter, text segment,stack segment,video ram and i/o segment?
How well does the cache work with virtual memory?
Have you ever ran a simulation of your cache model? I still think in terms FORTRAN IV here for that, is this showing my AGE?
Ben.

No. There is only an eight instruction word cache. I may add more later. Thinking about adding a larger direc-mapped cache. 3/4 of access is fetching instructions.
I am not using virtual memory ATM. So it likely does not play nicely if virtual memory is added.
I just ran it directly from the FPGA.

What ever happened with OPC?

OPC... from a CPU design and implementation perspective, I think not much has happened for perhaps 5 years. But back in 2020 a PiTubeDirect release brought OPC second processors to the hundreds of people with a Beeb, a Pi, and a suitable adapter board. And I see revaldinho recently (last year) optimised some Pi-calculating code for the OPC7.
https://github.com/revaldinho/opc/commits/master
https://github.com/hoglet67/PiTubeDirect/releases
https://revaldinho.github.io/opc/

Most recently the T3X language has caught my eye
https://t3x.org/t3x/index.html
> T3X is a family of programming languages that share a common syntax, but offer different runtime environments and focus on different aspects of programming. All T3X compilers are small and fast and easily bootstrapped. Some of them support modules and separate compilation, some compile to machine code in a single step. The original compiler was targetted at the 16-bit Tcode machine, but native code backends for various processors exist.
(Edit: I see on a nearby page it wants many 100k of RAM, which we don't have. But I also see a Z80 version which doesn't need s much. More reading is needed!)

Had the divide operands backwards in TinyBasic leading to incorrect divide results.

Found the loop variable in a FOR/NEXT statement was not being handled properly. Leading to type mismatches.

I had a quick look at the T3X language and was glad to see they provided a grammar listing as well as descriptive text.

100k of RAM is not very much these days.

Finally got Basic working well enough to perform the prime.bas test again. This time it crawls at 6:54 six minutes, fifty four seconds to find the first 1000 primes. It is using decimal float arithmetic. I should find a way to eliminate the subroutine call as it copies values to / from memory.

Spent most of the time today working on Thor2023. But,

added the DFPTrunc96() module to the decimal float module collection. Trunc() returns the integer part of a floating-point number in a float register. It essentially implements the INT() function in BASIC.

Changed the prime.bas program to be more similar to the original and eliminated a multiply and subtract. Hopefully it will run a few seconds faster.

Please note the most recent version of the core is rf68000 located in the rf68000 repository. https://github.com/robfinch/rf68000
I should maybe change the name of this topic.

The original FT68000 core is very outdated and no so 68k compatible.

Started thinking about how to extend this core to 64-bits. The set of peripherals in use has some 64-bit peripherals. One thought is to make bytes 16-bits wide. So, B,W,L would be 16,32, and 64-bits. But I would also like to extend the number of registers. I think this has been done with the Apollo core already, so I have been researching that.

For a 64-bit mode I think the instruction parcel should be changed to 32-bits from 16-bits. The extra 16-bits would be used to specify more registers and operations. I think 16-bits could be inserted into the existing instruction format between bits 11 and 12, keeping the high order four bits as identifying the major instruction group. I have been looking at modifying the assembler to support this, and it is going to be a lot of changes to the assembler which is very complex.

64-bit mode would have 32 data and 32 address registers. It would also support a separate target register, which compilers like, allowing 2r1w instructions which do not need to overwrite a source operand.

Been watching streaming TV and playing video games lately. Taking quite a break.

Put some more thought into how to extend the core to 64-bits. My current thought is to use the MMU to specify 32/64 bit mode; this is how it is switched on some popular processors. Also may try to create a superscalar out-of-order version. 68k is appealing because it has only about 18 registers, if one include address, data, extra SP and flags registers. That means the register rename file does not need to be huge.

Chose to put the cpu width bits in the page management table entry. That way if the page is mapped multiple times it retains the size setting. Each memory page has a 128-bit tag associated with it, I call the PMTE. The same MMU system is used for several different projects.

Two bits are used, 00=data, 01=32-bit code, 10=64-bit code, 11=reserved.

Perhaps a new encoding method is needed on the 68000 model for long long and fixing the gizzilan floating point
sizes to just a few. Short ints don't seem to be used as often today, so a escape for that. Looking at the 68000 you spend a lot of time sign extending data. It world be nice if one could sign extend,or zero to the full 64 bits, rather than fiddle with data sizes and signed or unsigned data.
Byte, Byte sign extended and long long and long float encoded as short encoding, others flag a extend opcode.