I am assuming that Geri is expecting that it will a) run the code exactly as written (without concern for the efficiency, because, hey, a simple op code has to run fast, right?) without doing any of those sort of of things, and b) be able to run the subleq opcode in a single, short cycle, with no pipelining, instruction and data caching, branch prediction, microcoding, etc. and get as good or better performance than a 'super complex' design that, you know, had instructions that can be implemented in a simple circuit such as an adder, a negator, a Not Or, or a move to register.
I didn't choose those by accident; they are all operations required in a naive implementation the Subleq instruction. The adder is needed twice, in fact. Assuming you are using two's complement, the subtract is a negation (which in turn is an increment - basically a single bit add-with-carry on the zero bit - followed by a NOT). This is followed by the compare, and since this is subleq and not subeqz, it needs a general comparison, which is usually implemented using a subtract followed by a compare to zero. The compare itself is just a NOR with n inputs where n is the bit width, producing a single bit value for the result.
You will also need to decode the implicit operands into a set of three registers, two for the values to be operated on and the third for the target. You also would need an instruction register, and every instruction needs to end with the IP being either incremented or loaded with the branch target - in practice, it might be easier to have it do the increment in parallel a fourth hidden register, and use the results of the multi-NOR to select which of the two target address registers to load into IP.
All of this is without considering the massive amount of content-addressable memory you would need for caching these operands, because even with the sort of process you are likely to have access to, a load from memory would take at least a few hundred CPU cycles.
This is just off the top of my head; there are surely more efficient implementations that could be used. The thing is, anything like that would require time and effort, and Geri doesn't seem to really grasp that just because an idea is simple, it doesn't mean that it is a good idea. As both Brendan and I have told you repeatedly, the overall result of this in silicon would be at least as complex as any other current-day microprocessor, and would still never perform as well.
But all that is besides the point. Even for a straightforward, naive implementation such as I just described, designing the circuits is only the first step in developing a new IC, and by no means the longest. For an FPGA, yes, that is most of it, but it isn't even close to that for a custom ASIC, never mind a full IC implementation. And for that ground-up IC, the process costs millions (in either USD or Euros) just for creating a mask, as I have already stated. There are maskless process, true, but those cost even more - those costs are something you are going to get around, period.
Also, Geri? Please tell me you haven't given these people any money. The way you describe what they told you seems terribly suspicious to me, though that might be just my cynicism talking.
_________________ Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF Ordo OS Project Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
Last edited by Schol-R-LEA on Fri May 12, 2017 11:00 am, edited 2 times in total.
|