24 bit integer

Quote:

---

Originally posted by dude_1967
all cast overwrites are left out. So if you want 'em you'll have to add 'em.

---

No problem Chris. That bit I can do!! In fact I was tinkering about with CornedBee's sample this afternoon and it's given me loads of ideas.

Quote:

---

Originally posted by dude_1967
This code is absolutely new and it has not been verified significantly.

---

The only thing I've noticed is that I can't figure out if it's big endian or little endian - e.g. the constructor:-

Code:

---

explicit inline c_integer24(const UINT32 u)
{
      m_data[2] = static_cast<UINT8>(u);
      m_data[1] = static_cast<UINT8>(u >> 8);
      m_data[0] = static_cast<UINT8>(u >> 16);
}

---

appears big endian but I wasn't sure if it was just a typo.



Thanks to everyone BTW. I think I'll be busy for the next few days!

Sorry, what I meant by the above was that if I do this:-

c_integer24 myInt24(45);

I expected m_data[0] to be 45, m_data[1] to be zero and m_data[2] to be zero.

In fact, m_data[2] was set to 45 and the others were zero. Hope that explains it a bit better.

Yes John,

My implementation c_integer24 uses the big endian storage convention. This differs from modern Intel and VAX systems. When converting from integer quantities within one hardware system, no caution is needed and the storage convention is irrelevant since the internal format is applied using shifts.

However, if you want to include support for data which might be coming from various hardware sources, then you need a ctor from UINT8* with a flag indication of the endedness as shown below.

Code:

---


    explicit c_integer24(const UINT8* const p, const bool b_little_endian = true)
    {
      // Constructor from a byte data pointer providing support
      // for data from various hardware systems. There is support
      // for both little endian format as well as big endian
      // format based on the value of the bool input parameter
      // 'b_little_endian'. The default endedness is little endian,
      // which is compatible with modern Intel and VAX systems,
      // whereby bytes at lower addresses have lower significance.
      // Example: With little endian, the value 0x123456 is stored
      // in memory location m as m[0] = 0x56, m[1] = 0x34, m[2] = 0x12.
      // Since c_integer24 uses the big endian storage convention,
      // the order must be reversed for little endian byte pointer
      // inputs.
      m_data[0] = b_little_endian ? p[2] : p[0];
      m_data[1] = p[1];
      m_data[2] = b_little_endian ? p[0] : p[2];
    }

---

This ctor can be tested with sample code such as the following:

Code:

---


  ::std::cout.unsetf(::std::ios::dec);
  ::std::cout.setf(::std::ios::hex | ::std::ios::showbase);

  const INT32 test_endian_n32 = 0x123456;
  c_integer24 test_endian_n24(reinterpret_cast<const UINT8*>(&test_endian_n32));

  ::std::cout << test_endian_n24 << ::std::endl;
  ::std::cout << test_endian_n32 << ::std::endl;

---

I modified my class for the sake of completeness and included it here as an attatchment once again.

Sincerely, Chris.

P.S.

I'll try to watch out for that overwriting / overriding thing in future posts. But I've already forgotten which one is correct...

Chris.

:cool:

Just a thought here... If you you are not constrained by some other API that requires arrays of 3-byte data, then you may be able to still use 32-bit data --- just bit shift the data before and after you are done with it:

Code:

---

// could redefine this if you are working on 9-bit or 12-bit platforms
const unsigned bits_per_byte = 8;

inline unsigned long FromAudio(unsigned long input)
{
    return input << (sizeof(unsigned long)*bits_per_byte-24);
}

inline unsigned long ToAudio(unsigned long input)
{
    return input >> (sizeof(unsigned long)*bits_per_byte-24);
}

void processAudio()
{
    // read data using FromAudio()

    // process data using 32-bit integer math

    // write data using ToAudio()
}

---

Then all your data processing will be done efficiently using your machine's integer processing unit instead of C++ code. Only the reading and writing of your data will take longer.

Just an idea.

- Kevin

Here's another question. I'm pretty sure I know the answer to this but I'm not 100% certain....

Let's suppose we have 4 bytes holding a 32 bit int and for the sake of argument we're considering these bytes as an array (this is all just theretical). In a little endian system the leftmost byte is least significant and would be array[0]. The rightmost byte is most significant and in this example it would be array[3].

What happens in a big endian system? Obviously, the leftmost byte is now most significant - but how is it numbered? Is it still array[0]? Or is it now array[3]?

In other words, with a big endian sytem are the elements of an array still numbered e[0], e[1], e[2], ... e[n]? Or is the numbering also reversed - i.e. e[n], ... e[2], e[1], e[0]?

The array numbering remains unchanged. The actual address locations in physical memory are reversed with respect to the two systems.

Chris.