2023-07-09 00:04:22 Zarutian_iPad - you're thinking of making your own ROM with a diode array? 2023-07-09 00:04:34 That's getting pretty hard core, man... 2023-07-09 00:06:07 Those little DIP switches are cute. 2023-07-09 01:23:19 I sometimes think a fun little exercise would be to design a processor structure that worked entirely using moves. You'd just have a set of "ports" and your instructions would just move data from place to place. So each isntruction would just be a source and a destination. 2023-07-09 01:23:54 So to do an add, you'd move the operands to alu input ports and hten move the alu output port to the destination. 2023-07-09 01:24:19 Of course, one port would be a RAM address port. 2023-07-09 01:24:55 You'd jump by moving something into the instruction pointer port. 2023-07-09 01:25:25 I think if you supported conditional operations you'd be able to do anything. 2023-07-09 01:29:19 Main problem with such an approach is that it wouldn't exploit "obvious parallelism." In a lot of operations you could do several things at once, but this model doesn't really capture that. 2023-07-09 11:34:36 Actually I suppose you could capture some of that parallelism by running fast and letting each move block momentarily if it needed to in order to have its inputs ready. Then parallel operations would just happen in parallel "naturally." Almost, at least. 2023-07-09 11:35:52 You begin to see how very long instruction word designs evolve - such a word would just be able to trigger several moves which would then happen at the same time. 2023-07-09 11:54:08 One easy way to do conditionals on those designs is to feed the flags and PC into the ALU and increment by one instruction or two instructions depending on the flag 2023-07-09 11:54:33 Versus trying to set up logic to load the PC or not based on flags 2023-07-09 12:18:59 Yes. 2023-07-09 12:26:29 Though depending on how it's set up you might need to fetch an instructon before you can tell if it's conditional or not. 2023-07-09 12:27:05 You could arrange for the conditional decision to apply to the "next" instruction instead of "this" instruction, but then you'd need to be careful with jumps. 2023-07-09 12:27:52 I think this is why the approach in HP calculators is to offer "Increment and Skip if Greater" and "Decrement and Skip if Equal" instructions. 2023-07-09 12:30:40 Ya 2023-07-09 12:31:04 What I'm describing is just having an ALU operation that adds the size of one instruction to a register if carry is set for example 2023-07-09 12:31:07 and 0 otherwise 2023-07-09 12:31:48 then next step is writing that to PC like you would for a jump where the address is held in a register since that is where the ALU writes the result back to anyway 2023-07-09 12:34:42 If youre going for a minimal design that is 2023-07-09 12:34:51 I always think about that with 7400 stuff but doesnt matter if its an FPGA 2023-07-09 12:38:44 Yes. That's not quite a "conditional instruction," though - it's a conditional "skip an instruction." It's different from having the following instruction carry its own condition specifier. 2023-07-09 12:39:15 But like I said, in the latter design you'd have to fetch that following instruction before you knew whether to "not do it" or not. 2023-07-09 12:40:20 Confining that decision process to a few generic instructions which you can then "wrap" other instructions with is the more common approach, i think, but ARM seems to go kind of heavy toward making a lot of instructions conditional. 2023-07-09 12:40:44 On the basis that you may not really WANT to avoid fetching the instruction, because that hiccups your pipeline. 2023-07-09 12:41:58 In my little FPGA Forth processor design I fetched everything, but then skipped over instructions appropriately *in* the pipeline. 2023-07-09 12:43:13 Used to be when I talked about that I had to say that it had only been a "paper design" - barely more than notes, though some of them were pretty detailed. But last year I actually got parts of it running in Verilog. 2023-07-09 12:43:44 The whole fetch side seemed to be working pretty well. 2023-07-09 12:44:29 ACTION only has SKip if Zero instruction in his minimal dual stack machine design 2023-07-09 12:44:53 It's enough. 2023-07-09 12:45:30 I still have a couple of tabs open on that "belt machine" from Mill. That's a pretty interesting design - very very different from either stack or register machines. 2023-07-09 12:45:43 Supports a ton of parallelism very gracefully. 2023-07-09 12:46:16 and it is quite similar in some ways to that "FIFO Forth" we had a slide deck on a couple of months ago. 2023-07-09 12:46:24 That's kind of what the belt is - a data fifo. 2023-07-09 12:47:16 Like I said a few weeks back, though, I'd sure hate to have to program a belt design completely by hand. It just begs for a lot of "software assistance." Lot of bookkeeping that has to be done. 2023-07-09 12:47:38 Because the data moves on every cycle, so something has to keep up with where everything is cycle by cycle. 2023-07-09 12:48:48 Once a data item is on the belt, it no longer changes - it's immutable. That removes a lot of potential timing hazards. 2023-07-09 12:49:59 One thing I don't really get yet, though, is that they brag about being lower power than other designs, and a design that moves all the local data constantly seems like it wouldn't minimize power consumption. 2023-07-09 12:50:16 It's likely that I just don't understand where the big power hogs are in traditional processors. 2023-07-09 12:50:54 I suspect it's NOT in the "straight forward parts" but rather is in all the side logic they use for instruction re-ordering and register renaming and so on. 2023-07-09 12:52:20 It looks to me like they have multiple belts, too, so different threads can each have their own belt. Otherwise it would be necessary to save and restore the belt content on every thread change. 2023-07-09 13:01:14 I think it's pretty evident how they came upon the design - it's a pretty logical outcome of just saying "we want a shit ton of ALUs; how do we keep them all busy?" 2023-07-09 13:01:56 I muse that FlowBasedProgramming will make hetreogenious and/or highly reconfigurable systems inevitable. 2023-07-09 13:03:02 I thin of flow-based programming as kind of on the other end of the parallelism spectrum. As in "types of parallelism." It's parallelism, but it's a very coarse-grain parallelism. 2023-07-09 13:03:22 The belt machine seems a lot more fine-grain to me. 2023-07-09 13:04:04 Flow based programming seems to fit typical modern processors better to me. 2023-07-09 13:04:06 there are other factors than just parallelism that play into it 2023-07-09 13:04:34 You can think of your cores as doing entirely different sorts of work. 2023-07-09 13:04:43 Even if those are stages in some overall process. 2023-07-09 13:15:12 factors such as more ease of programmability and understanding 2023-07-09 13:29:21 Yeah, it definitely excells in those aspects.