> > Perhaps they do prefer #1, but would they prefer it enough to accept a
> > slower maximum clock rate on their PIC because of the additional
> > hardware required in the ALU loop?

> It can significantly slow down the CPU because it is in the critical "ALU
> loop" which you want to make as simple as possible.

Oh come now.  "Significantly" I find difficult to believe - there are
plenty of CPUs that are no slower than a PIC that use the "traditional"
carry=borrow sense.  Besides, don't you end up needing the inversion
hardware for the SBC instruction instead, anyway?  Still in the "ALU loop"?
Doing the inversion when CARRY is generated seems LESS subject to timing
constraints than having to modify the SBC path - you're pretty much
guaranteed a fetch and decode cycle before you'll need the result, whereas
in SBC, once it decides it needs the CRY flag, it needs it NOW...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.