Standards/Protocols Discussion

[xdot]

Maybe a new thread where everyone has one post to write down what codes he using?

So, discuss and suggest minecraft protocols.

TODO:

• Standard ORE Instruction Set
  
• Standard Serial Data Transfer Protocol
  
• Display/GPU Protocol/Standard
  
• Classification of Instruction Sets
  
• Classification of data transfer protocols
  
• Character Encoding (7-bit ASCII?)
  
• Network Packet Routing
  
• Network Streams (Simplified TCP?)
  

.. and many more.

NOTE: This post will be updated in the near future.

[Chibill]

Only a standard IS that it needs to be able to use but can have a custom one.

---

Like it interputs the Standard IS.

---

Also for protocals we need to have a standard type of communication then a protocol but I say 4 bit segments.

[himehowareu]

I think that standard IS would be a limit the possibility for redstoning but I think it should be a contest for the internet protocols should be held .

[mort96]

I think, with the speed of minecraft CPUs, interpreting an instruction set would be a huge overhead. I think we should choose one IS as the "ORE x86", the IS most CPUs use and most software is written for.

I wrote a specification for an IS which I think is pretty neat: http://mortie.org/?webapp=compiler_16/morcore_spec.txt. It should be fairly easy to implement.

Another plus is that I've already written a compiler for it, http://mortie.org/?webapp=compiler_16. If we went with that IS, all CPUs implementing it could be programmed via that web app.

I don't know if my IS is necessarily the best to choose for a standard IS, but it's at least out there.

[WrytXander]

I think, with the speed of minecraft CPUs, interpreting an instruction set would be a huge overhead. I think we should choose one IS as the "ORE x86", the IS most CPUs use and most software is written for.

I wrote a specification for an IS which I think is pretty neat: http://mortie.org/?webapp=compiler_16/morcore_spec.txt. It should be fairly easy to implement.

Another plus is that I've already written a compiler for it, http://mortie.org/?webapp=compiler_16. If we went with that IS, all CPUs implementing it could be programmed via that web app.

I don't know if my IS is necessarily the best to choose for a standard IS, but it's at least out there.

I really love the IS, but one thins that bugged me, was the fact that there were stacks. Not everyone uses stacksor know how to use/implement one. So mysuggestion would be having two versions of this IS, one being a simple one, the pther being a more complex yet broad one. The basic OPs would be the same, so they could easily talk to each other.

Another suggestion would be, maybe we could use already existing ISs, that were probably made for educational purposes, such as RiSC16 or something.

[Iceglade]

I think, with the speed of minecraft CPUs, interpreting an instruction set would be a huge overhead. I think we should choose one IS as the "ORE x86", the IS most CPUs use and most software is written for.

I wrote a specification for an IS which I think is pretty neat: http://mortie.org/?webapp=compiler_16/morcore_spec.txt. It should be fairly easy to implement.

Another plus is that I've already written a compiler for it, http://mortie.org/?webapp=compiler_16. If we went with that IS, all CPUs implementing it could be programmed via that web app.

I don't know if my IS is necessarily the best to choose for a standard IS, but it's at least out there.

Could you make a thread going more in depth on how to code for that? It looks interesting and if we were to standardize then it would be good to know.

[mort96]

@ice added some documentation to the site now.

@wryt not so sure about using IRL ISes. IRL, there really isn't an issue if you have to use 10 commands instead of 5 to do a task, as even on the slowest computers, there would be no significant difference. In MC however, that could be almost a minute difference on a slow-ish CPU.

There's also the memory issue. Minecraft CPUs usually have 4, 8 or 16 registers, and no external RAM. Compilers for minecraft CPUs therefore have to be really careful about how much RAM it uses. My Sixteen compiler mostly directly translates from Sixteen code to Morcore binary, with some syntactic sugar. I fear that to get something similar with IRL educational ISes, we would have to both use a lot more instructions and more registers. I may be completely wrong about this though, I'm not an expert in the field.

I really don't think multiple variations of the standard IS would be a good idea. Even though they would be similar, a lot of software would for instance require stacks, which would make it unusable in all CPUs which don't have stacks. Rather remove stacks completely than leave them optional to the CPU producer.

[Frontrider]

I suggested this thread, so i may tell my opnion: 3 or 6 bits, i dont think that its matters in binary, but its really matters in my system.
forum.openredstone.org/showthread.php?tid=1701
Matters to me as long as orders for non boulen logic can be repredented in these bits. Base 8 can make compact and fast circuit, count it in while deciding.
I will accept whatever you say, but count it in.Make sure that your codes will not be a drawback. I think this is the reason why people dont like it, but if you make it flexible, then it will bring forward.

[mort96]

I had actually pushed some changes with no testing. It broke everything, and I didn't notice. Way to go. The Sixteen compiler should now work.

[Chibill]

Down with Standard Do you not remember what happened when we tried this on the RDF.

[Frontrider]

Down with Standard Do you not remember what happened when we tried this on the RDF.

What happened?

[xdot]

I wrote a specification for an IS which I think is pretty neat: http://mortie.org/?webapp=compiler_16/morcore_spec.txt. It should be fairly easy to implement.

Even though your instruction set lacks some necessary features like basic pointer operations and (hardware) interrupt handling, I nevertheless think it's a good IS to base the standard(s) one(s) on. (+1 for the stack)

I really love the IS, but one thins that bugged me, was the fact that there were stacks. Not everyone uses stacksor know how to use/implement one.

Really, a stack is necessary as it is the most sane (and probably most efficient) way of implementing (nested) function calls.

I really don't think multiple variations of the standard IS would be a good idea.

I am actually hoping we can compile a list of "standard" instruction sets (based on the actual target hardware). So, for instance, we can have three categories:

1. Basic Processing Units (In essence, ALU + RAM + I/O)
   
2. Advanced Systems (Pointers, Interrupts, Several I/O devices - protocol implementations)
   
3. Multi-core/Multi-user/Multi-thread Systems (Process and User management, Virtual Memory - MMUs e.t.c.)
   

[Chibill]

And this is my base standard for my CPUs

The IS a = address d = data

Code:

0000 0000 0000 Halt
0001 aaaa dddd Store
0010 aaaa 0000 Load A
0011 aaaa 0000 Load B
0100 dd00 0000 Invert Toggle 01 = A 10 = B
0101 0000 aaaa Add
0110 0000 aaaa Subtract
0111 0000 aaaa And
1000 0000 aaaa Or
1001 0000 aaaa Xor
1010 d000 0000 Shift Output 0 = left 1 = right
1011 aaaa d000 Jump 1--- = conditional uses a and b in ALU  the next 3 bits are greater then,equal to,less then.
1100 aaaa 0000 AXU out outputs a Value in Program mem to AXU port
1101 aaaa 0000 AXU in inputs the data from AXU port to program mem
1110 aaaa 0000 AXU out outputs a data value from Ram to the AXU port
1111 aaaa 0000 AXU in inputs a data value from AXU to RAM

[redstonewarrior]

I have a better proposition. Instead of building a standard IS that all CPUs implement, have a solid IS that is then easily translated into each independent IS, possibly even in redstone hardware. (You'd run the program through a translator before running it, or translate it with a real computer program.) Compatible IS-es will require certain features of course, and it may not be optimized depending on the site-IS, but it's a better start.
On a side note,
<reserved for pipe architecture specifications>

[Chibill]

My idea was like red's so pick it!

[Frontrider]

Make it run on redstone, no external program.

[xdot]

Update: Mort and I extended the Morcor IS to include some necessary features. Here is the new version:

1 bit - Immediate Flag for ARG1 - IMM1
1 bit - Immediate Flag for ARG2 - IMM2
5 bit - OP Code - OP
4 bit - Result Register - RS
8 bit - Argument #1 - ARG1
8 bit - Argument #2 - ARG2

ARG1: If IMM1: Immediate value. Else: Register (Address).
ARG2: If IMM2: Immediate value. Else: Register (Address).

# Instruction word:
IMM1 - IMM2 - OP - RS - ARG1 - ARGS
1 1 5 8 8 8 = 31 bits

00000 - NOP - No instruction

# Memory
00001 - MOV - RS = ARG1
00010 - DIN - RS = Lowest 8 bits = ARG1, highest 8 bits = ARG2

# Arithmetic
00011 - ADD - RS = ARG1 + ARG2
00100 - SUB - RS = ARG1 - ARG2
00101 - RSHIFT - RS = ARG1 RSHIFT

# Logic
00110 - OR - RS = ARG1 OR ARG2
00111 - AND - RS = ARG1 AND ARG2
01000 - XOR - RS = ARG1 XOR ARG2

# Inverted logic
01001 - NOR - RS = ARG1 NOR ARG2
01010 - NAND - RS = ARG1 NAND ARG2
01011 - XNOR - RS = ARG1 XNOR ARG2

# Branch logic
01100 - CMP - Compare ARG1 and ARG2 and update the FLAGS register.
01101 - JEQ - Branch to RS if ARG1 == ARG2
01110 - JGT - Branch to RS if ARG1 > ARG2
01111 - JLT - Branch to RS if ARG1 < ARG2

# Input/Output
10000 - WRITE - Output ARG1 to device ID ARG2
10001 - READ - RS = Input from device with ID=ARG2. Halts CPU until input from desired ID.

# Stack
10010 - PUSH - push ARG1 to stack
10011 - POP - RS = pop from stack

# Pointers
10100 - LDP - RS = *ARG1 (The value at the memory location specified by the contents of ARG1)
10101 - SVP - *ARG1 = ARG2

# CPU State
10110 - STOP - Stops the execution and resets program counter.
10111 - HALT - Halts the CPU until the user resumes the execution.

It is far from complete but it is a fairly good starting point.

[Chibill]

No I am still being like red custom IS Common coding langue.

---

Also one IS limits The way CPU can be built it also destroys optimization of the IS for the CPU.

[xdot]

No I am still being like red custom IS Common coding langue.

---

Also one IS limits The way CPU can be built it also destroys optimization of the IS for the CPU.

No one forces you to use it. Also, whether a potential minecraft CPU uses the standard instruction set (or one of the standard ones) or translates it - either on the fly or ahead of time - is irrelevant to the (current) discussion. We still need a universal instruction set.

However, as red said,

Compatible IS-es will require certain features of course, and it may not be optimized depending on the site-IS, but it's a better start.

[Cutlassw30]

The standard IS is a stupid idea. It kills change (cough x86).... What we need is a standard assembly level language in which we can transfer down to other ISs to exploit what they offer in terms of functpnallity and speed. A few set ideas would be needed such as interrupts and segmentation registers for virtual memory management to allow for a full system architecture however we should still be able to change the IS at anytime and just recompile the language to suit the new IS.

If we do make sort of a standard to follow I would recommend a few basic functions.

Arithmetic operations:

Their should be 4 types of arithmetic operations.

Unsigned For mult/div
Signed For mult/div
Immediate value argument

Then for branches.

I really hate the way x86 dose branching, the whole idea of using a CMP instruction before jump if equal to is really annoying and very slow IMO.

Op code 5 bits
Register arguments 4 bits

0-5 6-9 10-13 14-15
[op-5][RAA-4][RAB-4][nul-2] instruction uses no immediate
0-5 6-9 10-15
[op-5][RAA-4][IMM-6] instruction uses immediate (mem offset)
0-5 6-15
[op-5][IMM-10] instruction uses long immediate (jumps)

I think with branching however the CMP instruction is the only way around this so i digress on this point. (after all I want 1 cycle 16 bit loads from serial memory).

Registers.

AR: accumulator, used in almost all instructions. arithmetic, logical, function calls, etc

BR: base, only register that can be used as a memory offset MEM[BR+IMM]

CR: Used like the variable "i" in programming, used in loop instruction.

DR: Almost like a second accumulator, stores overflows from arithmetic operations, used as second arguments in function calls.

ER Used only for context switching (if we implement modes such as protected and real mode this register is not usable in protected mode).

FR: Holds flags of all operations preformed.

SI: Source of all memory operations

DI: Drain of all memory operations

R9-16: Gen purpose.


I will write more shit later.

[Chibill]

This is what I said cut but they won't stop with the Standard IS!!

[VirtualPineapple]

I don't like the idea of implementing a stack or pointers at the hardware level. I'd prefer to have those things as part of general memory management that is done by software. In real life, I don't believe that there is an actual hardware stack in the computer's RAM and though there is the issue of limited amounts of memory in minecraft, I think we should stay away from implementing pointers and stacks as separate devices. (Just a thought ;3)

[xdot]

The standard IS is a stupid idea. It kills change (cough x86).... What we need is a standard assembly level language in which we can transfer down to other ISs to exploit what they offer in terms of functpnallity and speed. A few set ideas would be needed such as interrupts and segmentation registers for virtual memory management to allow for a full system architecture however we should still be able to change the IS at anytime and just recompile the language to suit the new IS.

Yes, I tried to make clear that a CPU does not need to implement exactly the same instruction set. As long as the native IS is compatible and can be translated from and to the standard IS/Assembly langugage/Specification it can be considered standard-compilant.

Immediate value argument

We figured out that the majority of the instructions have immediate argument variants. That's why we just added a separate flag instead of dup- and triplicating instructions.

Then for branches.

I really hate the way x86 dose branching, the whole idea of using a CMP instruction before jump if equal to is really annoying and very slow IMO.

Op code 5 bits
Register arguments 4 bits

0-5 6-9 10-13 14-15
[op-5][RAA-4][RAB-4][nul-2] instruction uses no immediate
0-5 6-9 10-15
[op-5][RAA-4][IMM-6] instruction uses immediate (mem offset)
0-5 6-15
[op-5][IMM-10] instruction uses long immediate (jumps)

I think with branching however the CMP instruction is the only way around this so i digress on this point. (after all I want 1 cycle 16 bit loads from serial memory).

We actually tried to avoid that instruction but ran into multiple problems, as you did.

Anyway, from what I read, I think that you are trying to define a two-operand/accumulator IS. Even though I am not opposed to the idea, I think that a 3-operand IS would be easier to translate to lower level ones.

This is what I said cut but they won't stop with the Standard IS!!

Instead of complaining without arguments, why don't you contribute positively to the discussion?

I don't like the idea of implementing a stack or pointers at the hardware level. I'd prefer to have those things as part of general memory management that is done by software. In real life, I don't believe that there is an actual hardware stack in the computer's RAM and though there is the issue of limited amounts of memory in minecraft, I think we should stay away from implementing pointers and stacks as separate devices. (Just a thought ;3)

You have a point but (unnecessary) software emulation can be devasting to the CPU performance. For instance, if you try to implement virtual memory on the software level, memory access would be ridiculoulsy slow (3 CPU cycles overhead per fetch?). After all, most IRL hardware IS _do_ have specialized instructions (PUSH, POP) and registers (ESP) for stack manipulation.

[Cutlassw30]

Most instructions DO NOT need an immediate. ADD is one of the most common instructions and thats the only reason ADD immediate is there rather than say load value. Its only 2 extra cycles to do a AND immediate for example with out an actual ANDI instruction. I say leave ADDI as the only instruction that loads a value to a register (besides maybe ADDSI which shifts it over 8 times).

We should focus more on 2 cycle branching issues as they are used more commonly in programming.

[xdot]

Its only 2 extra cycles to do a AND immediate for example with out an actual ANDI instruction. I say leave ADDI as the only instruction that loads a value to a register (besides maybe ADDSI which shifts it over 8 times).

Considering that a single cycle takes from 5 to 20 ticks (depending on whether your CPU is pipeline'd), 2 extra cycles sounds like a waste of both CPU cycles and register/memory space (possibly bandwidth), compared to the 1 bit instruction word overhead. A solution would be to populate the registers with the immediate values during initialization, but it does not feel right to reserve memory for hardcoded bitmasks (e.g. 0xff).

[redstonewarrior]

To jump in with out of context high level statements, we should make an assembly language / base IS (to be converted) high level CISC, so that they are easily boiled down for individual (probably RISC) ISes.

[Chibill]

I resist this because I remember this past when you tryed this before.

[Iceglade]

Everything in this discussion is contradictory to progress. This thread sprung from one about reaching our limits, didn't it? Well let's think. We make this standard IS which little deviates from. We make software on 5 tick CPUs which are pretty much good enough to run Pong. Maybe space invaders if you're really good. And look at this! We're in a "software age" that lasted about a month, and now everybody is just making Pong in different ways on the same interface and then making another CPU.

In building up, I assumed this meant primarily networking and maybe some VMs to translate IS. A redstone internet forged in bussing across the top of the server would be amazing. A possible text-based programming interface for a CPU... just imagine real programming! I'm pretty sure that's never been done!

I'm just sad to see the smartest people on the entire server literally orchestrating the end of all new developments on ORE. Our time and effort should go into actually building up rather than just standardizing so we can show off our 200 different implementations of the midpoint circle algorithm.

[Konstacon]

As for the character thing, I have a character set I call the SSBCS for Standard Six Bit Character Set:

xxxx y z

The z bit is the special character control. If it is 0, special characters are off. If it is 1, spec chars are on.

The x bits (for spec chars off) represent letters A-M (13 letters) and . , and ! when the y bit is off. If the y bit is on, it represents N-Z (13 letters), and a space, and parenthesis.

When spec chars are on, and y is off, it represents numbers and 6 accented letters. When y is on, it represents the thing we need most; math characters!

Here's a table for the math characters. You guys can come up with the accented letters.

xxxx | output
0000 | square symbol
0001 | cube symbol
0010 | ^n symbol
0011 | +
0100 | -
0101 | x (not an x but a times sign)
0110 | / (not the boring slash but the dash with a dot over and below it)
0111 | >
1000 | <
1001 | =
1010 | {
1011 | }
1100 | [
1101 | ]
1110 | ^
1111 | ? (question mark because I couldn't fit it anywhere else.

I'll create a simple one if the spec chars are useless

[Cutlassw30]

As for the character thing, I have a character set I call the SSBCS for Standard Six Bit Character Set:

xxxx y z

The z bit is the special character control. If it is 0, special characters are off. If it is 1, spec chars are on.

The x bits (for spec chars off) represent letters A-M (13 letters) and . , and ! when the y bit is off. If the y bit is on, it represents N-Z (13 letters), and a space, and parenthesis.

When spec chars are on, and y is off, it represents numbers and 6 accented letters. When y is on, it represents the thing we need most; math characters!

Here's a table for the math characters. You guys can come up with the accented letters.

xxxx | output
0000 | square symbol
0001 | cube symbol
0010 | ^n symbol
0011 | +
0100 | -
0101 | x (not an x but a times sign)
0110 | / (not the boring slash but the dash with a dot over and below it)
0111 | >
1000 | <
1001 | =
1010 | {
1011 | }
1100 | [
1101 | ]
1110 | ^
1111 | ? (question mark because I couldn't fit it anywhere else.

I'll create a simple one if the spec chars are useless

I would just use standard 8 bit ASCII.

[himehowareu]

I think that some one should write a VM for these code so we can see them at work I am will to do this if some emails me the IS ,cycles per op code ,and clock speed I should have it done with in the hour ddpening on the time

Email : himehowareu@gmail.com

[Konstacon]

As for the character thing, I have a character set I call the SSBCS for Standard Six Bit Character Set:

xxxx y z

The z bit is the special character control. If it is 0, special characters are off. If it is 1, spec chars are on.

The x bits (for spec chars off) represent letters A-M (13 letters) and . , and ! when the y bit is off. If the y bit is on, it represents N-Z (13 letters), and a space, and parenthesis.

When spec chars are on, and y is off, it represents numbers and 6 accented letters. When y is on, it represents the thing we need most; math characters!

Here's a table for the math characters. You guys can come up with the accented letters.

xxxx | output
0000 | square symbol
0001 | cube symbol
0010 | ^n symbol
0011 | +
0100 | -
0101 | x (not an x but a times sign)
0110 | / (not the boring slash but the dash with a dot over and below it)
0111 | >
1000 | <
1001 | =
1010 | {
1011 | }
1100 | [
1101 | ]
1110 | ^
1111 | ? (question mark because I couldn't fit it anywhere else.

I'll create a simple one if the spec chars are useless

I would just use standard 8 bit ASCII.

8 bit ASCII has way too many characters to reasonably implement in minecraft.

[Chibill]

Yes this died!

[Iceglade]

Well don't bump it -_____-

[Legofreak]

I know this thread died but the way I transfer data along my serial lines could be modified to be a standard.

When a data send button is pressed, it is directly connected to the output line, sending a pulse which is detected by the receiver to start the recieve process. Then the reciever ignores any further data for a specific time and passes it through to the storage. The button pulse is followed immediately by the stream of data. Data is sent 3 ticks on 1 tick off effectively sending at 10b/s. It seemed having 4 ticks on caused data loss from high to low values and 2 ticks was hard to sync the reciever. Anything faster is just madness until comparator's are fixed.

Currently I'm using this standard to send 64 bit images. It is very easy to move data around to various slots.

I suppose the problem with this is addressing is separate. Unless you were to make a router that takes the same format as an address.

[Iceglade]

STOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOPSTOP