DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.


I do wonder if CPUDesigner would even be needed as the front end for the assembler could handle all of the creation of things based on existing properties. Most if not everything, will essentially be a property. Well properties are user-set and may have default values possibly.


Testing hello world assembly with -kernel in QEMU. However I have no idea where the kernel has been placed. So a bunch of 0xDEADBEEF and a memory search should find it. Setting the system to only 16MiB causes it to crash when it tries to read 0x01000000. memsave also appears to not do anything.


Seems I found my code, which is at 0x01000050.

00000050  00 00 00 00 de ad be ef  de ad be ef de ad be ef

Appears my current set of instructions proceeds to overwrite every single memory address with 0x60.


Actually that setting of every address to 0x60 is performed by the firmware itself for some reason (not my code). Perhaps it is trying to cause some kind of hardware fault so the real CPU resets on system that did not boot correctly. I will need to dig up my old code that does have an actual working PowerPC booting, for an old project when I had a simple C kernel.


Found my code, which just sets the start address to 0x0, thus causing it to work correctly. So basically the initial boot objects I make are going to be modeled after this since it works for the most part.


I believe I will remove CPUDesigner as the assembler front end can handle abstract creation of CPUDesigns.


Another thing I can have is a CPUInstruction interface that way I can programatically without resorting to Strings, use that on the representation of input and output assembly code.


Another thing I can add to instructions is an optional emulation layer, or rather simulation so that I can determine if I understand the register enough to see if it works correctly. Such code would also be handy for when code is run which uses illegal opcodes that are defined in a future CPU, that is assuming they throw an illegal opcode condition. Although it would be interpretive only it would form the basis for a simple emulator. Another thing it would be useful for is in the debugger, I can simulate the execution of a method and see if it works as intended. If that method does call other methods they will have to be loaded and emulated also, and it might not be possible to know where they even are.


The instruction enumeration could also greatly simplify assembly and disassembly of code, as I can remove gigantic switch statements and such.


So an analogue of the CPUData and such in NARF has now been placed in the core compiler and on top of that it is more generic and so everything can use it. With both asm and disasm rewriting code or doing nasty dependencies can be averted. So now I can start to work on the new CPUDesign and such and then have the assembler and NARF itself use that information. I disliked the CPUData because it was a bit crimped and ugly in usage. When I write CPUDesign it must not be ugly. Using the property enumeration and such should make it easier.


With the way my CPUDesign is, getting the asembler or disassembler from it will not work out as each machine will have varying things when it comes to insutruction encoding and decoding. Thus, AFE gets the creation.