24 bit integer

Anybody got any ideas about how I could implement 24 bit integer types? For example, with some compilers I've seen things like:-

typedef long long int Int64;
typedef unsigned long long int UInt64;

which are used for 64 bit types, but I want 24 bit types (3 bytes). I'd want to be able to do normal maths with them (plus, minus, multiply, divide etc) and assign values such as:-

UInt32 x = 24117248; // 0x1700000 (this overflows a 24 bit Uint)
UInt24 y = x; // result would equal 7340032 (0x700000) which is within range.

[Edit]
Ideally, they should also be capable of being cast to any of the other integer types - e.g.

Code:

---

Int32 SomeFuncThatRequiresA16BitInt ( Int16 n )
{
        return (n * 65536);
}

Int24 x = 29;

Int32 y = SomeFuncThatRequiresA16BitInt ((Int16) x );

---

You have to emulate it. 64-bit operations are supported on some machines, emulated by the compiler on others. 32-bit operations are supported nearly everywhere. 24 bits are an odd number of bytes, leading to inefficiencies were they supported. Thus you need to emulate them or, better, use 32-bit numbers.

The only reason to use 24-bit integers as opposed to 32-bit integers is due to issues regarding critical storage space.

This happens in my developments sometimes.

In order to emulate 24-bit native support, I usually use a data array of 3 bytes. The low word of the array holds the lower 16-bits and the single low byte of the single high 8-bit 'word' holds the upper 8-bits. Do all of the mathematics using standard 32-bit integers. Convert the results of the 32-bit integer calculations to the 3-byte storage scheme.

You can set this up in a clean C++ class if you want. Most compilers will align the size of such a class to 4 bytes anyway, so you might have to force single-byte alignment.

If you really want to do it, then I could work out some examples next week. I've got some stuff written in ANSI C related for this also.

Sincerely, Chris.

:thumb:

Thanks CornedBee but I guess what I'm asking is whether anyone has any code for emulating 24 bit ints. Using 32 bit ints isn't viable because of lack of overflow checking - e.g.

typedef long Int24;

Int24 x = 8400000; // This would result in a value for 'x' of 8400000, which would be invalid for a genuine, signed 24 bit int.

My "gut feeling" is that someone, somewhere must have solved this problem before.

Thanks for the offer Chris. The main reason I need this is to carry out signal processing on an audio stream. Audio streams are typically 8, 16 or 24 bit data so there's an immediate problem with 24 bit data because it has an 'unsupported' number of bytes per sample. A further problem with audio is that some systems use little-endian byte ordering and some use big-endian. Therefore, if the audio is 24 bit, I'm tryng to find some way of extracting exactly 3 bytes of data (per sample) for processing. Because of the byte ordering problem I'd need to do this, ideally, without an erroneous fourth byte.

VivÃ*simo - Clustered search on +audio +24 bit integer

John,

In addition to all the comments so far, it sounds like you really don't need the 'full-blown' 24-bit integer solution that I sometimes use for tightly packed embedded systems.

Simple get and put functions with some range checking might be sufficient.

Take a look at this sample below which shows an example for a rudimentary get function. There is some basic support for the two styles of endedness.

Maybe this will get you started.

Sincerely, Chris.

P.S. The casting back and forth has a sensible foundation and should not be neglected.

:)

Code:

---


#include <iostream>

typedef  signed char INT8;
typedef  signed int  INT32;
typedef unsigned char UINT8;
typedef unsigned int  UINT32;

const INT32 get_n24(const UINT8* p, const bool b_little_endian = true)
{
  INT32 n;
 
  if(b_little_endian)
  {
    n =  (static_cast< INT32>(static_cast<INT8>(p[2])) * 0x10000)
        | (static_cast<UINT32>(p[1]) * 0x100)
        |  static_cast<UINT32>(p[0]);
  }
  else
  {
    n =  (static_cast< INT32>(static_cast<INT8>(p[0])) * 0x10000)
        | (static_cast<UINT32>(p[1]) * 0x100)
        |  static_cast<UINT32>(p[2]);
  }
 
  return n;
}

int main(int argc, char* argv[])
{
  UINT8 data[3] = { 0xFF, 0xFF, 0xAF };
 
  INT32 n32 = ::get_n24(data);
 
  ::std::cout << n32 << ::std::endl;
 
  return 0;
}

---

Thanks guys. I'll look at your suggestions, later today. In the meantime, I thought of an alternative approach. Does anybody understand the mechanism whereby CString (a class) can represent itself as though it was a LPCTSTR?

Ideally, that's what I need. A class that can "disguise itself" as though it were an integer - but whose operators (+, -, = etc) could all be overloaded to simulate 24 bit arithmetic. If CString can pretend to be a const TCHAR*, it must be possible for other classes to do something similar.

John,

You are talking about the cast operator from CString to char*. In my opinion, this is not the way to go. I do not think that the use of strings for 24-bit numeric manipulation is effective.

Why don't you just write an int24 class based on three bytes with a possible sign flag? You can overload all the arithmetic operators in a very effective and clean fashion.

Do you know how to do this? If not, I'll be happy to write a few lines for you to get you started.

One question first: Are the 24-bit integers signed or unsigned?

Sincerely, Chris.

:thumb:

Hi Chris - thanks for your help with this.

I was only using CString as an example of a class that can disguise itself as TCHAR*. I didn't mean to imply that the maths should be done using strings. Sorry for any confustion.

I should be okay with creating a class and overloading its operators. The bit I don't understand is how to make a class pass itself off as a specified type, like CString can do.

If you look in my original post, I gave an example of how the custom Int24 variable would need to limit itself to 24 bit arithmetic and should also be "passable" to functions that require an integer. In a perfect world it would also store its data in 3 bytes, if possible. If you've got any code that could start me off I'd be very grateful. You don't need to worry about dealing with the 24 bit math limitations. I'll be able to code that myself.

Incidentally, I need to handle both signed and unsigned data - although my inclination was to have different custom variables for each.

It looks like this:

Code:

---

class int24
{
  int value;

public:
  int24() {}
  int24(const int24 &o) { value = o.value; }
  int24(int i) { //bounds check and assign }
  ...

  operator int() { return value; }

  int24 &operator =(const int24 &o) {
    value = o.value;
    return *this;
  }
  int24 &operator =(int i) {
    // bounds check and assign
  }
  ...
};

---

In the definition of CString (in afx.h) is:

Code:

---

operator LPCTSTR() const;

---

In afx.inl is:

Code:

---

_AFX_INLINE CString::operator LPCTSTR() const
  { return m_pchData; }

---

That means that LPCTSTR for CString works in the manner that the "operator int" works for CornedBee's int24 class.

OK let's finish this one.

John,

Corned Bee and Sam Hobbs have added the stuff about the casting operator.

I've got the source for 24-bit integer. It is attatched below in the form of full source code. Intentionally all cast overwrites are left out. So if you want 'em you'll have to add 'em.

I extracted this work from some of my other developments. I've been meaning to do this for quite some time now and this post kick-started me. This code is absolutely new and it has not been verified significantly.

Take a look. The syntax and algorithms will be usefull. Or you might simply take the entire class.

Sincerely, Chris.

:cool:

Quote:

---

Originally posted by dude_1967
Intentionally all cast overwrites are left out.

---

For C++ programmers, überschreiben usually means override, not overwrite. I don't know German but I can tell from the context when the word should be override instead of overwrite. Read my little Overwriting for a bit more.

Yes, Sam is right. In the context of classes, überschreiben should be override.

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.