Announcement

Collapse
No announcement yet.

Debian Guts Support For Old MIPS CPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by torsionbar28 View Post
    Why? There are inherent advantages to BE (e.g. imaging, networking). Quite frankly I'm not sure why LE is even still used, it should have gone extinct long ago.
    Indeed,
    In this regard, x86 is the one to blame for it.. or...the people, since the arch doesn't take actions

    Comment


    • #12
      Originally posted by torsionbar28 View Post
      Why? There are inherent advantages to BE (e.g. imaging, networking). Quite frankly I'm not sure why LE is even still used, it should have gone extinct long ago.
      BE doesn't have any inherent advantage for networking other than the fact that historically it was arbitrarily picked as the standard representation. It does have some advantages for certain data structures. On the other hand LE has the advantage that whether you access a given value as a byte or anything all the way up to a 64bit integer, it is always at the same base address without having to juggle with offsets and memory alignment constraints.

      Comment


      • #13
        Originally posted by torsionbar28 View Post
        Why? There are inherent advantages to BE (e.g. imaging, networking).
        No. BE is only used in networking by convention - not because it's actually any better-suited to the task.

        Originally posted by torsionbar28 View Post
        Quite frankly I'm not sure why LE is even still used, it should have gone extinct long ago.
        LE has the advantage that the numeric value of a byte in memory doesn't change based on the word size you use to read it.

        The only real advantage BE has is due to the western convention to write more significant digits to the left. So, when viewing a hex dump, it's easier for silly humans to understand. The better solution is to write better tools. For instance, if you just have your LE hex dump display addresses increasing from right-to-left, that would nullify this advantage of BE.

        Comment


        • #14
          Originally posted by jacob View Post
          BE doesn't have any inherent advantage for networking other than the fact that historically it was arbitrarily picked as the standard representation.
          Very Wrong!!
          In a world of Internet and Internet of Things/Network, packing data, serialising it, etc BE is king..

          Its Inherently more efficient to pack data, to serialise it.. which would mean better performance, less power consumption..
          Its also more efficient to translate from binary to decimal

          LE is like crazy, Always translating data,
          Very poor efficiency to send/receive data using a network in a LE computer,

          You need to use always functions for network translation, checksumming IP packets, verification its a mess, very poor efficiency..
          Some functions needed in LE *always*
          htons() - "Host to Network Short"
          htonl() - "Host to Network Long"
          ntohs() - "Network to Host Short"
          ntohl() - "Network to Host Long"

          Even though this functions can be called in BE( just because the litle-endians need them, if the code is shared..), *they do nothing*
          Otherwise you don't even need to call them in BE.

          Comment


          • #15
            Originally posted by coder View Post
            No. BE is only used in networking by convention - not because it's actually any better-suited to the task.
            That is completely Wrong!!

            See my comment above..

            Comment


            • #16
              Originally posted by tuxd3v View Post
              Its Inherently more efficient to pack data, to serialise it.. which would mean better performance, less power consumption..
              That is completely Wrong!!

              It's not inherently more efficient - it's only better if you're serializing to a format that is natively BE. By convention, a lot of network protocols are. If they were natively LE, then the shoe would be on the other foot. Neither is inherently better or worse at serialization.

              Originally posted by tuxd3v View Post
              Its also more efficient to translate from binary to decimal
              No, I'm pretty sure that's wrong. But, go ahead and explain how. If it's what I'm guessing, then I'll show you a LE version that's just as efficient.

              Comment


              • #17
                Originally posted by tuxd3v View Post
                That is completely Wrong!!

                See my comment above..
                No, you're confused. The process of byteswapping is in theory an inefficiency, but only when sending/receiving across the wire AND a lot of standards specifically denote little endian wire formats these days, since most machines are little endian and have be nigh forever.

                The larger reason LE is superior is that conversions between different sized (two's complement) integers (which happens a lot more than sending to disk or over the wire) can be accomplished just by sign extension or truncation, where BE numbers have to shift the contents.

                And really, either way, modern machines are really fast at doing these conversions, so compared to sending/receiving stuff from memory, or (orders of magnitude more expensive) sending and receiving over the network, the conversions are effectively free.
                Last edited by d4ddi0; 21 August 2019, 10:46 PM. Reason: Edit Spelling and extra sentence

                Comment


                • #18
                  Originally posted by tuxd3v View Post

                  Very Wrong!!
                  In a world of Internet and Internet of Things/Network, packing data, serialising it, etc BE is king..

                  Its Inherently more efficient to pack data, to serialise it.. which would mean better performance, less power consumption..
                  Its also more efficient to translate from binary to decimal

                  LE is like crazy,Always translating data,
                  Very poor efficiency to send/receive data using a network in a LE computer,

                  You need to use always functions for network translation, checksumming IP packets, verification its a mess, very poor efficiency..
                  Some functions needed in LE *always*
                  htons() - "Host to Network Short"
                  htonl() - "Host to Network Long"
                  ntohs() - "Network to Host Short"
                  ntohl() - "Network to Host Long"

                  Even though this functions can be called in BE( just because the litle-endians need them, if the code is shared..), *they do nothing*
                  Otherwise you don't even need to call them in BE.
                  If you ever do any work on BE, you find out a lot of (carelessly coded?) stuff breaks because either LE was specified or nobody even thought about endianness over the wire, and you end up having to use le16toh(), le32toh(), htole16(), htole32() more than you would like to get along with the rest of the world.

                  Comment


                  • #19
                    Simple example to illustrate the subtle difference between BE and LE generated code: https://gcc.godbolt.org/z/g46y1q

                    Comment


                    • #20
                      Originally posted by tuxd3v View Post

                      Very Wrong!!
                      In a world of Internet and Internet of Things/Network, packing data, serialising it, etc BE is king..

                      Its Inherently more efficient to pack data, to serialise it.. which would mean better performance, less power consumption..
                      Its also more efficient to translate from binary to decimal

                      LE is like crazy,Always translating data,
                      Very poor efficiency to send/receive data using a network in a LE computer,

                      You need to use always functions for network translation, checksumming IP packets, verification its a mess, very poor efficiency..
                      Some functions needed in LE *always*
                      htons() - "Host to Network Short"
                      htonl() - "Host to Network Long"
                      ntohs() - "Network to Host Short"
                      ntohl() - "Network to Host Long"

                      Even though this functions can be called in BE( just because the litle-endians need them, if the code is shared..), *they do nothing*
                      Otherwise you don't even need to call them in BE.
                      That's exactly what I was saying. Historically the choice has been BE, it could have been LE all the same, but it's an arbitrary pick that doesn't make one inherently more efficient for these applications than the other.

                      By the way on a modern CPU a "function" like htonl() compiles to a single instruction, bswap, so no, there is no measurable overhead induced by using LE.

                      Comment

                      Working...
                      X