new features for __emit

[Daniel-Cortez]

Is this a BUG REPORT, FEATURE REQUEST or QUESTION?:

• Bug Report
• Feature Request
• Question

What happened:
I have a few ideas for the __emit operator, but before implementing them and making a PR I guess it would be better to discuss them here first.

1. Add __emit dump <identifier>.
   This would allow the compiler to retrieve addresses of functions, variables etc. as constant values, which could be useful for initialization of constants and immutable arrays.
   Example:

static const functions[] =
{
    __emit dump func1,
    __emit dump func2,
    __emit dump func3
};

Though I'm not sure if dump would be a proper pseudo-instruction name because in compiler assembly output dump means "put value(s) into the data section", not "retrieve symbol value/address".

2. Allow jumps to naked functions.
   Since the next release is going to have naked functions without prologue and epilogue code, maybe we should allow such functions as arguments for jump instructions?

#pragma naked
NakedFunction() { /* ... */ }
// ...
__emit jzer NakedFunction;

3. Issue an error/warning if data/stack offset is not a multiple of cell size.

__emit load.s.pri 5; // The offset is not a multiple of 4, so this is clearly an error.

This would require addition of new error in sc5.c though (would "not a multiple of cell size" be a good description for it?)

4. Add a new error for invalid IDs in lctrl, sctrl and other instructions.

__emit lctrl -1;

Currently this would make the compiler issue an "invalid range" error, which clearly isn't the right description. But again, I'm not sure how to phrase that error properly.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:
Special thanks to @VVWVV for giving me the idea about the "not a multiple of cell size" error.

Environment:

• Operating System
• Compiler version
• How are you invoking the compiler? Pawno, Sublime, vscode, sampctl or command-line?
• If using sampctl, the version number

[YashasSamaga]

Would it be possible to have compile time evaluation of __emit where it is possible?

Instead of __emit dump sym, what about static const global_arr[] = { __emit const.pri func1, __emit const.pri func2 }?

The number would be evaluated at compile time and return. If the symbol is global, no instructions are written. If it was a local, maybe output the last constant value with const.pri (this is what someone would expect to happen?).

[Daniel-Cortez]

Would it be possible to have compile time evaluation of __emit where it is possible?

If by "where it is possible" you mean in constant expressions, then yes, I think this should be possible. But functions would be required to be implemented before the point of their use in __emit dump, otherwise their addresses wouldn't be known.

Instead of __emit dump sym, what about static const global_arr[] = { __emit const.pri func1, __emit const.pri func2 }?
The number would be evaluated at compile time and return. If the symbol is global, no instructions are written. If it was a local, maybe output the last constant value with const.pri (this is what someone would expect to happen?).

__emit const.pri would imply the value being loaded into the primary register and a const.pri instruction being put into the data section, both would be misleading in constant expressions. Pretty much the same problem as with dump.
Also making const.pri serving two purposes would be too complicated IMO, which is why I suggested dump instead, because this name is not used by any of __emit instructions (initially I was towards __emit const <sym>, but unfortunately this name is too already taken by one of macroinstructions introduced in Pawn 3.2).

[Y-Less]

I'dmuch prefer this as something like addressof(x) (or rather __addressof ). An actual keyword instead of extending an unrelated feature in a strange way (I've written an addressof library, but obviously an intrinsic is better.

[Y-Less]

Actually, there is this, #348, and possibly other required meta data like specifierof(x) etc, all of which would be nice to have, but would all clutter the global namespace (even with proper __ prefix). Maybe a more generic solution like:

#pragma meta name MyFunc

Which can then be combined with __Pragma from #267, then we have an easily extendable solution of:

#define nameof(%0) __Pragma meta name %0

Yes, the original becomes a bit more verbose, but less intrusive and definable. Or, since pragmas are instructions:

__Meta(name, func)
__Meta(address, func)

#if __Meta(address)
     #define addressof(%0) __Meta(address, %0)
#endif

Or something else, I don't like the symbols used for "name" and "address" in that code, but it's a rough idea.

[Daniel-Cortez]

While addressof seems to be a good idea, this question should probably be put aside for the time being as we need a consensus on the naming scheme (and if addressof should even be a separate operator).

Any help with phrasing a proper error description instead of invalid range still would be appreciated. I'll re-quote the question for convenience:

4. Add a new error for invalid IDs in lctrl, sctrl and other instructions.
   __emit lctrl -1;
   Currently this would make the compiler issue an "invalid range" error, which clearly isn't the right description. But again, I'm not sure how to phrase that error properly.

[Y-Less]

There is error 50 - "invalid range", 32 - "array index is out of bounds", and 28 - "invalid subscript (not an array or too many subscripts)". None are quite right, but good examples, giving something like "parameter is out of bounds". Would also need a way to specify lctrl 7 and 8 as valid (for JIT and crashdetect), maybe #pragma lctrl 7.

[Daniel-Cortez]

There is error 50 - "invalid range", 32 - "array index is out of bounds", and 28 - "invalid subscript (not an array or too many subscripts)". None are quite right, but good examples, giving something like "parameter is out of bounds".

That's my whole point. None of the existing errors are quite correct for this situation, so we probably need to add a new one. Speaking of which, how about ID %d is invalid for instruction \"%s\"?

Would also need a way to specify lctrl 7 and 8 as valid (for JIT and crashdetect), maybe #pragma lctrl 7.

That's already been taken care of, __emit recognizes IDs 0 through 9 as valid for lctrl (and for sctrl the valid IDs are 2, 4, 5, 6, 8 and 9). Or you mean we should rather disable IDs 7, 8 and 9 by default and enable them from user code with something like #pragma lctrl 7 on?

[Y-Less]

"Parameter" instead of "ID" to be more generic to any instruction, but otherwise yes.

And my point was more that plugins can add more. Yes 7-9 are covered, but there could be more in the future that should be specifiable.

[Zeex]

Since lctrl 123 is a no-op why check the parameter anyway? could as well just leave it be. Maybe some guy will invent a new meaning for lctrl 100 in some plugin. BTW crashdetect uses lctrl 255.

[Daniel-Cortez]

"Parameter" instead of "ID" to be more generic to any instruction, but otherwise yes.

I wanted to use "parameter" at first too, but it sounds too generic, it can mean anything (data address, stack offset, function address, label) while the error in question is supposed to be issued only for instructions lctrl, sctrl, lodb.i, strb.i, idxaddr.b, lidx.b, shl.c.pri/alt and shr.c.pri/alt, all of which take integer values as arguments. Maybe something more specific like "numeric parameter" would fit better (though it would probably also imply rational numbers)?

And my point was more that plugins can add more. Yes 7-9 are covered, but there could be more in the future that should be specifiable.

Since lctrl 123 is a no-op why check the parameter anyway? could as well just leave it be. Maybe some guy will invent a new meaning for lctrl 100 in some plugin. BTW crashdetect uses lctrl 255.

Probably would be better to keep everything simple and just disable that check for lctrl and sctrl (the only use of it was to make sure the user didn't specify an invalid ID due to a typo or something else) than to clutter the compiler with another #pragma.

[Y-Less]

It is only used for those instructions currently - with "parameter" it could be applied to others as well. Or if not parameter, not ID either - they aren't identifiers in most of those cases. I suppose the correct term is "operand".

[Daniel-Cortez]

It is only used for those instructions currently - with "parameter" it could be applied to others as well.

Not sure what you mean. There's no need to apply this error to other instructions as they already have this:

new var;
emit stor.pri var; // error 001: expected token: "-data offset-", but found "-local variable-"

which is much more informative IMO, as it also tells about operand types.

[Y-Less]

Oh, ok.