the idea for this is pretty amazing, but personally i would like it if there was a way to import a file or pastebin instead of having to use a book to write programs for it.

also 2 questions

1. are local labels supported?
   local labels basically allow you to reuse the same label names if they are within a global label, for example:

function_a:
    <code>
    .loop:
        <code>
    JMP .loop

function_b:
    <code>
    .loop:
        <code>
    JMP .loop

both use "loop" but refrence different labels, i use this a lot because this means you can use short label names and don't have to do stuff like "print_string_loop_1" or something.

2. what's up with the binary prefix?
   usually all base prefixes are consistent
   0x<number> for Hexadecimal
   0o<number> for Octal
   0b<number> for Binary

so why is it "<number>b" in this case? cannot be both supported plus "<number>h" for Hex?

I was thinking about making a mod that added buses to solve this problem. It would of had pinout blocks that could be added to the bus to tap into different signals.

wouldn't it just be easier to support ProjectRed's Colored Redstone Alloy Cables and the Bundles?

that would give you 16 bits per side, whic his 4 times as much as the current Vanilla Redstone variant plus since bundled cables are bi-directional you could be able to set each idivitual bit as either input/output instead of assigning each port as input/output.

then again if you were to use your own system you could probably support more than that in terms of bandwidth

Thanks @ProxyPlayerHD. I had a lot of fun building this mod and learned a lot. If I was doing it again, I would attempt to emulate a real processor like the z80 or i8080. If that were the case, I think real assemblers could be used, which would be really neat along with probably addressing some of the issues you have run into. Using something like pastebin is a great idea.

1: are local labels supported?
I don't remember, but I doubt it.

2: what's up with the binary prefix?
Great question, I think I accidentally mixed too different standards together.

hmm i'm not sure if emulating a complex existing CPU for a MCU is a good idea.
I don't know the Memory/Processing limits of this, so i'm not sure how complex you can get with this.

I would like to try to make my own version of this MCU and maybe improve it, but i cannot really use your CPU as example as there doesn't seem to be a lot of documentation about it, other than the registers and a simplified instruction set list (like i doubt that the only MOV instruction is MOV A, B). like what's the Program Counter width? Stack Pointer? Memory limits? the exact Instruction Set? what Architecture is it? etc.

lastly, before i go off reading about how MCU really work, what if MCUs that are placed next to eachother would connect to form one large MCU with more ports.

Back when I was looking at it I thought it might have actually been easier: http://www.emulator101.com/reference/8080-by-opcode.html, but I could easily be missing something. For that matter it wouldn't surprise me if an opensource java emulator could be found in github for one of those basic 8 bit CPUs.

When I built this processor, I made it run off of assembly instructions not opt codes ... I would not do that again. The architecture is custom with instructions modeled after x86, it was written from scratch. It is actually fairly simple, this class should answer most of your questions: https://github.com/ToroCraft/Minecoprocessors/blob/master/src/main/java/net/torocraft/minecoprocessors/processor/Processor.java

I used a byte for the stack pointer, a short for the instruction pointer. Not counting the stack and registers, I don't think the process as anything I would call memory.

Here are the registers: https://github.com/ToroCraft/Minecoprocessors/blob/master/src/main/java/net/torocraft/minecoprocessors/processor/Register.java

That last question could be tricky. It is of course possible, but would probably take some effort as it is not currently supported. I found dealing with the minecraft side of things was fun, but tricky and aggravating at times. I was thinking about making a mod that added buses to solve this problem. It would of had pinout blocks that could be added to the bus to tap into different signals.

ok so i threw something together, the CPU i thought up has the following:
6x (8 bit) General purpose registers: A, B, C, D, E, and F
2x (8 bit) Index Registers, X, and Y
1x (16 bit) Program Counter and Stack pointer
Currently 188 Instructions though this can easily change
a WAIT Insturction which HALTs the CPU until one of the ports changes (basically the same as you implemented it)
Data and Addresses are Big Endian, so it's eaiser to read for the user.

and yea not really sure what else is noteworthy, so here's the Instruction set. the order is that the coloumns defines the first nibble and the rows the second nibble. so for example a WAIT instruction is 0x01.

another thing about the instructions. * Defines a byte in memory directly after the instruction, and () means that the 2 following bytes after the Instruction are used as an Address, so (+X) means that that read address gets X added to it before being used.

the idea of the Memory map is realtively simple. IO has to be mapped to Memory as well since there are no IN/OUT Instructions
0x0000 - 0xFEFF -> Main Program Memory (65280 Bytes)
0xFFD8 - 0xFFDF -> Port Settings (8 Bytes)
0xFFE0 - 0xFFE7 -> Front Port (8 Bytes)
0xFFE8 - 0xFFEF -> Right Port (8 Bytes)
0xFFF0 - 0xFFF7 -> Back Port (8 Bytes)
0xFFF8 - 0xFFFF -> Left Port (8 Bytes)

Default value of SP = 0x7FFF
just in case someone uses the Stack without setting up an Address for the Stackpointer first.

I just thought of this Memory map, you can do stuff however you want, personally i would just leave space open between each port so that in the future if you ever go with your Bus Idea and increase the bandwidth of each Port it will not break existing programs because now all the base Port Addresses are different.

if there are any question or critism, just let me know. I'm not perfect at designing stuff like this.

Looks like you are on the right track to me, I didn't plan it out near as much. I am looking forward to seeing what you come up with!

I am going to close this issue, but please feel free to posting.

Thank you, since i don't know Java i will just try to build this in a Logic Simulator.

luckly my Vacation is just around the corner so i should have enough time to get something working.
I will use Logisim for this because i've used it for years and it just works.
i gave a link because i will send the finished MCU once i'm done so if you want you can look at it and maybe see some example programs running. (though with 4x 4 bit outputs it might be a little hard to get something like Text, but in a simulator you can always "cheat")

ok, i'm having quite a hard time to do anything really...

because... i don't really need to make a functional CPU, i just need to descripe it somehow, but i'm also bad at writing documenation.

so it's just hope this is understandable, you can just ask me if there are any aspects about the CPU that seem confusing: PASTEBIN

also here is an updated pic of all instructions, i tried to color code them, they are in the same order as in the Documentation:

for the rest of the MCU i just reuse the same information as i gave above:

0x0000 - 0xFEFF -> Main Program Memory (65280 Bytes)
0xFFD8 - 0xFFDF -> Port Settings (8 Bytes)
0xFFE0 - 0xFFE7 -> Front Port (8 Bytes)
0xFFE8 - 0xFFEF -> Right Port (8 Bytes)
0xFFF0 - 0xFFF7 -> Back Port (8 Bytes)
0xFFF8 - 0xFFFF -> Left Port (8 Bytes)

Default value of SP = 0x7FFF
just in case someone uses the Stack without setting up an Address for the Stackpointer first.

but one change, the ports are by default just 4 bit, so they should use the most highest address to also fit with the big endianness of the CPU.
so the Front Port technically goes from Address 0xFFE0 - 0xFFE7 but only the lower 4 bits of Address 0xFFE7 are actually effected/have an actual effect by/on the real Redstone Port

same with the Settings, only 4 bits are required to set each port to either input or output, and another 4 bits to either activate or deactivate the WAIT Feature of each port, but because of potential future expansion both should not be hosted in the same byte, maybe something like this is better:

0xFFD8 -
0xFFD9 -
0xFFDA -
0xFFDB - lower 4 bits have the Settings for the I/O Direction
0xFFDC -
0xFFDD -
0xFFDE -
0xFFDF - lower 4 bits have the Settings for the WAIT Function

and both just grow upwards if they are expanded. thought that would leave you with at most 32 bits of either setting, which means 32x4 bit Ports, or higher maybe 8 bit Ports.