12-31-2013, 12:20 AM
This is what I said cut but they won't stop with the Standard IS!!
12-31-2013, 12:20 AM
This is what I said cut but they won't stop with the Standard IS!!
12-31-2013, 02:09 AM
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)
12-31-2013, 10:08 AM
(12-30-2013, 11:59 PM)Cutlassw30 Wrote: 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. (12-30-2013, 11:59 PM)Cutlassw30 Wrote: 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. (12-30-2013, 11:59 PM)Cutlassw30 Wrote: Then for branches. 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. (12-31-2013, 12:20 AM)Chibill Wrote: 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? (12-31-2013, 02:09 AM)VirtualPineapple Wrote: 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.
12-31-2013, 01:07 PM
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. (12-31-2013, 01:07 PM)Cutlassw30 Wrote: 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).
12-31-2013, 02:51 PM
(This post was last modified: 12-31-2013, 02:52 PM by 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.
12-31-2013, 05:05 PM
I resist this because I remember this past when you tryed this before.
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.
12-31-2013, 10:26 PM
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
12-31-2013, 11:31 PM
(12-31-2013, 10:26 PM)snugglycreeper9 Wrote: As for the character thing, I have a character set I call the SSBCS for Standard Six Bit Character Set: I would just use standard 8 bit ASCII. |
|