Product Development, Many people (myself anyway) write their own application specific libraries in assembly language. When you do this, you can produce very efficient code because of non-specific register usage and tricks. Libraries of these types usually provide an associate C API file for use by C source code. It would really be nice if one could (in the C function prototype) force how the registers and fixed memory are used for passing parameters. For example, existing C51 does this: void Func1( float f1, unsigned int w1 ); f1 - passed in R4-R7 w1 - passed in ?_Func1?BYTE+4 (note the wasted space) IMO, there's no reason at all why 'w1' couldn't be passed in R2R3 ... provided the function implementation requires nothing from the compiler ... i.e. the function is user coded in assembly. My suggestion is a new (surrounding) pragma set for cases like this. It would look like this: #pragma USERSPECPARMS void Func1( float f1, unsigned int w1 ); f1 : R4 // R5,R6,R7 implied w1 : R2 // R3 implied #pragma NORMSPECPARMS The parameter register specification would follow immediately after the function prototype. Now, lets assume you have a function with parameter requirements that exceed the number of registers (8). The interior of the pragma set would understand this: #pragma Func2( float f1, float f2, unsigned int w1 ); f1 : R2 // R3,R4,R5 implied f2 : F0 // Passed in fixed memory, offset 0 w1 : R6 // R7 implied #pragma NORMREGPARMS In this case, we force f1 to be passed in R2-5, w1 to be passed in R6R7, and f2 to be passed in the fixed memory location: "?_Func2?BYTE+0 (note, force it to an offset of 0 in the fixed memory location, thus conserving the otherwise wasted fixed memory parameter size). I realize it would likely require some effort to provide such a feature, but it would be invaluable. People resort to assembly for efficiency. Said efficiency is comprimised if passed parameters must first be extracted from compiler defined fixed memory / registers and then rearranged back into particular register for the most efficient use. Please give this some serious consideration. Best Regards, R. Wey, DI Inc.