Hobo (19.10.2013 16:09, просмотров: 5562)-
- Пример к ниже изложенному :) Bill(200 знак., 22.10.2013 09:45)
- Бит C называется CARRY/notBORROW. (Programmers's manual 2.2.14.1: "при вычитании CARRY = неBORROW"). Заема не было => carry стал единицей. С OV все понятно: байт был отрицательным, стал положительным - testerplus(19.10.2013 17:03)
- Думал, может у профессиональных контроллеров бит С наоборот работает - почитал PIC24 Family datasheet - вроде нет, подскажите плиз, а то мы сами не местные... Hobo(169 знак., 19.10.2013 16:35)
- Это связано с тем, что в 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)