Inserting assembly instructions from Pawn 4 scripts in compilation

[leScythekill]

Since commit 57f7de9, the #emit instruction has been removed from Pawn. Is there any equivalent to insert AMX Assembly instructions directly in compile-time?

Thanks.

[Y-Less]

I believe it was just entirely removed as a feature, rather than changed. However, if you know the commit it happened you could revert it*. Or there is a 3.x fork here:

https://github.com/pawn-lang/compiler

Which has greatly expanded the abilities of #emit by adding __emit as well, as a higher level construct. It can be used as a statement or expression, not just a directive. Could be worth looking at bringing that forward for a more modern integrated replacement.

* I'm not sure how much the p-code changed between 3 and 4. If it hasn't, which would be good for AMX stability, replacing it shouldn't be too hard.

[leScythekill]

Thanks for replying.

I was looking for something that's similar (or equal) to #emit (or your compilers __emit, even) in Pawn 4, but as you said, looks like it's been entirely removed after said commit. Appreciate you all are still maintaining older releases, though.

@compuphase not to bother you or anything, but why was the #emit directive removed? Hope you get to see this, and maybe even as Y_Less mentioned, consider adding a modern #emit to newer Pawn releases, like __emit!

[compuphase]

#emit was added, initially as an undocumented directive, for me to make it easier to validate the implementations of the abstract machines (to check whether every P-code instruction did exactly what it was supposed to do). I removed it in version 4, because I considered that the (improved) peephole optimizer might get confused about an unexpected instruction in de code sequence, up to the point of generating invalid code.

[Y-Less]

it's awful, I know, but that's not because of Pawn or #emit

Care to justify that?

[Y-Less]

Though there are really two questions there:

1. If it is awful, why is it a good example of the things you can do with #emit? Surely that would make it an argument against #emit etc - look at all the terrible things it did.
2. If those features aren't awful, then the better request would be to have them upgraded to first-class (compiler) support. So that inline etc aren't just pre-processor and assembly magic, but real language features; which is still an argument against #emit.

[Y-Less]

Well yes, that is partially true (sorry, I'm just very used to the "YSI bad" crowd, who simply parrot that because they heard a rumour that there was once a bug somewhere). Some of the code could undoubtedly be improved, but a lot of the stranger parts are written that way for a reason - usually because it's the only way to bypass some compiler limitation or bug. For example, the macros are almost unreadable 1. just because there's no way to make them readable (they're very close to regex the way I use them) but also because 2. the compiler has (had) a line-length limit of 511 characters, which I very frequently hit with some of the more advanced replacements. Thus I had to save every character I could, which was sadly at the expense of readability.

[namazso]

The reasoning for removal is understandable, but it would be really great if we could instead get a better alternative, like fully assembly functions that aren't optimized / tried to be optimized. This way worked for C/C++ for a very long time (although separate c/S files linked together in that case). I think functions like numargs and getarg could be better implemented as stocks with assembly, rather than having to have natives for them.