5

I'm working on a library that supports file reading, and right now I've always assumed that all the bytes are written in most significant bit first format. Is the least significant bit first format ever practically used anywhere today on any platform? The library I'm writing isn't targeted at older operating systems (ideally anything onwards from the year 2000).

I'm curious if writing such a feature in might be a waste of time that could be spent on other things.

Water
  • 356
  • 1
  • 12
  • 4
    As far as I know, "least significant bit" is merely a name for the bit in a word with the smallest positional value. I am not aware of any "format" or encoding that goes by that name. Are you perhaps confusing this with the terms *big endian* and *little endian*? –  Mar 03 '15 at 21:55
  • 6
    Little Endian vs. Big Endian is about byte order, not bit order! The smallest addressable unit is usually a byte or a word, and the data inside this unit is just an opaque number. The position of single bits cannot be determined and is not relevant. A byte will have a least significant bit and a most significant bit, but the question of which bit comes first, is mu, is empty. – amon Mar 03 '15 at 22:06
  • 2
    Big endian byte order is used *EVERYWHERE* - not just natively on certain non-x86 architectures like SPARC, but also every time you transmit binary data over a network. DNS, HTTP 2.0, and many other standards transmit integers in network byte order ("big endian"), meaning that any program which implements or deals with such protocols must deal with big endian format. – Charles Salvia Mar 03 '15 at 22:20
  • @GregHewgill: That's because there are things about Little Endian that make it convenient for designing CPU architectures. Also, because Intel (Intel is uniformly Little Endian). – Robert Harvey Mar 03 '15 at 22:31
  • 4
    I don't know why people are bringing up little/big endian byte order. My question is about *bit* order, not byte order. I already know and have written stuff for little/big endian. Edit: This is directed at the people that are confused if I'm asking about byte order. – Water Mar 03 '15 at 22:39
  • 5
    Within the scope you set, there **is no** bit-order, as the data is written in chunks of *byte*s. – Deduplicator Mar 03 '15 at 23:11
  • @Water: My suggestion is to further clarify your purpose: does "a library that supports file reading" mean ["all utility functions one will ever need for decoding all digital formats ever in existence"](http://www.digitalpreservation.gov/formats/fdd/descriptions.shtml)? – rwong Mar 03 '15 at 23:28
  • If the bits were in another order (where, in what sense?), I don't think your software could actually notice that. – RemcoGerlich Mar 04 '15 at 08:07
  • 2
    Since the OP has clarified that the question really is about "bit order" and not endianness, I have deleted my now-unrelated comments. – Greg Hewgill Mar 04 '15 at 19:23

3 Answers3

11

Well, you might have heard of a little thing called Ethernet, which transmits most-significant byte first, but least-significant bit first.

The thing is, no one cares unless they happen to be designing an Ethernet card, because the card's hardware packs the data into bytes, which is how it's accessed everywhere else in the system.

So if your library happens to be designed to run directly on a disk drive controller chip, and you have to read data written by other controllers following their own standards, by all means include the option. Anywhere else, it doesn't matter.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
3

If you are looking for a very precise answer, you will need to define very precisely what "least significant bit format" means. As evident in the comments, there can be a lot of interpretations of what that means, and a lot of details can be glossed over by a not very careful reader.

Example #1 - BMP image format, for black-white (1bpp)

For one example of "least significant bit first format", consider the BMP image format, 1bpp.

A black and white (bitonal, or 1-bit-per-pixel) image stored as BMP will have its row-zero, column-zero pixel stored at the bit 7 of the byte 0 of the pixel data area.

As a matter of arithmetic, the term "bit 7" always unambiguously refer to the bit mask 0x80, because it is the "7th digit of its binary representation". (the 0th digit is the bit mask 0x01.)

Example #2 - TIFF Fax

http://www.awaresystems.be/imaging/tiff/tifftags/fillorder.html

The original TIFF Fax specification was designed with hardware (electronic) implementations in mind, and therefore has to deal with electrical serialization and deserialization. With it comes the choice of which bit to send down the wire first. Thus, the specification allows for both, and therefore every TIFF image reader has to support reading both kinds of files and to perform the necessary conversion before decoding the bit stream.

rwong
  • 16,695
  • 3
  • 33
  • 81
  • 1
    Good examples. Of course, those image format decoders are unlikely to expect the file io library to perform the reversal. – Karl Bielefeldt Mar 03 '15 at 23:19
  • @KarlBielefeldt one would not expect the File IO to have these utilities, but would certainly expect them in an Endianness utility or a Bit Array utility. In particular, bit endianness must also be considered in conjunction with bit-packing (such as used in [Huffman code](http://en.wikipedia.org/wiki/Huffman_coding) ) - one will need to read "7 bits", with a particular bit-endianness, and which *straddles two bytes* (i.e. not aligned or confined by byte boundaries). It all depends on needs and specification. – rwong Mar 03 '15 at 23:32
  • Agreed. Oh, the perils of a vaguely-specified question :-) – Karl Bielefeldt Mar 04 '15 at 00:30
1

Given that things such as characters / letters, numbers, and raw in essentially every format and programming language use the most significant bit first format, you can apply the ostrich solution to this problem. Your time is better spent working on the actual library itself instead of a feature that will likely never be needed.

Also, as some people have mentioned, a decent amount of integers that use the least-significant-* format use the most-significant-byte format which is a different thing.

user16871
  • 111
  • 2