5 ms·

Actually, IEEE-754 floating point numbers (which C doubles are in most circumstances) have a sign bit while most modern architectures / compilers use two's comp

Actually, IEEE-754 floating point numbers (which C doubles are in most circumstances) have a sign bit while most modern architectures / compilers use two's complement for denoting negative integer numbers, so even doing non-trivial sign-related things with signed 32 bit integers in C code would potentially break.

sparky 17y ago
Yeah, the difference in representations could be a problem. I think a lot of it could be dealt with (with much difficulty) by the compiler -- for instance, you might be able to use the mantissa bits as a two's-complement int and synthesize proper arithmetic and comparison behavior out of unholy combinations of floating-point operations -- but in general, if someone depends on the bit pattern explicitly (as in compressed data, bloom filter, bit flags, ...), you're going to have a hell of a time getting correctness, much less performance.
_delirium 17y ago
True, but that's not that common, is it? The C standard doesn't let you assume two's complement, and while it's nearly universal that you can assume it in practice, I also don't frequently see apps doing manual bit-twiddling that relies on the representation of negative numbers. Code that gets run through lint would also have that flagged.
- azim 17y ago
  One thing that's actually extremely common, however, in C code is using ints for bitmasks. I'm not sure how operators like &|! would be implemented with doubles, but they'd need some fancy software implementation.
  - mhansen 17y ago
    Javascript faces similar problems - it has no int type - all numbers are represented as 64-bit doubles. &|! operations are done by converting the double to an int, performing the operation, then converting back to a double.
    - celoyd 17y ago
      Just to be clear, when you say they are done like that, those operators are in the spec and that’s how they act; it’s not just a standard hack. So there is (for example) a ToInt32 function in the spec but not in the language. This surprised me. (I was playing with cryptography in JS and needed to do lots of bitwise operations on hand-made bigints. It was easier than I expected.)
      - mhansen 17y ago
        Can I see your work somewhere? I've been wondering about crypto in javascript. I checked your profile for an email, but it doesn't show.
        celoyd 17y ago
        It was an implementation of Trivium, an extremely simple stream cipher. I was also thinking of doing Salsa20, but I got distracted. The code: http://basecase.org/trivium/trivium.js http://basecase.org/trivium/trivium.js Demo: http://basecase.org/trivium/ http://basecase.org/trivium/ Honestly, I lost interest once I got it working with simple test strings. If you do something cool with it, let me know! Edit: Looking at it again, my code is badly undercommented – sorry. But if you follow along with the Trivium specification (http://www.ecrypt.eu.org/stream/ciphers/trivium/trivium.pdf http://www.ecrypt.eu.org/stream/ciphers/trivium/trivium.pdf), which is a model of clarity, it should all make sense mod renaming of variables etc. The outstanding bug is that it assumes that any sequence of 16-bit values can be taken as a UTF-16 string, which is not true. Will e-mail you some general thoughts when I have a few minutes.
  - _delirium 17y ago
    In the C backend at least, it appears to cast to an int, perform the bitwise operations, and then cast back. Just trying it out now, the function: int foo(int bar) { return bar & 0x01; } compiles to: clue_real_t _foo(clue_real_t fp, clue_optr_t stack, clue_real_t FLOAT0) { clue_real_t sp; clue_real_t FLOAT1; clue_real_t FLOAT2; sp = 0; sp = fp + sp; FLOAT1 = 1; FLOAT2 = (clue_realint_t) FLOAT0 & (clue_realint_t) FLOAT1; return FLOAT2; }
- DrJokepu 17y ago
  Yes, I don't think it's that common at all. In fact, the only place I would expect to find such things is the source code of 90's video games where developers tried to grasp every bit of performance they could with series of unholy tricks.

sparky 17y ago

Yeah, the difference in representations could be a problem. I think a lot of it could be dealt with (with much difficulty) by the compiler -- for instance, you might be able to use the mantissa bits as a two's-complement int and synthesize proper arithmetic and comparison behavior out of unholy combinations of floating-point operations -- but in general, if someone depends on the bit pattern explicitly (as in compressed data, bloom filter, bit flags, ...), you're going to have a hell of a time getting correctness, much less performance.

_delirium 17y ago

True, but that's not that common, is it? The C standard doesn't let you assume two's complement, and while it's nearly universal that you can assume it in practice, I also don't frequently see apps doing manual bit-twiddling that relies on the representation of negative numbers. Code that gets run through lint would also have that flagged.

azim 17y ago
One thing that's actually extremely common, however, in C code is using ints for bitmasks. I'm not sure how operators like &|! would be implemented with doubles, but they'd need some fancy software implementation.
- mhansen 17y ago
  Javascript faces similar problems - it has no int type - all numbers are represented as 64-bit doubles. &|! operations are done by converting the double to an int, performing the operation, then converting back to a double.
  - celoyd 17y ago
    Just to be clear, when you say they are done like that, those operators are in the spec and that’s how they act; it’s not just a standard hack. So there is (for example) a ToInt32 function in the spec but not in the language. This surprised me. (I was playing with cryptography in JS and needed to do lots of bitwise operations on hand-made bigints. It was easier than I expected.)
    - mhansen 17y ago
      Can I see your work somewhere? I've been wondering about crypto in javascript. I checked your profile for an email, but it doesn't show.
      - celoyd 17y ago
        It was an implementation of Trivium, an extremely simple stream cipher. I was also thinking of doing Salsa20, but I got distracted. The code: http://basecase.org/trivium/trivium.js http://basecase.org/trivium/trivium.js Demo: http://basecase.org/trivium/ http://basecase.org/trivium/ Honestly, I lost interest once I got it working with simple test strings. If you do something cool with it, let me know! Edit: Looking at it again, my code is badly undercommented – sorry. But if you follow along with the Trivium specification (http://www.ecrypt.eu.org/stream/ciphers/trivium/trivium.pdf http://www.ecrypt.eu.org/stream/ciphers/trivium/trivium.pdf), which is a model of clarity, it should all make sense mod renaming of variables etc. The outstanding bug is that it assumes that any sequence of 16-bit values can be taken as a UTF-16 string, which is not true. Will e-mail you some general thoughts when I have a few minutes.
- _delirium 17y ago
  In the C backend at least, it appears to cast to an int, perform the bitwise operations, and then cast back. Just trying it out now, the function: int foo(int bar) { return bar & 0x01; } compiles to: clue_real_t _foo(clue_real_t fp, clue_optr_t stack, clue_real_t FLOAT0) { clue_real_t sp; clue_real_t FLOAT1; clue_real_t FLOAT2; sp = 0; sp = fp + sp; FLOAT1 = 1; FLOAT2 = (clue_realint_t) FLOAT0 & (clue_realint_t) FLOAT1; return FLOAT2; }
DrJokepu 17y ago
Yes, I don't think it's that common at all. In fact, the only place I would expect to find such things is the source code of 90's video games where developers tried to grasp every bit of performance they could with series of unholy tricks.