Bringing up the bit shift syntax issue again..
Community Forums/Monkey2 Talk/Bringing up the bit shift syntax issue again..
| ||
| Hi, About 6 months ago in the Syntax Wishlist thread, I asked if we could see Shl/Shr reflect zero-filled operations, and adding Sal/Sar for sign-bit preserving operations. Without an official response to this, I assume that the behavior is preserved from monkey1, which frankly is kinda weird! Particularly Shr, which preserves the sign bit. I'm assuming that this was done to keep platform consistency, but it may not be necessary anymore now that C++ is the primary target. Short of replacing Shl/Shr entirely with << and >>, could we maybe see their behavior changed to reflect their mnemonic? Or, at least be given the option of having zero-fill shifts... (The issue came to mind when talking to someone about mx2's imminent release. They asked me if mx2 would support unsigned types, shorts, etc, and I didn't have an affirmative answer for him. They were concerned about porting code which used bit shift trickery and I told them that it could be worked around mostly without trouble, with the exception of the arithmetic shift right, which gave me trouble in monkey1 and required the use of bitmasks.) |
| ||
| Unsigned numbers are supported, and x Shr y will preserve the sign bit of x if x is signed, otherwise 0 is shifted in. I guess I could add a Sar, but it's not strictly necessary and I think would raise more issues than it solved, eg: Can you use Sar with unsigned numbers? Do you HAVE to use Sar with signed numbers and Shr with unsigned? Shl and Sal are the same thing - I don't know of any language/operation that preserves the low bit when shifting left. I prefer Shl, Shr to << and >> as < and > are used quite a lot in the language already for comparisons and generics. |
| ||
| I too prefer shl/shr syntax to <</>>. so much easier to process (in my head at least) |
| ||
| ZX80 assemblers had a SLI (shift left increment) operator, which shifted a register left and set the lowest bit. It was not intended but arose as a result of a bug in the microcode when the chip was developed. But back then every option that existed was likely to find use. |
| ||
| @Nobuyuki: A small starting point to get an overview: ' basic data types in MX2 MX2 C++ mapping Comment ----------------------------------------------------------------------------------- Void void Object bbObject Bool bool ( typedef bool bbBool ) Byte signed char ( typedef signed char bbByte ) UByte unsigned char ( typedef unsigned char bbUByte ) Short signed short ( typedef signed short bbShort ) UShort unsigned short ( typedef unsigned short bbUShort ) Int signed int ( typedef signed int bbInt ) UInt unsigned int ( typedef unsigned int bbUInt ) Long signed long long ( typedef signed long long bbLong ) ULong unsigned long long ( typedef unsigned long long bbULong ) Float float ( typedef float bbFloat ) Double double ( typedef double bbDouble ) Char unsigned short ( typedef unsigned short bbChar ) CChar char WChar wchar_t Utf8Char char String bbString CString char* (bbCString?) ( CString = Alias for CChar Ptr ) WString wchar_t* ( WString = Alias for WChar Ptr ) Utf8String char* ( Utf8String = Alias for Utf8Char Ptr ) Info taken from Xmas demo v3 => modules/monkey/types.monkey2 => native/ => bbtypes.h C++ mapping for the last 3 types will probably change to bbCString, bbWString, and bbUtf8String respectively. |
| ||
| I would like to have: LSL, LSR, ASL, ASR, ROL and ROR. |
| ||
| @ Mark, Danilo Great, thanks a lot for the info guys. |
   |