[PRoSToTeM@]

http://x86.renejeschke.de/html/file_...86_id_285.html

The 8086 does not mask the shift count. However, all other IA-32 processors (starting with the Intel 286 processor) do mask the shift count to 5 bits, resulting in a maximum count of 31. This masking is done in all operating modes (including the virtual-8086 mode) to reduce the maximum execution time of the instructions.

http://www.intel.com/content/dam/www....pdf#page=1263

The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used).

On AMD I have the same behavior.
Do we use AMXX on non-x86 arch? Also I think amxmodx should ensure shiftCount & 31.

[fysiks]

Originally Posted by PRoSToTeM@ Also I think amxmodx should ensure shiftCount & 31.

AMX Mod X should do nothing of the sort. A language is not there to prevent everyone from making all mistakes.

And, regardless of how unlikely a future update would break it, it is still better to properly understand the there are only 32 bits in the cell and to handle that in the code itself for clarity.

Of course, you can do whatever you want with your own code so I'll stop here.

[PRoSToTeM@]

Originally Posted by fysiks AMX Mod X should do nothing of the sort. A language is not there to prevent everyone from making all mistakes.

AMXX Pawn can ensure it like C#. Why not?
https://msdn.microsoft.com/ru-ru/lib...(v=vs.71).aspx

When the type of x is int or uint, the shift count is given by the low-order five bits of count. In other words, the shift count is computed from count & 0x1F.

[Bugsy]

I could have sworn in the past that when I did a 1 << 32 shift, the result is 0. This was a few years ago and was also while I was on a 32-bit system. Now that I'm running a 64-bit OS and a later version of AMX-X, maybe this is why the shift now rotates back to bit 1 @ 1 << 32? There were quite a few of us in a discussion about this 1 << 32 issue (myself, joaquimandrade, fysiks? connormcleod?) and we came to the conclusion that id & 31 was the most efficient way to handle a 1 << 32 shift. If this was a standard, why would nobody speak up about this? I wonder if Arkshine could provide any feedback on this.

I'm with fysiks on this one though, logically 1 << 32 should push the bit out of the cell.

Using this, if you set the 32nd bit (31 in this calculator) and shift it to the left, the resulting value is 0, as expected. http://calc.penjee.com/

[fysiks]

Originally Posted by PRoSToTeM@ AMXX Pawn can ensure it like C#. Why not? https://msdn.microsoft.com/ru-ru/lib...(v=vs.71).aspx

Just because you can doesn't mean that you should.

[Depresie]

AMX Mod X should do nothing of the sort. A language is not there to prevent everyone from making all mistakes.

Thank You !