VHDL Issue Number: 2004 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: Definition of SLA doesn't make sense Relevant_LRM_Sections: 7.2.3 Related_Issues: Key_Words_and_Phrases: SLA Authors_Name: Paul Graham Authors_Phone_Number: Authors_Fax_Number: Authors_Email_Address: pgraham@cadence.com Authors_Affiliation: Authors_Address1: Authors_Address2: Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 04 August 2000 Date Analyzed: 28 October 2004 Author of Analysis: Chuck Swart Revision Number: 4 Date Last Revised: 20 July 2005 Description of Problem ---------------------- The definition of sla in the 1993 LRM is kind of weird. It basically preserves the parity bit of the left input, so that, for bit vectors: "001" sla 1 evaluates to "011" which might be interpreted as 1 sla 1 == 3 etc. I have never seen a computer opcode which implements this function, though sll, srl, and sra opcodes are ubiquitous. ? Proposed Resolution ------------------- Why not just define sla to be the same as sll (as in Verilog) VASG-ISAC Analysis & Rationale ------------------------------ The SLA operator was added to provide a symmetric set of left and right shift operators. As currently defined, these operators make no assumptions about whether the left bit of a bit vector or the right bit is signed. Notice that these operators are only defined for vectors of type bit or of type boolean. The intent is that all shift operators can be overloaded to achieve any desired semantic interpretation. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change is needed for the current version. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change is needed for future versions. However, there are currently attempts to extend the shift operators to a larger class of types. If these extended definitions treat the predefined SLA operator for these types in a different way than the existing LRM states, then there will be a conflict between the need for uniform semantics for the predefined operators and the requirement for backward compatibility.