Резултата е "Address Error trap"
Това нещо работи, когато вместо деление е +, - или *
Ако fas & tam са integer, работи, но резултата е цяло число. (16.00000)
PIC24HJ128GA506A на 40 Mips, MPLAB IDE 8.92 без оптимизации, с опция "Large code model" (128kB flash)
Това е част от голям проект, който си работи, но се налага да се добавят някой нови функции към устройството. На други места в програмата има подобни сметки, които си работят.
Формулите са по-сложни от примера по-горе, но и той не работи, като го компилирам вместо онези формули.

P.S. При компилиране не дава ниакаква грешка, но при симулация влиза в "AdressЕrror" прекъсване, а като го записах в проца (първия път, без да подозирам, че нещо не е наред), започна да се рестартира. Пробвах го с C30 v3.31, C30 v3.25 i xc16 v1.21 - няма разлика.

Ако добавиш "0" след десетичната точка ?

Същата работа!

В ПИКльовците е само емулация - пускаш го с дебъгера и виждаш къде му е проблема - много вероятно да е бъг в библиотеката на компилатора - пък ако не ти се занимава (то си е зор и си иска опит такова дебъгване) изолирай малка програмка която се дъни и го пращай на микрочип да си го анализират

Като изолирам формулите в отделен проект, всичко работи. Даже и другите подобни формули в този същия проект, но в други процедури си работят. По-склонен съм да мисля, че проблема е в задклавиатурното устройство, отколкото в компилатора, но не мога да измисля какво съм осрал За това писах тука - някой може да даде идея, която да проработи!
То в тия жеги само това е спасението:

Или буфер или стека си омазал... или буфер който е омазал стека:) Сложи брейк преди да умре и дебъгвай стъпка по стъпка в асемблера и виж на коя инструкция умира... или като иде в трапа, виж стека на кой адрес е възникнало изключението.

Стека май генерираше прекъсвания за ъндер/оверфлоу ... иначе като едното нищо може да е заради това - това са най мръсните грешки

Тествай ако си извел изчислението в отделна функция да:
* предаваш данните за променливите по различни начини - поменливи/указатели
* вътре в нея да предефинираш променливи идващи ти от указатели

срещал съм подобен бъг при много голям сорс и евентуално силно намаляла RAM.

Ето 2 картинки на ситуацията. Първата е точно преди да "гръмне", а втората след това.

Малко вероятно е една такава операция сама по себе си да направи такъв проблем. До колкото съм имал досег с този вид грешки, работата става при пренасочване или при опит за четене от точно определена клетка.
Пример:

Не съм сигурен за това как се получават тези грешки, понеже при мен на симулация така и не можах да докарам такава, но на практика гърмеше през час.
Опитай да добавиш някаква проверка на резултата!
Поздрави!

Позабравил съм 24-ките, обаче скоро имаше и друга тема за гърмене, беше с 32-ки, мисля проблема е същия, неподравнен адрес в масив, в който се слага цяла дума.
По сложените картинки, имаш инструкция mov [--W15],W12, вижда се w15=0x14CC, като направи предекремента, съдържанието/адрес в масив?/ става нечетно, т.е. неподравнено на дума, и следва гарантиран гърмеж с ADDRESS ERROR.