Re: [PATCH] left shift of negative value do_binop src/arith_yacc.c:111:12

Steffen Nurpmeso wrote in
 <20250820211130.r-9ZHphA@steffen%sdaoden.eu>:
 |Harald van Dijk wrote in
 | <[email protected]>:
 ||On 20/08/2025 15:49, Steffen Nurpmeso wrote:
 ||> Harald van Dijk wrote in
 ||>   <[email protected]>:
 ||>|This is what I was referring to with "subtly changing behaviour that
 ||>|differed across architectures". This behaved differently across
 ||>|architectures, taking only the low bits of the shift count is what x86
 ||>|does but is not universal, and I did not think it would be sensible to
 ||>|implement that on other platforms where it never worked that way. The
 ||>|behaviour I picked is what would have been the result if excessive shift
 ||>|counts hadn't been explicitly undefined, it's simply that e.g. a shift
 ||>|by 123 is equivalent to 123 shifts by 1.
 ||> 
 ||> Ok, but i am not with you regarding that then.  (Do you can name
 ||> "other platforms"?)
 ||
 ||It has been about six years since I looked at that so I don't remember 
 ||exactly. I think it was most likely 32-bit ARM where $(( 1 << 65 )) 
 ||would result in 0.
 |
 |I see -- thanks.  No 32-bit ARM all around here, i think i will
 |finally install an AlpineLinux armv7 VM as soon as possible!

Actually ARM in general seems to act like that, i looked at [1]
for aarch, the ARMv7 docu (newest is PDF anyway) was a bit cryptic
(it only says 1<=X<=31, and that 0==move instruction).
Well good to know, this is then of course different behaviour, if
the greater-than hits.  Though the doc says they inspect a byte
only, if i understood this right, and i wondered how they get
there (i did not know ARM can access "partial registers"), to
compare only 8 of 32/64 bit, in the register case.  Maybe it is
doc misunderstanding.  I should maybe boot an aarch VM and check
it out, ie, if i code ASM, whether say 0x101 is treated as "1", or
as an excess, since the entire register value is 257, say.
Well i do not know.
I like how Alpha, Risc, x86 do it.  Seems easy and cheap.

Anyway, for the MUA, the vexpr command that also offers saturated
and unsigned arithmetic documented "[f]or the bitwise shifts, the
saturated maximum is 63", it is otherwise overflow error, and for
the shell arithmetic i now explicitly document "(Only the 6 least
significant bits of the shift operand are used.)", and so it is
"defined behavior" for this code base of mine.

  [1] https://developer.arm.com/documentation/dui0801/l/A32-and-T32-Instructions/Shift-operations

Thanks!  And Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)