13 ms·

I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU archite

by drfuchs 11y ago

I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU architecture?" But, "No; think more along the lines of 'adding a new multiply instruction'. By the time you're in Bitcode, you're already fairly architecture-specific" says he. My hopes for a return to big-endian are dashed. [Quotes are approximate.]

twoodfin 11y ago
That sounds about right. No radical architectural shifts, but bitcode submissions should let Apple optimize apps automatically for whatever latest tweaks are available in issue width or fused instructions. My most radical speculation is an iPhone A-series chip with an additional low power ARM core especially to support Watch apps without burning too much "host" device battery.
kmicklas 11y ago
Why on earth would you ever want to _return_ to big-endian?
- Marat_Dukhan 11y ago
  To think different
- drfuchs 11y ago
  Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works. The one place I've seen little-endian actually be a help is that it tends to catch "forgot to malloc strlen PLUS ONE for the terminating NUL byte" bugs that go undetected for much longer on big-endian machines. Making such an error means the NUL gets written just past the end of the malloc, which may be the first byte of the next word in the heap, which (on many implementations of malloc) holds the length of the next item in the heap, which is typically a non-huge integer. Thus, on big-endian machines, you're overwriting a zero (high order byte of a non-huge integer) with a zero, so no harm done, and the bug is masked. On little-endian machines, though, you're very likely clobbering malloc's idea of the size of the next item, and eventually it will notice that its internal data structures have been corrupted and complain. I learned this lesson after we'd been shipping crash-free FrameMaker for years on 68000 and Sparc, and then ported to the short-lived Sun386i.
  - ahomescu1 11y ago
    > Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Actually, it is possible that that was nothing more than an accident. We use Arabic numerals, and Arabic languages are written right-to-left. Then there are languages like German where digits are read in reverse, so "42" is read as "two-and-forty".
    - hyperpape 11y ago
      Do they also call 1042 "Forty two and one thousand"?
      - ahomescu1 11y ago
        After looking up some German for beginners (German speakers, feel free to correct me), I found out that 1042 is read like "one thousand two and forty".
        mschulze 11y ago
        German speaker here, that's correct. When the number is between 1000-1999 the "one" in "one thousand" is sometimes omitted, so "thousand two and forty".
        DavidSJ 11y ago
        Also known as middle endian.
        mitchty 11y ago
        Even if its weird, its nothing like French numerals.
        Joky 11y ago
        Aren't the only weirdness in French 70, 80 and 90? That's nothing compared to German :)
- logicallee 11y ago
  >why on earth there's your problem, you're living on earth. try living in the cloud. :) (network byte order)
- jfb 11y ago
  Because BSD vs SysV just doesn't have that frisson of '80s nerdwar any longer?
  - DonHopkins 11y ago
    Remember the Tie Fighter -vs- Death Star poster swag from Usenix? 4.x > V ∀ x from 0..∞
- nsajko 11y ago
  Graphically explained: http://geekandpoke.typepad.com/geekandpoke/2011/09/simply-explained-1.html http://geekandpoke.typepad.com/geekandpoke/2011/09/simply-ex...
clord 11y ago
Exactly. Clang makes platform-specific lowerings and bakes in some ABI-specific gunk. Granted not so much as the object code on the other side of the back-end. Enabling target-specific vectorization and whole-program optimization are probably the goal.

by drfuchs 11y ago

twoodfin 11y ago

That sounds about right. No radical architectural shifts, but bitcode submissions should let Apple optimize apps automatically for whatever latest tweaks are available in issue width or fused instructions. My most radical speculation is an iPhone A-series chip with an additional low power ARM core especially to support Watch apps without burning too much "host" device battery.

kmicklas 11y ago

Why on earth would you ever want to _return_ to big-endian?

Marat_Dukhan 11y ago
To think different
drfuchs 11y ago
Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Because the left-most bit in a byte is the high-order bit, so the left-most byte in a word should be the high-order byte. Because ordering two 8-character ascii strings can be done with a single 8-byte integer compare instruction (with the obvious generalizations). Because looking for 0x12345678 in a hex dump (visually or with an automatic tool) isn't a maddening task. Because manipulating 1-bit-per-pixel image data and frame buffers (shifting left and right, particularly) doesn't lead to despair. Because that's how any right-thinking person's brain works. The one place I've seen little-endian actually be a help is that it tends to catch "forgot to malloc strlen PLUS ONE for the terminating NUL byte" bugs that go undetected for much longer on big-endian machines. Making such an error means the NUL gets written just past the end of the malloc, which may be the first byte of the next word in the heap, which (on many implementations of malloc) holds the length of the next item in the heap, which is typically a non-huge integer. Thus, on big-endian machines, you're overwriting a zero (high order byte of a non-huge integer) with a zero, so no harm done, and the bug is masked. On little-endian machines, though, you're very likely clobbering malloc's idea of the size of the next item, and eventually it will notice that its internal data structures have been corrupted and complain. I learned this lesson after we'd been shipping crash-free FrameMaker for years on 68000 and Sparc, and then ported to the short-lived Sun386i.
- ahomescu1 11y ago
  > Because big-endian matches how most humans have done it for most of history ("five hundred twenty one" is written "521" or "DXXI", not "125" or "IXXD"). Actually, it is possible that that was nothing more than an accident. We use Arabic numerals, and Arabic languages are written right-to-left. Then there are languages like German where digits are read in reverse, so "42" is read as "two-and-forty".
  - hyperpape 11y ago
    Do they also call 1042 "Forty two and one thousand"?
    - ahomescu1 11y ago
      After looking up some German for beginners (German speakers, feel free to correct me), I found out that 1042 is read like "one thousand two and forty".
      - mschulze 11y ago
        German speaker here, that's correct. When the number is between 1000-1999 the "one" in "one thousand" is sometimes omitted, so "thousand two and forty".
      - DavidSJ 11y ago
        Also known as middle endian.
        mitchty 11y ago
        Even if its weird, its nothing like French numerals.
        Joky 11y ago
        Aren't the only weirdness in French 70, 80 and 90? That's nothing compared to German :)
logicallee 11y ago
>why on earth there's your problem, you're living on earth. try living in the cloud. :) (network byte order)
jfb 11y ago
Because BSD vs SysV just doesn't have that frisson of '80s nerdwar any longer?
- DonHopkins 11y ago
  Remember the Tie Fighter -vs- Death Star poster swag from Usenix? 4.x > V ∀ x from 0..∞
nsajko 11y ago
Graphically explained: http://geekandpoke.typepad.com/geekandpoke/2011/09/simply-explained-1.html http://geekandpoke.typepad.com/geekandpoke/2011/09/simply-ex...

clord 11y ago

Exactly. Clang makes platform-specific lowerings and bakes in some ABI-specific gunk. Granted not so much as the object code on the other side of the back-end. Enabling target-specific vectorization and whole-program optimization are probably the goal.