--- Quote Start ---
The definition of __builtin_custom_ini() is in the gcc sources, there isn't anything 'special' about it you could write it yourself. It expends to a single nios instruction.
I've a very similar one:
__attribute__((always_inline))
static __inline__ unsigned int
custom_inic(const unsigned int op, unsigned int a, const unsigned int b)
{
uint32_t result;
__asm__ ( "custom\t%1, %0, %2, c%3"
: "=r" (result) : "n" (op), "r" (a), "n" (b));
return result;
}
for custom instructions where I use the 'regb' field as a sub-opcode
(In particular for supporting all the byte and bit swaps in a single instruction).
The custom instruction number is allocated by sopc builder/qsys when you add the instruction, unfortunately you don't seem to be able to choose your own number [1].
The instruction number is then written to one of the generated .h files.
[1] This is a problem if you are trying to define multiple nios cpu with different (overlapping) sets of custom instructions. Or want to be able to compile code without the sopc/qsys generated header file.
--- Quote End ---
Thanks a lot for your reply. You mean to say the __builtin_custom_ini() function is in-built and we cannot modify them.
One question I have is, how does the application programmer know the macro CRC_CI_MACRO implements the CRC functionality?
From his point of view 'ini' can be any function which takes in an integer as the input and returns another integer.
So does he look into the generated .h file , take the instruction number and use it for the macro ALT_CI_CRC_INST_N ?
Even if he does that how does he know the built in custom ini function implements the CRC?
Any comments towards these lines are really appreciated.
Thank You,
Akhil
Honored Contributor
