Index: automake/cfa.m4 =================================================================== --- automake/cfa.m4 (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ automake/cfa.m4 (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -66,4 +66,5 @@ "x86-64" ) cannon_arch_name="x64";; "x86_64" ) cannon_arch_name="x64";; + "aarch64" ) cannon_arch_name="x64";; "x86" ) cannon_arch_name="x86";; "i386" ) cannon_arch_name="x86";; @@ -75,5 +76,5 @@ "armv7l" ) cannon_arch_name="arm";; *) - >&2 echo "Unkown architecture " $arch_name; + >&2 echo "Unknown architecture " $arch_name; exit 1 ;; Index: benchmark/Makefile.am =================================================================== --- benchmark/Makefile.am (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ benchmark/Makefile.am (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -11,6 +11,6 @@ ## Created On : Sun May 31 09:08:15 2015 ## Last Modified By : Peter A. Buhr -## Last Modified On : Mon Jun 24 16:45:42 2019 -## Update Count : 53 +## Last Modified On : Mon Jul 29 18:02:19 2019 +## Update Count : 54 ############################################################################### @@ -50,5 +50,6 @@ REPEAT = ${abs_top_builddir}/tools/repeat STATS = ${abs_top_srcdir}/tools/stat.py -repeats = 3 # 30 +# NEED AT LEAST 4 DATA VALUES FOR BENCHMARKS BECAUSE THE MAX AND MIN VALUES ARE REMOVED +repeats = 5 # 31 for benchmarks arch = x64 skipcompile = no Index: benchmark/Makefile.in =================================================================== --- benchmark/Makefile.in (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ benchmark/Makefile.in (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -396,5 +396,6 @@ REPEAT = ${abs_top_builddir}/tools/repeat STATS = ${abs_top_srcdir}/tools/stat.py -repeats = 3 # 30 +# NEED AT LEAST 4 DATA VALUES FOR BENCHMARKS BECAUSE THE MAX AND MIN VALUES ARE REMOVED +repeats = 5 # 31 for benchmarks arch = x64 skipcompile = no Index: configure =================================================================== --- configure (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ configure (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -3433,4 +3433,5 @@ "x86-64" ) cannon_arch_name="x64";; "x86_64" ) cannon_arch_name="x64";; + "aarch64" ) cannon_arch_name="x64";; "x86" ) cannon_arch_name="x86";; "i386" ) cannon_arch_name="x86";; @@ -3442,5 +3443,5 @@ "armv7l" ) cannon_arch_name="arm";; *) - >&2 echo "Unkown architecture " $arch_name; + >&2 echo "Unknown architecture " $arch_name; exit 1 ;; @@ -3474,4 +3475,5 @@ "x86-64" ) cannon_arch_name="x64";; "x86_64" ) cannon_arch_name="x64";; + "aarch64" ) cannon_arch_name="x64";; "x86" ) cannon_arch_name="x86";; "i386" ) cannon_arch_name="x86";; @@ -3483,5 +3485,5 @@ "armv7l" ) cannon_arch_name="arm";; *) - >&2 echo "Unkown architecture " $arch_name; + >&2 echo "Unknown architecture " $arch_name; exit 1 ;; Index: doc/proposals/operator-defaults.md =================================================================== --- doc/proposals/operator-defaults.md (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) +++ doc/proposals/operator-defaults.md (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -0,0 +1,281 @@ +Operator Defaults +================= + +This proposal introduces a new syntax for requesting a default implementation +of an operator and the rules for generating them. + +This is to build on the implied relationships between operators. Most default +operators will be implemented in terms of other operators. As a fall-back +operators can try to figure out an intuitive definition from inspection of the +type's sue declaration. + +Syntax +------ + +The syntax for requesting a default implementation is part of function +definition. After the function signature (after the parameter list) instead +of putting the function body you declare it to be equal to default. + + box ?+?(box const & left, box const & right) = default; + +These can exist along side any forward definitions of the function, but would +conflict with any other complete definitions or deletions of the function. + +It could be valid syntax on any function, but possibly all non-operators would +report that no default implementation available. + +If default implementations are really popular and we don't need additional +information about the signature a more compact syntax could be added. + + default box( ?(), ?=?, ?!=?, ??, ?<=?, ?>=? ); + +Generation Strategies +--------------------- + +There exists a system around the default generation that selects how to +generate a given function if one can be generated at all. This section +describes that system and some of the logic behind it. + +There are two main strategies for generating an operator implementation. + +The first is to mimic the relationship between operators on the primitive +types by defining a new operator in terms of an existing operator on the same +type. For instance `++i` is equivalent to `i += 1`, so the generated +implementation will "look like" that. + +The second is to inspect the structure of the declaration to guess at what +the default implementation would be. Because of that it is dependent on the +kind of declaration, a structure doesn't have the same rules as an +enumeration. Also it is similar to the implicate definitions currently created +by the compiler and the generation methods for many are carried over. + +From these strategies a method of generation (a particular set of rules that +define an implementation from the type and existing functions) has to be +picked, but often there is more than on reasonable choice. In these cases they +are ordered and the first (best) one whose requirements is met is then used. +See "Circular Requirements" below for some exceptions and extensions to this +pattern. + +Generally the methods based on operators come first as they propagate any +unusual implementations from the explicate operators to the ones being +generated. If all of those fail then the intuitive definition based on the +declaration's shape is used. The general patterns in this area for the +different sue types follow. + +### Structures +Structures will usually apply the operation to each field, or when there are +two parameters the matching pairs of fields from each, and then combine the +results. + +This does require that the fields have certain operators defined on them. +In this respect it is still operator based generation, but we use inspection +on the structure to find out which operators to use. + +Also, for the purposes of default generation types declared with the +concurrency modifiers (coroutine, monitor and thread) are considered structs. +The default implementations should be the same as if you had written out the +extra field and functions by hand. + +### Enumerations +The two ways of using enumerations are considered. First as "one of" the +list options as in normal use, the second is as a set of flags where each +option represents a flag that may or may not be set. + +Currently there is no way to specify which nor does the system attempt to +guess by checking assigned values. There is one case where an operator could +have a meaningful default in both versions. If both are included then we can +try to pick one by scanning the enumeration to see what values its options +are given (a linear series or powers of 2) could be used. In all other cases +the definition that makes sense can be assumed. + +### Unions +Unions are the hardest to deal with because the instance does not show which +field in the union is being used. Because of that there are very few intuitive +definitions to use and the ones that do depend on bit-wise operations and only +if the union is made of primitive types. + +### Traits +Default operations are not supported on traits. A function implemented by the +default generation may be used to satisfy an assertion. However a default +implementation may not be requested on a polymorphic function. + +It could in theory, limiting to operation based generation and using the +operations available in the assertion list. There are a few problems: ++ Knowing the entire set of functions being generated is very useful in some + cases and this information is quickly lost with polymorphic functions. ++ The rules for choosing a generation method do not match how a polymorphic + function is selected so the results can be inconsistent. ++ It is easily to mimic with a polymorphic function already, writing out one + generic function and including it. + +Default Generation +------------------ + +Here are the generation methods. Unless otherwise stated they are listed in +priority order. That is the first one mentioned that a type fits (has all the +required operators or its form matches) will be used. + +The operator based constructions can be used on any sue type, those that +require a particular kind mention that. + +### Constructor: ?{} +Note that requesting any constructor to be generated counts as defining a +constructor for purposes of disabling the implicate constructors. There are +no operator based methods for generating constructors. + +For structures: For the zero argument constructor (aka the default constructor, +which takes just a reference to the value to construct) each field is +constructed with its zero argument constructor. For the copy constructor each +field is copy constructed from the same field in the copied structure. For +zero_t and one_t each field is also constructed from zero_t or one_t. + +For enumerations: For the zero argument constructor the value is set to 0 if +one of the enumeration options is 0 (or set to the first value in the enum). +For the zero_t constructor it is the same except the check is skipped (and no +or). The copy constructor is the same as memcpy. + +For unions: For the zero argument constructor of a union that is constructed +entirely of primitive types (or other types that zero argument construct to +all 0s) the union filled with 0s. For the copy constructor of a union of types +that all have trivial copy constructors memcpy is used. + +### Destructor: ^?{} +Requesting the default destructor should be the same as having it implicitly +defined. Destructors only have one signature and the intuitive definition for +that is the same as without the signature. + +Still it should be allowed for consistency. It also allows it to be forward +declared and then generated in a .cfa file. + +### Assignment: ?=? +Default assignment is only supported between two objects of the same type. +For structures it is field to field assignment. For enumerations and unions +of primitives or trivially copiable types it the same as memcpy. + +### Equality: ?==? ?!=? +Both equality operations can be implemented by negating the result of the +other operations. + +For structures: Equality can be implement by checking equality on each pair of +matching fields and taking the logical and of the results. Inequality can be +implemented by checking inequality on each pair of matching fields and taking +the logical or of the results. + +Both logical operations could be short circuiting. Without side effects it is +purely an optimization. + +For enumerations: Both operations are the same as on the underlying integral. + +For unions: If it is assumed that the different branches represent different +views of the same data and this data is primitive, than bit-wise comparisons +can be used. + +### Comparison: ?? ?<=? ?>=? +Less than can be implemented by flipping the arguments on greater than. +Greater than can be implemented by flipping less then. Less than or equal to +can be implemented by flipping greater than or equal to. Greater than or equal +to can be implemented by flipping less than or equal to. + +Less than or equal to can be implemented by using less than, equals and taking +the or of the results. Greater than or equal to can be implemented by using +greater than, equals and taking the or of the results. + +> The trick of negating comparisons is not used. As an example ? (boolean) not ?>=? unless the type is strictly ordered. For operator based +> overloads that might not be true in very reasonable implementations so it is +> not assumed. + +Opposite less than can be implemented as less than or equal to and not equal +to. Greater than can be implemented as greater than or equal to and not equal +to. + +For enumerations: Enumerations that represent one of all operations are the +same as on the underlying integral. Enumerations that represent a set of +options could replace less then with subset of and greator than with superset +of and use bit-wise masking to implement those operations. + +### Binary & Relative Assignment Operators: ?_? ?_=? +This applies to each operator in the form of `T ?_?(T, T);` for some type T +and has a matching relative assignment operator `T& ?_=?(T&, T)` where the +`_` in both is replaced by some string of operator characters. + +The binary operator can be created by copying the left argument, using the +relative assignment with the right argument and returning the updated copy. + +The relative assignment operator can be implemented by using the binary +operation to create a copy, then assigning the result to the left argument. +The left argument should then be returned. For the signature above it would +return by reference. The signature `T ?_=?(T&, T)` could also be supported in +which case it would return by copy. + +### Minus: -? ?-? +Unary minus can be implemented by subtracting argument from the value created +from zero_t. + +Binary minus can be implemented by negating (with unary minus) the right +argument and adding the result to the left argument. + +### Increment & Decrement: ++? ?++ --? ?-- +Either pre- operation can implemented by applying the post- operation and then +returning a reference to, or copy of, the updated value. Either post- +operation can be implemented by copying the argument, applying the pre- +operation to the original and returning the copy. + +Pre-increment can be implemented by using addition assignment by the value +constructed from one_t. Pre-decrement can be implemented by using subtraction +assignment by the value from one_t. + +Because many of the operations used have there own default implementations +(for example: ?+=? from ?+? or field-wise one_t construction) this list could +be expanded by replacing a function call with the default implementation for +that function. This might work for the post- operations generated from +relative assignment, the one_t constructed object and copying, but the logical +connection becomes weaker and weaker as that process continues. + +### Bit Manipulation: ?|? ?&? ~? ?<>? +No operation based construction is provided for bit manipulation operators. + +For enumerations that are considered sets of flags: And returns a set with all +flags set in both operand sets, or returns a set with all flags set that are +set in either operand sets and not returns a set with all flags set that are +not set in the operand set. + +> And it would be possible to actually implement this for any sized type and +> just do the bitwise operation and trust the user that it makes sense if they +> request it. + +Also for set enumerations, the signature `T ?<get_lvalue() ) { - // when not generating C code, print lvalue for debugging. - typeString = "lvalue " + typeString; - } } } Index: src/SymTab/Mangler.cc =================================================================== --- src/SymTab/Mangler.cc (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ src/SymTab/Mangler.cc (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -10,6 +10,6 @@ // Created On : Sun May 17 21:40:29 2015 // Last Modified By : Peter A. Buhr -// Last Modified On : Mon Sep 25 15:49:26 2017 -// Update Count : 23 +// Last Modified On : Tue Jul 30 13:46:10 2019 +// Update Count : 26 // #include "Mangler.h" @@ -377,9 +377,4 @@ mangleName << Encoding::qualifiers.at(Type::Mutex); } // if - if ( type->get_lvalue() ) { - // mangle based on whether the type is lvalue, so that the resolver can differentiate lvalues and rvalues - mangleName << Encoding::qualifiers.at(Type::Lvalue); - } - if ( inFunctionType ) { // turn off inFunctionType so that types can be differentiated for nested qualifiers @@ -724,9 +719,4 @@ mangleName << Encoding::qualifiers.at(Type::Mutex); } // if - if ( type->is_lvalue() ) { - // mangle based on whether the type is lvalue, so that the resolver can differentiate lvalues and rvalues - mangleName << Encoding::qualifiers.at(Type::Lvalue); - } - if ( inFunctionType ) { // turn off inFunctionType so that types can be differentiated for nested qualifiers Index: tests/pybin/settings.py =================================================================== --- tests/pybin/settings.py (revision c6f1f3ebf65fd583f3f052ae0aed817e4ce7f4fc) +++ tests/pybin/settings.py (revision 0d92e5c9f8a21c6e4fcc64a40b59c727c60f5934) @@ -22,4 +22,5 @@ 'x86-64' : 'x64', 'x86_64' : 'x64', + 'aarch64' : 'x64', 'x86' : 'x86', 'i386' : 'x86', @@ -40,5 +41,5 @@ canonical_host = Architecture.make_canonical( config.HOSTARCH ) except KeyError: - print("Unkown host architecture %s" % config.HOSTARCH, file=sys.stderr) + print("Unknown host architecture %s" % config.HOSTARCH, file=sys.stderr) sys.exit(1) @@ -47,5 +48,5 @@ arch = Architecture.make_canonical( arch ) except KeyError: - print("Unkown architecture %s" % arch, file=sys.stderr) + print("Unknown architecture %s" % arch, file=sys.stderr) sys.exit(1)