h a l f b a k e r yMay contain nuts.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
In most programming languages, some data types are specified as unsigned, and will be zero-extended if they are cast to larger types; other data types are signed, and will be sign-extended if they are cast to larger types. I would like to see a data type which would always be one-extended (all upper
bits filled with 'ones'). Such a data type would not be particularly useful for variables, but would be useful for subexpressions involving the ones-complement operator.
For example, given an expression like:
longVar = longVar and not someExpression
The intended function of this expression is to mask out those bits of the 64-bit variable which are set in the constant. Such logic should be clear regardless of the size of the constant. Unfortunately, some constant values will yield unexpected results (which ones malfunction depends upon the language and implementation) because the expression "not someExpression" may not end up evaluating to a 64-bit number with the upper bits set. If ones-padded types were available for the value of "not someExpression", this issue would be avoided.
[link]
|
| |
Hi supercat. Long time no see. I've no idea if your
idea is any good, just dropped in to say hello. |
|
| |
<mumble> big/small-endian, redefines, kids these days </mumble> |
|
| |
Perhaps I was unclear? New programming languages are developed from time to time. Unfortunately, programming languages seem to have trouble with evaluating expressions such as "var = var and not expr" when the size of var is greater than the size of expr. Different programming languages have different rules for integer promotion, but I am unaware of any language which handles the above expression sensibly for all combinations of variable sizes except for those which promote all integer expressions to the largest available integer type. |
|
| |
If someone is going to define a new programming language (as people do from time to time), it would seem logical to try to define integer promotion rules which will achieve sensible results for common expressions without requiring explicit typecasts (which may make code brittle) or generating inefficient code. Recognizing upper-bit-set types for intermediate subexpressions would allow expressions involving inversion to be handled sensibly. Incidentally, it would also allow compilers to be sensible in their warnings about 'narrowing' integer conversions. For example, if 'bytevar' equals $04, the expression 'longvar = not bytevar' should set longvar to $FFFFFFFFFFFFFFF4 (if it's 64 bits), but the expression 'bytevar2 = not bytevar' should set bytevar2 to $F0 without complaining about trying to put a 64-bit value into an 8-bit variable. |
|
| |
If you know you will be comparing integers of varying length and signage with an integer constant, why not define the constant once as a signed double and once as an unsigned double, then redefine their storage areas so you can pull long and shorts out of them as well. Yes, thankyou that will be $1,114.93. |
|
| |
The purpose isn't primarily for comparing integers, but for operations like masking. Perhaps recognizing an "and not" operator might be more useful, but unless one were using a whole new syntax, it might add confusion. Basically, the goal of the one-extended types would be to allow a compiler to achieve the same results as would be achieved by extending all operands to the machine's longest integral types, without having to do so. If one added to VB an "and not" operator written AndNot, an expression like "Foo = Bar AndNot Boz" could work as expected for all possible sizes of bar and boz, but the differences betwee that expression and "Foo = Bar And Not Boz" could cause confusion. |
|
| |
ahh, i see (vaguely)... you'd think the compiler would complain that for some reason you're doing boolean operations on unequal-length fields... Have you considered redef'ing the (say) double as shorter fields instead of requiring padding for the other field ? |
|
| |