#FUSES XINST?

[hello188]

Hi, I am using PIC18F47J53 and PCH compiler 4.127

When I try to compile with #FUSE XINST, it compiles but with warning saying

FEATURE not supported XINST

Does this compiler version not support extended instruction set at all? or Do i have to tweak the compiler settings or something to enable it??

Thank you.

[PCM programmer]

It's just not supported. Don't enable it. If you do, the PIC will run
in an erratic way.

[hello188]

Yea. the code just doesn't work if I enable it.

What I am wondering is that , is there big difference between enabling it and disabling it, assuming that the code was compiled accordingly?

Thank you

[n-squared]

From the PIC18F46J11 manual:
"
1.1.4 EXTENDED INSTRUCTION SET
The PIC18F46J11 family implements the optional
extension to the PIC18 instruction set, adding eight
new instructions and an Indexed Addressing mode.
Enabled as a device configuration option, the extension
has been specifically designed to optimize re-entrant
application code originally developed in high-level
languages, such as C.
"
_________________
Every solution has a problem.

[PCM programmer]

See Collink's explanation of why it causes problems if it's enabled in CCS:
http://www.ccsinfo.com/forum/viewtopic.php?t=43414

[hello188]

Now, I get it. Basically, in order to implement the XINST set, you have to change aspects regarding all the other instructions. So, basically, the maker of the compiler has to re-design their compiling engine almost from the scratch.


I think the PRO version of the new XC8 compiler from the Microchip supports the XINST set.

Will there be huge/noticeable difference between the code generated using XINST code and the one without it?? I wonder it's even worth bothering it if the difference is negligible.


Thank you.

[Ttelmah]

Basically an unanswerable question. It depends totally on whether your particular code would use these features. Gain 'on average', would probably be a couple of percent, but if you happened to want to write recursive code, then the gain is the difference between being able to do this, and not....
Problem of course would then be that you'd have to start worrying about how much stack space is used for this, and probably adding code to avoid overflows, so might well find things running slower. Some of the features would improve certain things a little, actually avoiding some of the restrictions that currently exist, so I'd not be surprised if in the future perhaps compiler V5, would start to use these. However as with all such things I'd expect it to take a year before the feature in CCS is truly stable....

Best Wishes

[ckielstra]

Just some extra info.
I used to work for a compiler builder company where they had compilers for many different processor types. For a relative small company to be able to do this they had developed many generic components that were re-used for every processor type. The PIC hardware however was not supported. Because of its very minimalistic design without stack pointer register it required a completely different compiler approach than for almost all other processors.

Have you ever looked at the GNU set of compilers? Many different processor types are supported, but not the PIC. For the same reason as explained above.

Will the compiled code be more efficient (speed or memory usage)? I don't know. The wider set of instructions will give more optimization options, but don't have huge expectations. Most likely that the more 'traditional' type of stack based compilers will even be slower than the specialized PIC compilers like CCS.

For us, as users, the most important advantage is that more compiler builders will enter the market. And a second advantage is that existing generic code libraries (using recursion) can be easier ported to the PIC processors.