12-29-2013, 08:53 AM
(12-28-2013, 10:28 PM)mort96 Wrote: 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) (12-28-2013, 11:18 PM)WrytXander Wrote: 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. (12-28-2013, 11:44 PM)mort96 Wrote: 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:
12-29-2013, 01:35 PM
And this is my base standard for my CPUs
(12-14-2013, 10:17 PM)Chibill Wrote: The IS a = address d = data
12-29-2013, 06:50 PM
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>
12-29-2013, 07:38 PM
My idea was like red's so pick it!
12-30-2013, 11:21 AM
Make it run on redstone, no external program.
12-30-2013, 01:49 PM
Update: Mort and I extended the Morcor IS to include some necessary features. Here is the new version:
Quote:1 bit - Immediate Flag for ARG1 - IMM1 It is far from complete but it is a fairly good starting point.
12-30-2013, 05:28 PM
(12-30-2013, 03:46 PM)Chibill Wrote: No I am still being like red custom IS Common coding langue. 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, (12-29-2013, 06:50 PM)redstonewarrior Wrote: 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.
12-30-2013, 11:59 PM
(This post was last modified: 12-31-2013, 12:17 AM by 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. |
|