12-23-2014, 10:16 PM
I should like to state (after my long hiatus) that I agree with GISED_Link to some extent. You should try to avoid mapping a real opcode to 0x00 if you have the room in your IS to do so. Then, you can map a memory read error or a STOP to the opcode of 0x00. If you have microcoding, then not having a 0x00 opcode becomes more important because much of the math that most microcoding performs can have issues working around zero for either pointers or opcodes. In programming, a common practice is to set something to zero (like a pointer), perform an allocation, and then see if it isn't zero, meaning that it worked, or is zero, meaning that it failed and it's time to perform the exception routine and commit software suicide. In microcoding, a similar thing happens, you allocate 0 to the micro-operation being considered, allocate a temporary space for it on the table (at zero, oddly enough), then run the opcode through the tabling program, and it gives it a nonzero micro-operation in return at a nonzero table address for your instruction pointer to work with. If zero remains in either location, you know you have a problem, but if zero actually is something that can be returned as a valid and useful output, then it's your best guess as to whether or not your allocation worked or failed. Therefore zero is a common sign of an error in allocations and basically all other programs, to the point that x86 has a FLAG that is set if the output is zero simply because a zero output is bad juju. So, from a programming standpoint, I would say to avoid zero for consistency, if nothing else.
Now, for your computer, a really nice thing about mapping STOP to 0x00 is that an opcode execution could be wired as the bitwise OR down the entire opcode AND'ed with the clock all added to the instruction pointer with ADDC being invoked by a starting signal (basically: if there is an opcode at line x or a start signal at any point, push 1 to the carry in of the instruction pointer accumulator). This is a convenient way to make the STOP opcode 0x00 without adding any loss to overall throughput and adding one phase to the instruction pointer's pipeline. It is therefore unrelated to the execution pipeline and gives you an opcode usually reserved for a microcoded environment.
I can tell you how to do it in general pretty easily, it will take me a bit of thinking to put it in terms of this specific instruction set. I have to be somewhere right now, but tell me what you want to know and I'll explain it (this one is fairly simple in it's general form on a stack machine.)
Now, for your computer, a really nice thing about mapping STOP to 0x00 is that an opcode execution could be wired as the bitwise OR down the entire opcode AND'ed with the clock all added to the instruction pointer with ADDC being invoked by a starting signal (basically: if there is an opcode at line x or a start signal at any point, push 1 to the carry in of the instruction pointer accumulator). This is a convenient way to make the STOP opcode 0x00 without adding any loss to overall throughput and adding one phase to the instruction pointer's pipeline. It is therefore unrelated to the execution pipeline and gives you an opcode usually reserved for a microcoded environment.
LordDecapo Wrote:I do like the repeat inst. Is there a way to tell it to repeat like several instructions in a row over and over? Like "repeat inst 1,2,, and 3, 10times"?
I can tell you how to do it in general pretty easily, it will take me a bit of thinking to put it in terms of this specific instruction set. I have to be somewhere right now, but tell me what you want to know and I'll explain it (this one is fairly simple in it's general form on a stack machine.)