-
- Это связано с тем, что в PICах операция вычитания как таковая отсутствует. Поэтому для вычитания используется операция сложения с дополнительным кодом уменьшаемого. - Bill(21.10.2013 13:05)
- Неправда. В 16-битниках, о которых и идет речь, есть и ADD, и SUB - каждая со своим опкодом, а "инверсное" поведение CARRY при вычитании сделано для наследственной совместимости с 8-битниками - MBedder(21.10.2013 14:30)
- Еще раз: инструкция SUB есть, только она реализована как сложение с дополнительным кодом. Отсюда и "странное" поведение флажка переноса. Если же не обращать внимание на поведение данного флажка, то разницы никакой не будет. Bill(195 знак., 21.10.2013 14:50 - 14:55)
- SUB именно так реализована ВО ВСЕХ архитектурах, а инверсия переноса - затея мистечковая, дабы тёщу ублажить - MBedder(21.10.2013 15:03)
- Еще раз: инструкция SUB есть, только она реализована как сложение с дополнительным кодом. Отсюда и "странное" поведение флажка переноса. Если же не обращать внимание на поведение данного флажка, то разницы никакой не будет. Bill(195 знак., 21.10.2013 14:50 - 14:55)
- Неправда. В 16-битниках, о которых и идет речь, есть и ADD, и SUB - каждая со своим опкодом, а "инверсное" поведение CARRY при вычитании сделано для наследственной совместимости с 8-битниками - MBedder(21.10.2013 14:30)
- Это связано с тем, что в PICах операция вычитания как таковая отсутствует. Поэтому для вычитания используется операция сложения с дополнительным кодом уменьшаемого. - Bill(21.10.2013 13:05)