Comments on: Three byte integers

By: Nigel Jones

Nigel Jones — Mon, 02 Nov 2009 13:17:55 +0000

A very thoughtful comment hth313. I must say I'm always impressed by the quality of the comments I get on this blog. I take your point that adding support for 3 byte integers is non trivial. In fact I'm sure a compiler writer could probably come up with a few more objections. I guess my main thought is that an embedded C compiler is supposed to be a useful tool to allow us to get our jobs done. Instead it's sub-optimal for reasons that have virtually nothing to do with our industry. Given the size of the embedded market place, surely we deserve tools that are optimal for us? Why do we always have to play second fiddle to the general computing market place?

By: hth313

hth313 — Fri, 30 Oct 2009 10:48:23 +0000

I do not think it is all that easy.You need many more operations for integers compared to pointers. You need to add; * / << >> switch, signed compare and more cast rules.That is just to get it to work, then you may need to make it generate good code as well, and that may cost a lot more.I think you hit the real reasons with your original post, lack of people asking for it and lack of code base (for benchmarking) that suggest it would be good. If done by a compiler vendor, it may just end up being regarded as something odd that is a potential source of portability problems.You will also end up in a funny situation with integral promotion. Will it be promoted to something smaller or bigger (or even same) as int24_t? Implementations will be all over the place.With short, you know int will be at least as large, and long may equal or larger than int.With int24_t, you would have no firm rule on which side of int it will be, add in standard integral promotion and you will be in for some interesting portability issues going between 16 and 32 bit ints.What about printf-formatting? Should int24_t be promoted to int if it fits inside it, or long if it does not?But in general I agree with the article, a 24 bit size makes sense. 16-bit is sometimes small and you seldom need all the bits in a 32-bit.

By: Nigel Jones

Nigel Jones — Sat, 10 Oct 2009 12:31:21 +0000

Very interesting Tom. When I wrote the blog posting, I was thinking exclusively about pure integers. However, your comment reminds me that many processors have an address space that fits nicely into 24 bits – and thus that pointer types are often represented as 3 byte types. Thus if a compiler can support three byte pointer arithmetic, surely it would easy enough to add support for three byte integers?

By: Tom Evans

Tom Evans — Sat, 10 Oct 2009 05:12:20 +0000

> Now a quick web search indicates> that there may be the odd compiler> out there that supports 3 byte> integers – but the vast majority> do not.I know of one that did, sort of. But they fixed that bug.The Renesas M32C/80 series has four 16-bit data registers (with R0 and R1 only supporting byte ops, and R0R2 and R1R3 supporting 32-bit ops) and two 24-bit “Address Registers”. It also has 24-bit SB, FP, PC and so on.One version of the compiler preferred to perform all pointer arithmetic in the 3-byte address registers. This was a good use of the resources (leaving the two 32-bit registers free for data ops). The next version of the compiler generated completely different code, performing all address arithmetic in the 4-byte R0R2 and R1R3 registers, and then copying to A0 and A1 for access. I don't know if this was to pass some “standard C test code” or to share compiler technology with other CPUs, but this is an example of “efficient use of 3-byte arithmetic” that was then removed.If a compiler did support “int24_t” then it would make the integral promotion rules a lot more interesting.

By: Uhmmmm

Uhmmmm — Thu, 11 Jun 2009 21:48:05 +0000

In the first example of the temporary value overflowing, there's no reason (in theory) that the compiler couldn't determine that a 24 bit temporary is enough in many cases. Certainly for a constant coefficient, it should be able to determine it.Not that I know of any compiler that does it. But in theory it's possible without a new type.