| ??? 12/14/07 23:55 Read: times |
#148253 - careful now! Responding to: ???'s previous message |
You're starting to remind me of the government ... endless growth won't help anyone here.
After all, while this is a learning experience, I'm concerned about what you may learn. Unlike software, where you get paid by the line, there's no point in consuming ALL the resources ... How does it help you to duplicate resources that are already inherently addressable? Russ Cooper said:
Jan said:
... but then you want to indicate writing to ACC in the description rather than writing to "internal memory" at address. Similar of course applies to all SFRs. On the other hand, R0 & R1 are a different story; you might want to have them BOTH in internal RAM and as separate registers, writing simultaneously to both, and reading from either as needed. Actually, I was already planning to duplicate several of the registers as you are suggesting for R0 and R1. Again, this does not show up on the diagram yet, but will when I get around to detailing the block called "Internal Memory". Right now, I think it makes sense to put the following both in the internal RAM and in separate, dedicated registers: R0 and R1 as you suggested, so that they can be easily used for indirect addressing. ACC because that shortens by one clock all of the instructions where A is the source operand. SP so that it can easily be used for pushes and pops and calls and returns. DPTR so that it can easily be used for indirect addressing. Some or all of PSW so that the bank bits and various other flags are easily available. I imagine this list will change somewhat as I work out all the details. I'd not see bit operations as a separate ALU, rather, generate the proper constant (0x01, 0x02, 0x04,..., 0x80) and run the whole byte through the ALU. You are right. I have thought about this some more and the whole idea of the BLU is stupid. Be prepared for fierce and unfair criticism. But delivered with love and compassion, right? :) I had a day trip to San Diego today, and so had a few hours of time sitting in airports and on the plane to start thinking about the insides of the "Internal Memory" block. A lot of it seemed pretty straightforward, but I got hung up trying to decide how to handle the PSW. It's different because of the way some of its bits get set by CJNE and the add and subtract instructions. More to follow on this subject. Compare is really an XOR, isn't it? If you XOR and then behave as you would in JNZ, wouldn't that do the job? Another option would be a subtract but don't update A. An ALU has a zero status, right? Likewise, <CLR (whatever)> is just an XOR of (whatever) with (whatever), right? There are many ways to skin a cat, but using what's already available saves the effort of building yet another knife. -- Russ
What's the reason for duplicating registers whose contents can be routed in multiple directions? If you build an ALU that muxes its inputs from the available resource pool, and is capable of loading as well as of incrementing/decrementing DPTR, and SP, and other destinations, and loading and incrementing PC, it clearly has to contain a 16-bit Adder/Subtractor. If you think about the ALU as the intersection of lots of logic paths, like a railroad yard, and the controlling state machine(s) as providing the steering controls to those logic paths, you'll see that data can be sourced and sunk by the same resources at oposite ends of a single operation. If you fetch program memory in wide chunks, accessing it for interpretation sometimes in 32-bit (or wider) word-wide parallel, and sometimes as bytes, you'll have access to plenty of data for single-cycle as well as out-of sequence and concurrent processing. Those features might require additional resources. I'm not sure that duplicating mapped resources will help. Now, since this is a learning effort, so go ahead and explore the paths you see leading in the direction you want to go. You know, of course, that you needn't try what I'm telling you unless it appeals to you. I'm pretty sure that if I ever expend the effort to build an 805x in programmable logic, it will be of this sort, though. So long as I can buy a chip for 10-20% of the smallest FPGA, it's not likely I'll build one in FPGA unless I need lots of task-specific hardware to go with it. In the meantime, instead of making the chips more economical, the makers just make 'em bigger, so over time, the smallest FPGA's are 100x the size (and, unfortunately, cost) that I need rather than merely 10x. RE |
