Keen to go _ExtInt? LLVM Clang compiler adds support for custom width integers
- Reference: 1587721811
- News link: https://www.theregister.co.uk/2020/04/24/llvm_project_adds_support_for/
- Source link:
The assumption of power-of-two integer sizes is baked into computing and into the C language. "Historically these types have been sufficient for nearly all programming architectures, since power-of-two representation of integers is convenient and practical," [1]said Keane .
There is a problem, though, when it comes to configuring FPGA (Field Programmable Gate Array) chips – integrated circuits designed to be customised for specific applications. Tools called High Level Synthesis Compilers are used to generate transistor layouts for FPGAs, he added, but standard C integer types are "incredibly wasteful."
"A vast majority of the time programmers are not using the full width of their integer types".
It is true: most of the time the numbers stored are far smaller than the maximum a 32-bit integer allows, 2,147,483,647 for a signed int, for example. This does not normally make any difference, since the CPU is designed for those types, but "on FPGAs logic gates are an incredibly valuable resource, and HLS compilers should not be required to waste bits on large power of two integers when they only need a small subset of that!" Keane said.
The C language also promotes operations on types smaller than int to operations on int, he said. The result of these two factors is "massively larger FPGA/HLS programs than the programmer needed, and likely much larger than they intended. Worse, there was no way for the programmer to express their intent in the cases where they do not need the full width of a standard integer type."
The LLVM-IR (Intermediate Representation) assembly language can represent integers of any bitwidth between 1 and 16,777,215, so the [2]patch enables coders to use the new _ExtInt class of types, which translate into the corresponding LLVM-IR types. For example, "unsigned _ExtInt(9) foo;" declares a variable foo that is an unsigned integer type taking up 9 bits and represented as an i9 in LLVM-IR, said the Intel engineer.
This is the fourth attempt since 2017 to implement this feature, requested by Intel's FPGA group, and that it is "very far from over", Keane said, since it will be subject to approval by the [3]ISO/IEC WG14 standards committee , which specifies the C programming language. A [4]paper [PDF] has been submitted and received "near unanimous support" at the Spring WG14 committee meeting and could potentially be approved, with amendments, at the next WG14 meeting (set for October 2020 in Minneapolis, COVID-19 allowing), when it would become part of the language. The committee is rightly cautious about adding stuff to C so it might not happen, or it might be delayed.
Is this feature of any use outside FPGA programming? A [5]discussion on HackerNews is inconclusive. "Arbitrary bit-width integers are great for writing computer emulator code," one commenter noted, though they observed that you could use [6]Zig , which already supports arbitrary bit-width integers up to 128 bits.
C developers with an opinion on _ExtInt are invited to contact Keane or other WG14 committee members with their views.®
Sponsored: [7]How To Accelerate Brilliant Digital Experiences With Low-Code
[1] http://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html
[2] https://github.com/llvm/llvm-project/commit/5f0903e9bec97e67bf34d887bcbe9d05790de934
[3] http://www.open-std.org/jtc1/sc22/wg14/
[4] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf
[5] https://news.ycombinator.com/item?id=22946014
[6] https://ziglang.org/
[7] https://go.theregister.co.uk/tl/1936/-8552/how-to-accelerate-brilliant-digital-experiences-with-low-code?td=wptl1936
Re: Sounds like a good idea
"I've come across some real pigs to debug later when the bits "unexpectedly" overflowed into each other."
That can be avoided by only ever setting the bit(s) using carefully written macros that mask out the untouchable bits.
Re: Sounds like a good idea
The one instance that sprang to mind when I wrote the above was when the original programmer was storing a value that never went negative, so he'd used the highest bit to store something else. Until the inevitable happened and it did store a negative value.
You can also have lots of fun compressing alpha-numeric characters. If the user's input data can only consist of A-Z, 0-9, comma, full stop and Space - a total of 39 characters, you can encode this as binary in 5 bits (0 - 38 decimal). Leaving 3 bits free per byte. Luxury! So you can start your next character using the remaining 3 bits from the previous byte and so on. It was a relief when RAM and disk space increased and such binary gymnastics were no longer required.
Re: Sounds like a good idea
You’ve basically described how security arise. Make assumption. Assumption is invalidated. Shit happens.
It’s also why we (should) unit test for such things before pushing to prod. But hey, testing is boring so we don’t do it right?
As to using unused bits - plenty of tech still does that. The Deflate also, ASN.1 PER etc. It’s not going away.
Re: Sounds like a good idea
Of course it should be tested! I never said it shouldn't. I'm saying the idea in principle sounds good and should be looked into, not just dismissed out of hand. There could easily be issues found that make it a non-starter. We won't know until it is properly researched and tested.
Sounds like a good idea
No point wasting time processing unused bits. Reminds me of my early days programming in the 70's and 80's when RAM and disk space was at an absolute premium and I (everyone really) used all manner of weird and wonderful ways to compress data to the minimum. It did of course eventually lead to problems like Y2K with an assumed "19" or "20" depending on whether the year was more or less than 80 for example. It did make handling other people's poorly documented code a nightmare though, especially if they munged multiple values into one integer variable (using higher bit positions) to hold boolean or other data; no bits wasted. I've come across some real pigs to debug later when the bits "unexpectedly" overflowed into each other.