Attachment:
NVCZ.png [ 81.59 KiB | Viewed 10241 times ]
Let the complaints begin...
Looking back upon this, I see the Overflow XOR gate could have been 5V LVC.
Inputs are 6nS earlier than full results, so plenty of time for the slower gate.
Also plenty of time to buffer the Carry output. Prolly should have done that.
The Zero chain can't progress any faster than Carrys or Borrows are resolved.
But if resistors, buffers, or CLA even out that timing, splitting Zero might help.
No doubt a BLA Borrow tree could be tricked to omit XORvert B at the front end.
But I wonder if a ZLA tree is possible. Can we predict Zero just from raw inputs?
ZLA for math maybe, but to work also for logic functions seems impossible.
Any progress on Decimal? Cause I'm creatively empty and pleading the 2A03,
interrupt, microcode, something, any cheat but actual decimal hardware to
further complicate and slow the works...
Only three and a half MUX repeat per slice. Others and XOR occur once only.
Half an S4S5 MUX is availaibe to another slice. Why I count three n' a half.
Might could merge CARRY8 with BORROW8 using the /OE pins instead.
Let me think on that awhile. Rotates and shifts might still want MUX...
Does it matter specifically what nonsense V produces during rotations?
If any nonsense will do, I am surely producing it. 2G53 controlled by S5
could force the overflow output low, but is there any need?
The bit7 shifter producing an oVerflow XOR input might be redundant to
one producing ARITHMETIC7. Doesn't save any IC to Muntz away a half
MUX, but one less load for the chains. More authentic roto-nonsense-V
than to produce nothing or duplicate CarryOut. Doubt it matters...