Started another project called "bigfoot" because it will have a big footprint. It is a bit like the PowerPC, but with 41-bit instructions and 128 registers. An eventual goal is including backwards compatibility with the Itanium / x386, possibly others as well.

41 bits is strange size. What is the advantage here? The IBM 730 (stretch) had a separate logic block to handle logic and character/bit packing.
Would that be a advantage here?

I read about the IBM 730 (stretch) a while ago. Quite an amazing machine for the time.

Yeah, it is a strange size. Bigfoot needs 128 registers to be somewhat compatible and that means going to an instruction size larger than 32-bits. 41-bits fits three instructions into a 128-bit bundle and has the same basic format as the Itanium. The size allows 128-bit instruction fetches which is a nice power of two. It will be a challenge to work out the software.

There is a 68k core that might be integrated too. Hopefully several different cores will be able to fit. It is likely that the initial version will be a simple sequential state machine approach without an overlapped pipeline.

The system call instruction is being overloaded to call other instruction sets. It should be able to return back to the native set when a return from interrupt is done. Some more thought needs to go into how to get back to native mode though.

Worked on improving the rf8088 code with a goal of incorporating it into Bigfoot. It is a stepping stone to other CPUs.
The 8088 code is from 2009, a lot has been learned since then, and tools have improved.
An instruction cache interface has been added. The data port is being modified to use FTA bus.

You got one too many 8's there. 8080 emulation will get you CP/M.

The 8x86 model of computing may have too many problems, like segment registers and 1 meg adressing.
Debuging 386 code, may take more time, than a Native 32 bit machine, plus you got to reboot to change
386 modes. The problem with emulation is you need to bug compatable in many cases.


For bootstraping you need to keep it simple.
Testing a new mother board last night , that was bug fixed from the old mother board, 1st try did not work.
Replacing a 74HC14 with a real 74ls14 and a slower 22V10 it came to life.

Good luck with your new mission, this screen will self distruct in 5..4..3..2..

One step at a time. i386+ is more popular. I have a couple of other cores, 6502, 6809 that I might try and integrate.

I am shooting for simple compatibility to begin with. Just being able to execute ordinary i386 instructions, I expect it not to work in many cases.
To begin with the 386 emulation will not have many protection features. It will load the segment base from a descriptor but won't check limits for instance. I may add one or two features to allow mode switches.

I would like to be able to call i386 code from native mode, and have it return to native mode. I think that means adding flags to the i386 emulation so it can tell where it needs to return.
Yeah, I agree. The complexity has to be built up over time.

Got a good chunk of a i386 emulator core done, converting it from the rf8088 to 32-bits. It has been mostly coding so no bugfixes. I hope to have an estimate of the core size and performance in a few days.
I am guessing 5x the 8088 core or about 25,000 LUTs and 50MHz+. The rf8088 synthesized close to 100MHz. It was working for simple test programs at one point about 10 years ago. Timed for 70MHz in an older FPGA.

It looks like I was off a bit on my size estimate. I was thinking the 8088 was 8 bits, but it has 16-bit ops, so the 386 is only twice as wide not four times as wide. The 386 core is about 7,000 LUTs minus a few instructions yet, and times to 66MHz.

I am not sure what to do about paging. The native core has a TLB and paging, so I am not sure I want to add a second TLB and paging support in the 386. I will have to come up with a way of faking the paging stuff so that the native paging unit is used.

Now up to about 8,000 LUTs but many more i386 instructions added. Still makes 66MHz timing.

Took a break from the i386 emulation.

Shrunk the size of the Bigfoot TLBE by realizing that the access counters did not need to be part of the TLBE. That removes the access counter and the access counter update address and logic. The access counters can be dedicated RAM which increments whenever a page is accessed. The page access counters are useful for the aging page replacement algorithm.
The SoC has just over 8,200 hardware access counts. Fortunately, things do not need to be updated all at the same time. Only one memory access is taking place during any cycle. So a single counter combined with a RAM can be used.
A 27-bit counter was used because it fits nicely into the 9-bit wide BRAMs.

Working on access counters and implementing the page management table, got me working on memory gateways. A memory gateway protects an region of memory using access keys and privilege levels. An app requesting access must have a key matching the one required for the memory page, and it must also have privilege to access the page, or a protection error will be the response. There are three gateways in the system-on-chip. One each for DRAM, ROM, and IO. Here is a diagram of their placement in the SoC.

Worked on the MMU today, and started exploring capabilities.

https://www.theregister.com/2022/07/26/cheri_computer_runs_kde

Created a capabilities tag cache. Capabilities associate a tag bit with every 32-bytes of memory. Since memory is only an integral number of bytes wide, the tag bit must be cached elsewhere in memory. I have 16Mbits for tags for 512MB DRAM stored in the last 2MB of the DRAM memory. Another 16,384 tags or 2kB is stored in the scratchpad memory for the scratchpad and ROM memories.
The tag cache usually provides the tag bit without needing another memory access. If the bit is not in the cache then it must be loaded.

Modified the CPU to use 128-bit registers. Associated with each register is a 128-bit capabilities descriptor.
The register files uses 16 BRAMs now.

Been working on the MMU and coming up with support for capabilities.

Added group clear to the register file which allows clearing any number of registers within a group. Groups are 16 registers. So, all 16 registers of the group may be cleared with a single instruction. A similar instruction is present in the CHERI instruction set; useful for transitioning between secure domains. There are eight groups of registers for the 128-GPRs and eight groups for the FPRs.

Fixed some errors and omissions in the 80386 core. Still a long ways to go.

Moving mountains one stone at a time.