- ABORT
- ABORT"
- ABS
- ACCEPT
- ACTION-OF
- AGAIN
- ALIGN
- ALIGNED
- ALLOT
- AND
- BASE
- BEGIN
- BL
- BUFFER:
- [
- [CHAR]
- [COMPILE]
- [']
- CASE
- C,
- CELL+
- CELLS
- C@
- CHAR
- CHAR+
- CHARS
- COMPILE,
- CONSTANT
- COUNT
- CR
- CREATE
- C!
- :
- :NONAME
- ,
- C"
- DECIMAL
- DEFER
- DEFER@
- DEFER!
- DEPTH
- DO
- DOES>
- DROP
- DUP
- /
- /MOD
- .R
- .(
- ."
- ELSE
- EMIT
- ENDCASE
- ENDOF
- ENVIRONMENT?
- ERASE
- EVALUATE
- EXECUTE
- EXIT
- =
- FALSE
- FILL
- FIND
- FM/MOD
- @
- HERE
- HEX
- HOLD
- HOLDS
- I
- IF
- IMMEDIATE
- INVERT
- IS
- J
- KEY
- LEAVE
- LITERAL
- LOOP
- LSHIFT
- MARKER
- MAX
- MIN
- MOD
- MOVE
- M*
- -
- NEGATE
- NIP
- OF
- OR
- OVER
- 1-
- 1+
- PAD
- PARSE-NAME
- PARSE
- PICK
- POSTPONE
- +
- +LOOP
- +!
- QUIT
- RECURSE
- REFILL
- REPEAT
- RESTORE-INPUT
- R@
- ROLL
- ROT
- RSHIFT
- R>
- SAVE-INPUT
- SIGN
- SM/REM
- SOURCE-ID
- SOURCE
- SPACE
- SPACES
- STATE
- SWAP
- ;
- S\"
- S"
- S>D
- !
- THEN
- TO
- TRUE
- TUCK
- TYPE
- '
- *
- */
- */MOD
- 2DROP
- 2DUP
- 2/
- 2@
- 2OVER
- 2R@
- 2R>
- 2SWAP
- 2!
- 2*
- 2>R
- U.R
- UM/MOD
- UM*
- UNLOOP
- UNTIL
- UNUSED
- U.
- U<
- U>
- VALUE
- VARIABLE
- WHILE
- WITHIN
- WORD
- XOR
- 0=
- 0<
- 0>
- 0<>
- \
- .
- <
- >
- <>
- #>
- <#
- #
- #S
- (
- ?DO
- ?DUP
- >BODY
- >IN
- >NUMBER
- >R
6.1.1805 LSHIFT l-shift CORE
Perform a logical left shift of u bit-places on x1, giving x2. Put zeroes into the least significant bits vacated by the shift. An ambiguous condition exists if u is greater than or equal to the number of bits in a cell.
Testing:
T{ 1 1 LSHIFT -> 2 }T
T{ 1 2 LSHIFT -> 4 }T
T{ 1 F LSHIFT -> 8000 }T \ BIGGEST GUARANTEED SHIFT
T{ 1S 1 LSHIFT 1 XOR -> 1S }T
T{ MSB 1 LSHIFT -> 0 }T
ContributeContributions
ruv
[335] An ambiguous condition in LSHIFTRequest for clarification2024-02-05 15:46:57
6.1.1805 says:
An ambiguous condition exists if u is greater than or equal to the number of bits in a cell.
Why does this ambiguous condition exist? Do we have implementations that produce some side effects or other result than 0 if u is greater than or equal to the number of bits in a cell?
Rationale. The result of a single shift by u bits should be always equivalent of u sequential shifts by 1 bit, regardless of u.
Then, could this ambiguous conditions be removed?
ruv
Well, I just checked. Systems typically consider only the low-order bits of u corresponding to the cell size, and ignore the high-order bits.
So this ambiguous condition probably cannot be eliminated.
ThomasPornin
In fact there is some variation among architectures. x86 use the least significant n bits
ThomasPornin
(Oops sorry clicked too early)
x86 use the least significant n bits, except the original 8086 and 8088 when the shift count is in the CL register, in which case all 8 bits would be used (this was how the 80186 was distinguished from the 8086). The use of just n bits is common enough among modern archs, but 32-bit ARM (e.g. in ARM Cortex M0+ or M4 microcontrollers) is an exception, since it uses the low eight bits of the operand (but still ignores the higher bits). Enforcing a result of zero when the count is higher than the register width is certainly doable but requires some extra specific instructions, so it is certainly not done in general.