nonarkitten / pseudo-jit Goto Github PK

It might be required for stability (esp with the new register format that takes over the stack) that we need to remove all C code from the run time and tweak the assembly code to ensure that the stack is not used an only D0-D3 are.

Now that the opcode table is split we need to rearrange the fragments to optimize cache locality. Consult the Cyclone 68000 project for a good template to use for which opcodes to group together.

Some opcodes like BCD may require the stack (check) and if so, will need to be rewritten.

Memory timing is still not working well with Amiga custom registers. Seems to read ROM okay. RAM is hit-and-miss.

Need some example code on how to

• execute ARM instructions
• access EEPROM for settings
• change base parameters (e.g., clock speed)

We need to measure the clock input for best-attempt synchronization.

In this mode, we run the FSB at 50MHz regardless of the detected speed. This is primarily for MiniMig and the TF1200 (hopefully with more to come in the future).

Need an unbrickable way to update a SECOND image stored in SPI flash for easier user upgrades.

Self explanatory. We're implementing the WHOLE 68882 opcode table, possibly the 68040 additions for single-precision as well.

All 68030 opcodes should be included as well, but there is no real coprocessor bus so all other F-line opcodes will cause an exception.

PRU code is still working with the Alpha pinout. Need to update and expand on the PRU functionality as per the beta.

The PJIT cache has not be tested at all.

There are some really good ColdFire opcodes we can include that won't confuse core auto-detection. What this would allow is the use of a more modern compiler like CodeWarrior, which might produce better code than gcc?

• bitrev; reverse the order of all 32-bits
• byterev; reverse the byte-order of all 4 bytes
• ff1; find the first '1' bit
• mov3q; move a 3-bit immediate to arbitrary EA
• mvs; move and sign-extend in one operations
• mvz; move and zero-extend in one operations
• rems/remu; like divs/divu but only get remainder
• sats; if operation overflows, saturate to +/- INT MAX
• tpf; 2, 4 or 6-byte NOP

This will also need to be a user option and depends on the EEPROM working. Copies of the MapROM can exist in SPI Flash and should be loaded at boot time.

Accelerators can access chip RAM as fast as Agnus -- that is, perform a memory read/write per cycle. This isn't 100% compatible and needs to be a user option.

Interrupt handling was removed when I pulled the old C interpreter out. Need to put that back in.

Software RESET does not seem to do anything and/or work and we have no direct way of actually depowered in the chip. Need to investigate if this is a timing problem or we have serious I2C read/write issues.

It has been proven that big-endian mode works on the AM3358 with two exceptions -- all peripheral IO has to be endian-swapped when reading/writing registers and the GPMC is simply broken and will only work in little-endian mode. This has necessitated two workarounds:

eor rA, rA, #1

For accessing bytes in their correct order, and;

ror rD, rD,#16

To place words back into their correct order when reading/writing 32-bit data (and with read-modify-write operations, this has to be done twice).

An alternate option is to disable the GPMC and use "bit-banging." This would allow us full control over the bus and timing (though strict 68000 timing may be a challenge) without the need for the GreenPAK and has the interesting side-effect of no longer needing the GreenPAK.

24-bit address memory would be set up as a trap space for the MMU, triggering a data abort, which would then perform the memory operation manually before returning.

32-bit address memory would then be accessed using big-endian mode and neither the eor or ror above would be required, significantly speeding up access.

Good:

• much faster 32-bit performance
• easily reprogrammable timing parameters
• allows the Alpha-boards to be used
• allows the GreenPAK to be removed

Bad:

• much slower 24-bit performance
• loss of ARM-side DMA (which to be fair, isn't a "thing" yet)

Ugly:

• might be too slow to actually work (need to be inside ~500 cycles!)
• cannot use Code Composer Studio for this as it "forbids" big-endian on ARM

Right now, boot is hardwired. We need to save the various configuration states into EEPROM.

• core type (68000/EC020/030)
• FPU enabled or not
• base CPU clock (1 to 1000MHz)
• enable fast RAM

In the file pjit_handlers.c, ROXL and ROXR are not implemented.

Loading a 2MB file from SPI Flash (max 48MHz) is not going to be especially fast. We'll need to look into an efficient compressor for the code. LZ4W might be a very good and very fast candidate.

It might be a good idea to have something that can run all/most 68K opcodes and provide output.