5 ms·

Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`?

by innocenat 5y ago

matheusmoreira 5y ago
No. I expect that from I/O functions.
- innocenat 5y ago
  How is it different? Why do you draw the line at I/O function?
  - matheusmoreira 5y ago
    Because it doesn't really matter how the program calculates mathematical functions as long as the result is correct. Whether it's a function or an instruction, it's inconsequential. I/O on the other hand is a lot more interesting. They're a very common source of undefined behavior, bugs and interception via custom shared objects. I'd rather the compiler touched them as little as possible. Actually I'd rather not use them at all. I find system calls to be much more ergonomic.
    - innocenat 5y ago
      What about datetime, random, system, etc?
      - matheusmoreira 5y ago
        They're all system calls that are better served by using operating functions directly. I'm not sure how the compiler could possibly optimize those away though. Maybe the random function could become a very untrustworthy instruction?
        _kst_ 5y ago
        Random number generation generally isn't handled by system calls. It's just computation. (Some languages do provide support for hardware [pseudo-]random number generation. C doesn't.) More generally, using system calls directly for things like getting the current time makes sense only if you don't care about portability. C can support both portable and non-portable code. Both are important. I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. I sympathize with your situation, but it's not one that most programmers share.
        matheusmoreira 5y ago
        > I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. Definitely seems that way to me as well. Still, if I bend C enough it turns into something that's almost what I want. I just wish GCC had a couple more flags to control code generation in these surprising cases.
    - _kst_ 5y ago
      For me, it doesn't matter whether printf("hello\n") works via a call to printf or a call to puts. If those 6 characters I specified are written to standard output, I don't care how it was done. Of course I care if I want to use the value returned by printf, but if my code uses that value the optimization isn't performed. I think the semantic gap between assembly language and C is much wider than a lot of people realize. I wonder if a language somewhere in the middle of that gap would be useful to some people. (It probably wouldn't be useful to me.)
varajelle 5y ago
> Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`? Of course. Who else is going to set errno when I pass negative a number?
- int_19h 5y ago
  Nobody has to, if you pass it an unsigned int. Would you still expect it to be a function call then?
- matheusmoreira 5y ago
  So the compiler actually can't optimize because of legacy errno cruft? That's hilarious...
  - varajelle 5y ago
    The compiler respects the C standard by default. According to it, puts() is the same as a printf() in some conditions, but sqrt() is not the same as the instruction. If you don't like C, you can use a dialect of it by setting some flags: -fno-math-errno if you want to optimize sqrt anyway or -fno-builtin if you don't want the compiler to replace functions calls
    - matheusmoreira 5y ago
      I like C for the most part. I don't like the standard library. It's got stuff like errno, a thread local global variable, and that's just the simplest problem. Freestanding C turned out to be a far better language just because it has no legacy cruft weighing it down. > -fno-math-errno That's interesting, didn't know about it.
- gspr 5y ago
  Ok, so make the question one of `call sqrt` vs `sqrtss xmm0` + a test that sets errno in case of negative then? Or even simpler: do you demand that `x = sqrt(4)` entails emitting code that calls `sqrt`?

Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`?

matheusmoreira 5y ago

No. I expect that from I/O functions.

innocenat 5y ago
How is it different? Why do you draw the line at I/O function?
- matheusmoreira 5y ago
  Because it doesn't really matter how the program calculates mathematical functions as long as the result is correct. Whether it's a function or an instruction, it's inconsequential. I/O on the other hand is a lot more interesting. They're a very common source of undefined behavior, bugs and interception via custom shared objects. I'd rather the compiler touched them as little as possible. Actually I'd rather not use them at all. I find system calls to be much more ergonomic.
  - innocenat 5y ago
    What about datetime, random, system, etc?
    - matheusmoreira 5y ago
      They're all system calls that are better served by using operating functions directly. I'm not sure how the compiler could possibly optimize those away though. Maybe the random function could become a very untrustworthy instruction?
      - _kst_ 5y ago
        Random number generation generally isn't handled by system calls. It's just computation. (Some languages do provide support for hardware [pseudo-]random number generation. C doesn't.) More generally, using system calls directly for things like getting the current time makes sense only if you don't care about portability. C can support both portable and non-portable code. Both are important. I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. I sympathize with your situation, but it's not one that most programmers share.
        matheusmoreira 5y ago
        > I get the impression that C is too high-level, and assembly language is too tedious, to fully support your requirements. Definitely seems that way to me as well. Still, if I bend C enough it turns into something that's almost what I want. I just wish GCC had a couple more flags to control code generation in these surprising cases.
  - _kst_ 5y ago
    For me, it doesn't matter whether printf("hello\n") works via a call to printf or a call to puts. If those 6 characters I specified are written to standard output, I don't care how it was done. Of course I care if I want to use the value returned by printf, but if my code uses that value the optimization isn't performed. I think the semantic gap between assembly language and C is much wider than a lot of people realize. I wonder if a language somewhere in the middle of that gap would be useful to some people. (It probably wouldn't be useful to me.)

varajelle 5y ago

> Do you also expect `sqrt(a)` to be `call sqrt` and not `sqrtss xmm0`? Of course. Who else is going to set errno when I pass negative a number?

int_19h 5y ago
Nobody has to, if you pass it an unsigned int. Would you still expect it to be a function call then?
matheusmoreira 5y ago
So the compiler actually can't optimize because of legacy errno cruft? That's hilarious...
- varajelle 5y ago
  The compiler respects the C standard by default. According to it, puts() is the same as a printf() in some conditions, but sqrt() is not the same as the instruction. If you don't like C, you can use a dialect of it by setting some flags: -fno-math-errno if you want to optimize sqrt anyway or -fno-builtin if you don't want the compiler to replace functions calls
  - matheusmoreira 5y ago
    I like C for the most part. I don't like the standard library. It's got stuff like errno, a thread local global variable, and that's just the simplest problem. Freestanding C turned out to be a far better language just because it has no legacy cruft weighing it down. > -fno-math-errno That's interesting, didn't know about it.
gspr 5y ago
Ok, so make the question one of `call sqrt` vs `sqrtss xmm0` + a test that sets errno in case of negative then? Or even simpler: do you demand that `x = sqrt(4)` entails emitting code that calls `sqrt`?