Spent some time sketching out a 20-bit version of the 8086, using 10-bit bytes. I wanted a fairly simple processor with more memory available than 64kB. A 10-bit byte 8086 would work well. There is enough additional room to support 16 registers. Next, I thought it would be better to stick with 8-bit bytes. So, I sketched out the processor again, but this time extended the addressing to used 24-bit addresses rather than 16-bit addresses. After a short time, I finally figured my time would be better spent working on my 80386 core, needed for Bigfoot. Fixed several bugs in the rf80386 core, but have not got to the point of testing yet.

The memory controller for the test system needs to be updated. The explicit channel id has been replaced by one present in the transaction id. This is almost easy to do, except that an invalid channel id was being used as a flag, and now there are no invalid channel ids. So, rework is needed to support an invalid channel flag.

Built the i386 assembler available with vasm. So, a small amount of startup test code can be written.

Reviewed some i386 test code from here: test386.asm/src/test386.asm at master · barotto/test386.asm · GitHub

The reset address for the i386 emulator was moved to avoid issues with the cache prefetching beyond the end of memory. The usual reset address is $FFFFFFF0 but this address causes the cache to fetch a line “wrapping around” in the memory space. So, the reset address has been changed to $FFFF0000.

The operand size control logic was worked on for the i386 emulator.

I have got a ‘386 core is ready to the point of running some tests in simulation, but I have run into a snag. I do not know how to specify scaled index register without a base in vasm. It took me a bit to get used to the AT&T syntax style. The following code gives an error when assembled for the scaled index operand. This looks to me like an issue in parse_operand() for x86 assembler.



error 2007 in line 21 of "t386.asm": missing ')' in baseindex addressing mode
> movw $error,(%eax*4)

error 2007 in line 22 of "t386.asm": missing ')' in baseindex addressing mode
> movw $0xf000,2(%eax*4)

just possibly you need a comma?

example online which might be relevant:
> cmp 0x804a38(,%ebx,4), %eax

Putting in a comma works ( I did try that ), fixing the operand, but the assembler came back with a different error having to do with the operand size I think.

I managed to work around it.

movw $error,(,%eax,4)

did not work because the error routine address label is treated as a 32-bit value even when the code is specified as 16-bit.

I changed it to something like:

movl $error,%edx
movw %dx,(,%eax,4)

There are issues to work through in the core with real vs protected mode and size prefixes.
I am thinking of only supporting protected mode, but then there are issues setting up segments prior to segment descriptors being setup.

Some progress on i386 emulation. First run of a loop to initialize a small table in simulation. Getting Fibonacci working is the next step. Fibonacci was compiled and linked with vbcc and vlink. The C compiler and linker work as they are.

Big Fixes:
Some compares were updating the register file.
The CALL instruction was decrementing the stack pointer an extra time.

The core, without the cache, is sitting around 12k LUTs in size. I think this is very good. It should fit into a small FPGA.

Milestone:
The Fibonacci test program runs! To do more sophisticated testing the test system needs to be revised for 32-bit operation, so that I/O can take place. For a while the test system has been geared towards a 64-bit machine. For instance, the text display uses 64-bit character cells. I suppose I could try extending the i386 emulation to 64-bits, but it would likely result in an incompatible machine.

The size of a text character cell may be tied to the bit-width of the processor. 16-bits for a 16-bit processor, so 32-bits would probably work well here.
9-bit RGB333 foreground and background colors plus a 12-bit character code number is one possibility.

Some updates were done to the test system and few snags had to be worked out.

Work being done on a bootrom written in C. ATM it does little more than initialize a page table, then delay for about 3 seconds. Contemplating setting up the memory gateway system.

Memory gateways are set to ‘no key required’ and public access when the FPGA is configured. This allows unrestricted access to memory areas.

rf386 Bug Fixes:
The modrm byte was not being read for shift by immediate.

The stack pointer was being updated with an adjustment value even for RET without an adjustment.

A transaction id check had to be added to the LOAD states. For some reason, responses are being repeated in the response buffer. This caused loads for the wrong response.

rf386 changes:
Questioning handling of hardware interrupts. Rather than the existing method of the processor performing an interrupt acknowledge cycle to fetch the vector when an interrupt occurs, an interrupt message may be placed on the response bus. The message would contain the vector. The cpu would continuously poll the response bus in hardware for an interrupt message, then act on it. Using a message would reduce the interrupt response time as there is no need to request the vector.

rf386 Bug Fixes
Shifts and rotates were completely messed up. I must have been drunk when I coded them originally. Found while testing branches which use a shift to set bits in the flags register.

rf386 differences from i386
The upper address bits for real mode are 0xFFF placing real mode in the upper megabyte of the memory space. The test system is built with scratchpad in this area for booting. There is no memory in the lowest megabyte of the test system. The 0xFFF is a config constant.

The overflow flag setting for multi-bit shifts is undefined for the ‘386. rf386 calculates this. If the sign of the result is different that the sign of the original value, then overflow is flagged. The original test program assumes that the overflow is set to zero for multi-bit shifts. However, since the behavior is supposedly undefined for the '386 programs should not rely on the setting.

Some of the shift flag result settings may be different, but they are still sensible. For instance, if a value is shifted to the right by 32 bits and shifts operate according to a modulo 32 count, then the result is the same as the input. According to the original test program all the flags are cleared. However, rf386 sets the sign flag according to the sign of the result.
There may be similar issues with the half-carry for BCD arithmetic. rf386 may not set this flag exactly the same as the i386 in all cases.

Testing all the corner cases is just too much work for a home project, so things that are not quite the same are "features".
The goal is to get a large amount of code working, mostly generated by a compiler.

Testing of the i386 emulation is progressing along. Mainly porting test routines for use with vasm.

Ran into an issue with the expansion of macros to symbols used in a .if directive. If the symbol is non-constant then an error occurs. However, for the use case, two symbols were being compared for equality. I tentatively modified vasm to allow non-constant symbols to be compared for equality, returning true if it is the same symbol on both side of the '=' even though it may not be defined yet.

Running about 800 instructions in sim reveals the IPC to be about 0.123 or a CPI of about 8.

rf386 successes
String instructions appear to have worked the first time without modification. Otherwise, the test program is not sufficient to detect errors.
Test code is about 6kB or 2,800 instructions of assembler so far.

rf386 bug fixes
Loads and store were not always successful if there was an instruction cache load taking place at the same time. So, load and store were modified to wait for an instruction hit before proceeding.

The bus allows two options for stores, a classic cycle, and an error acknowledge cycle. Classic stores assume the store operation completes successfully. Devices on the bus do not need to send back an acknowledge for a classic store. Error acknowledging stores require a response cycle indicating an error or success which is sent back to the bus master. The difference is that classic stores are very fast, requiring only a single clock cycle to post the store operation. Error acknowledging stores are much slower as they wait until a response is received back from the device. It may take a dozen cycle for instance for the store to make a round trip. The drawback of a classic store is that there is no way to tell if the store worked. In testing stores were failing, then stale data was being read back on a load.

Challenges
vasm cannot currently handle an instruction prefix placed on the same line as the instruction. This led to errors in the port of the test software. This took me a bit to figure out, done by reviewing the backend cpu.c code.

Some work on protected mode code was done for rf386.
It is hundreds of lines of code to perform a call / return operation. Which has led me to think that this part of the project is somewhat dubious.

The interrupt handling code was updated to separate interrupt handling for different modes. Previously the approach used was a single sequencer containing if/else statements. Protected mode interrupt handling still is not fully coded.

The core has creeped up in size to about 17kLUTs.

I have been browsing some of the x64 instruction set documentation, toying with the idea of supporting 64-bits.

I may take a break from the rf386 to work more on Bigfoot’s native mode.
Worked on Bigfoot’s native mode branching. The instructions vary from one to five bytes in length, with the length determined by the first byte of the instruction. Opcodes are shown in the table below.

Bigfoot native mode supports protection with 256 privilege levels. I have not figured out all the details yet. If the x86 protection model is roughly followed, then 256 stack pointers would be needed in the task control block. One for each privilege level. This seems a bit excessive to me. It can be noted that a task cannot be in more than one privilege level at a time. One thought is to cache four stack pointers along with their associated priv level in the TCB (task control block). If the priv level is not in the cache then a stack for that priv would need to be allocated and added to the cache.
Another thought is to use the priv level to compute an index into a large stack area. Memory is divided up into lots that have a priv level associated with them. Multiple stacks at the same priv level could be in the same block.
ATM I am leaning towards going with the excess. 256 stack pointers in a TCB. While it would consume a chunk of memory (4k for SS:SP), it is a simple approach.

rf386 status
It is like 300 LOC but I think the RET/RETF operation is finally coded, including protection checks. I am not sure that it does all the protection checks in the same order as a i386, but it only makes a difference if the checks fail.

rf386
Updated the far call code. It is about 400 LOC.
Got some of the task switching code written.
There is work yet to do on the interrupt return code.
The core has creeped up in size further to about 20kLUTs.

Bigfoot Native Mode
Switched to using 8kB memory pages rather than 64kB. This should help prevent wasted space with small allocations. The primary reason 64kB pages were in use was to match the memory lot protection system lot size of 64kB. I am rethinking the memory lot system as I think it may not scale well to gigabytes of memory. The information stored in the memory lot tag is currently tested during memory access in a memory bridge at the target memory. This means the information does not need to be fed back up the memory hierarchy, making lot tests fast. But it requires dedicated RAM integrated into a memory bridge and the amount of such RAM may not scale to the size of main memory.

rf386
Up to 7kB of test code for the cpu test program is running and not reporting any errors. Testing has gotten to the point of testing the paged MMU of the ‘386. The MMU emulation is not coded yet. I am not sure I want to develop a i386 compatible MMU. Bigfoot’s MMU would be used instead. Bigfoot’s MMU is now similar to the RISCV MMU. It uses 8kB pages though.

Bigfoot Native Mode
Pondering how to implement the privilege level system. I think the privilege level need only be checked to map pages into the app’s address space. If an app does not have a particular privilege, the memory page simply is not mapped into the app’s address space. Previously, the privilege level and page key were part of the TLB entry and checked for every access.

rf386
Coded the move to/from control registers instructions. Cr3 is interesting because it contains the page table base address, and so when it is updated a MMIO store operation takes place to update the base address in the page table walker, which is a memory mapped device.

ToDo:
The debug control registers and associated logic are not coded yet.

The MMU was integrated into the MPU component. It has not been tested yet, but the default setup does not seem to interfere with the execution of the cpu test program. By default, the scratchpad RAM / ROM address translations are stored in the TLB at reset, so they do not need to be found via a table walk. No table walks taking place yet.

The MPU which currently includes the CPU, instruction cache and MMU is about 27k LUTs.