И изгледжа в C18 това което ползваш като функции е написано с ползване на повечко рам.

...Ама не виждам защо не ползваш 24-ки/дсПик като вече имаш опит с тях - там поне няма такива глупости.

Имаше една оптимизация, като я махнеш харчеше по-малко flash, мисля беше procedure abstraction

Има и трик за прекъсванията, по подразбиране C18 запазва едни 20-тина байта, които ги използва за математически операции. Обаче ако в прекъсванията нямаш сложна аритметика, компилатора не ги използва и няма смисъл да се запазват. Опцията е:
#pragma interrupt InterruptHandlerHigh nosave=section("MATH_DATA")

То умножението в случая е точно в прекъсването, ама и не само там.

Ако имаш сметки в прекъсване не е добре работата.

Ама работата не е добре само под C18

Под XC8 ц умножението на парче, проблема е никакъв.

Linux DesktopPC 2.6.32-45-generic #102-Ubuntu SMP Wed Jan 2 21:53:06 UTC 2013 i686 GNU/Linux
Disassembly Listing for v2
Generated From:
/home/../temp/mcc18_mul_example/dist/debug/production/mcc18_mul_example.production.cof
Feb 1, 2013 11:16:12 PM

--- /opt/microchip/xc8/v1.12/sources/wmul.c -----------------------------------------------------------
1: unsigned int
2: __wmul(unsigned int multiplier, unsigned int multiplicand)
3: {
4: unsigned int product = 0;
FF9C 6A05 CLRF product, ACCESS
FF9E 6A06 CLRF 0x6, ACCESS
5:
6: do {
7: if(multiplier & 1)
FFA0 A001 BTFSS multiplier, 0, ACCESS
FFA2 D004 BRA 0xFFAC
8: product += multiplicand;
FFA4 5003 MOVF multiplicand, W, ACCESS
FFA6 2605 ADDWF product, F, ACCESS
FFA8 5004 MOVF 0x4, W, ACCESS
FFAA 2206 ADDWFC 0x6, F, ACCESS
9: multiplicand <<= 1;
FFAC 90D8 BCF STATUS, 0, ACCESS
FFAE 3603 RLCF multiplicand, F, ACCESS
FFB0 3604 RLCF 0x4, F, ACCESS
10: multiplier >>= 1;
FFB2 90D8 BCF STATUS, 0, ACCESS
FFB4 3202 RRCF 0x2, F, ACCESS
FFB6 3201 RRCF multiplier, F, ACCESS
11: } while(multiplier != 0);
FFB8 5002 MOVF 0x2, W, ACCESS
FFBA 1001 IORWF multiplier, W, ACCESS
FFBC E1F1 BNZ 0xFFA0
12: return product;
FFBE C005 MOVFF product, multiplier
FFC0 F001 NOP
FFC2 C006 MOVFF 0x6, 0x2
FFC4 F002 NOP
13: }
FFC6 0012 RETURN 0
--- /home/../temp/mcc18_mul_example/src/main.c ----------------------------------------------------
1: #include <p18cxxx.h>
2: #include "Integers.h"
3: #include "fuses.h"
4:
5: void main(void) {
6: volatile int a,b;
7: volatile long c;
8: a = 38342;
FFC8 0E95 MOVLW 0x95
FFCA 6E0C MOVWF 0xC, ACCESS
FFCC 0EC6 MOVLW 0xC6
FFCE 6E0B MOVWF a, ACCESS
9: b = -30342;
FFD0 0E89 MOVLW 0x89
FFD2 6E0E MOVWF 0xE, ACCESS
FFD4 0E7A MOVLW 0x7A
FFD6 6E0D MOVWF b, ACCESS
10: c = a * b;
FFD8 C00B MOVFF a, multiplier
FFDA F001 NOP
FFDC C00C MOVFF 0xC, 0x2
FFDE F002 NOP
FFE0 C00D MOVFF b, multiplicand
FFE2 F003 NOP
FFE4 C00E MOVFF 0xE, 0x4
FFE6 F004 NOP
FFE8 ECCE CALL 0xFF9C, 0
FFEA F07F NOP
FFEC C001 MOVFF multiplier, c
FFEE F007 NOP
FFF0 C002 MOVFF 0x2, 0x8
FFF2 F008 NOP
FFF4 0E00 MOVLW 0x0
FFF6 BE08 BTFSC 0x8, 7, ACCESS
FFF8 0EFF MOVLW 0xFF
FFFA 6E09 MOVWF 0x9, ACCESS
FFFC 6E0A MOVWF 0xA, ACCESS
11: while(1);
12: }

Очевидно. Ама работата не е добре само под C18, защото вика подпрограма за умножение, а не слага кода директно в прекъсването. Под XC8 ц умножението на парче, проблема е никакъв.

А то е PID алгоритъм - там му е мястото.

Цъ... в прекъсване само елементарни логически неща, set, clear....

Защото?

Сметките на PID регулатора определено нямат никакво място в прекъсване.

Реших да проверя твърдението ти:
...
Kодът от примерa за C18 го компилирах с XC8 v1.12 PRO и се оказа, че XC8 генерира софтуерно умножение.
Всички отпимизации са включени. По всичко изглежда, че поне още 1-2г. няма и да помисля за XC8.
На един по-голям проект за PIC18F26K80 ми изкара хиляди грешки, пък уж можел да работи в режим C18 компилация.
XC8 изглежда ще да е нито риба, нито рак, смесица от концепциите на Hi-Tech PICC18 с Microchip C18. Почти съм убеден, че ако с XC8 компилирам код за PICC18 и там ще ми избълва хиляди грешки.