Standards/Protocols Discussion

[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.