6 ms·

I'd love to know if there's any use to this beyond FPGAs. This just seems to be another case of porting the complexity of RTL design into C syntax so that they

I'd love to know if there's any use to this beyond FPGAs. This just seems to be another case of porting the complexity of RTL design into C syntax so that they can claim they have an HLS product that compiles C to gates. It's not C to gates if you had to rewrite all your C to manually specific the bit widths of every single signal. I really wonder how far we can keep going before the naming police break into Intel Headquarters and rename all their marketing material with "Low Level Synthesis".

jschwartzi 7y ago
It provides another way to represent individual register fields without using bitfields. And probably gives you stronger guarantees about what happens when the bitfield overflows. It also provides a way to pass those values around without passing the whole register struct around.
deleted 7y ago
[deleted]
pjc50 7y ago
I was wondering that, and share your skepticism of autotranslation (it basically never works, and the only reason people like it is that the HDLs are stuck in the 80s). But I think the "no automatic promotion or conversion" combined with "will error if combined with different width" could actually make extint(8) and extint(16) useful - it's a massive hint to autovectorisers and lets you generate the SIMD instructions for those widths. Doubly so if they make sure never to write the words "undefined" where they mean "implementation-defined" for extint. At the moment normal arithmetic in C (x = x+1) is potentially undefined behaviour.
- qppo 7y ago
  High level synthesis works perfectly fine, just not from C. HDLs have chugged along too, it's just the toolchains are ridiculously expensive and risky to change. That's why hardware tech stacks lag behind the state-of-the-art. I share the skepticism of high level synthesis from C as being a bad motivation. The workflow is more like metaprogramming, and C is terrible at that.
  - gpanders 7y ago
    > High level synthesis works perfectly fine, just not from C What other HLS languages have you used? I'm not aware of any apart from C (and a limited subset of C++).
    - nybble41 7y ago
      Clash[1] is one HLS language which generates HDL from a large subset of Haskell. The language is Haskell, actually, but not every construct can be synthesized; e.g. recursive data types and FFI calls have no HDL equivalent. Clash hooks into the compiler (GHC) and generates HDL from the intermediate representation. You can also run the Haskell code directly to see the simulated output. [1] https://clash-lang.org/ https://clash-lang.org/
      - gpanders 7y ago
        That is very cool. Alas, most of the other hardware engineers I work with can hardly write C, let alone Haskell, so I very much doubt I'll ever be able to use this at my job. But I like to see that there is innovation in this space and that people are trying new things.
mratsim 7y ago
Cryptography. Want to do finite field computation on a 254-bit integer? Now you can (BN254, very popular for zero-knowledge proofs) 381-bit? you're covered. It's very perf critical and the field modulus bitsize and values are known at compile-time. (example in my library where I basically add to implement the same machinery: https://github.com/mratsim/constantine/blob/ff9dec48/constantine/config/curves_declaration.nim#L79-L201 https://github.com/mratsim/constantine/blob/ff9dec48/constan...)
- ori_b 7y ago
  Does the compiler guarantee constant time? If not, it's still useless for cryptography. If it does, then it becomes useless for regular work because plain bigint will kick it's ass on performance, especially when doing division. This is an efficiency hack for fpga.
  - steerablesafe 7y ago
    Compilers generally never guarantee constant time. The C and C++ standards have no notion of observing timing.
    - 0xFFC 7y ago
      What is observing timing?
      - qznc 7y ago
        One could imagine an annotation for if-statements that both branches should run for the same number of instructions or cycles.
        deleted 7y ago
        [deleted]
      - steerablesafe 7y ago
        I meant "observation of timing".
elgfare 7y ago
I can see this being used in serialization protocols.
steerablesafe 7y ago
Generic code for getting the high 64 part from unsigned unsigned integer multiplication of 64 bit values. Can be useful for fixed-point math for example.
zamadatix 7y ago
Network protocols immediately came to mind for me. They love packed structs of weird bit sizes because anything that's not payload is overhead on every message for the rest of time. Fields can also be large, e.g. VLANs are 12 bits, VXLAN ids are 24 bits, MAC addresses are 48 bits, IPv6 addresses are 128 bits so it's not just limited to a couple of small sized bitflag style things.
- SlowRobotAhead 7y ago
  You can already do this in C though, If EVER SO SLIGHTLY wasteful in non-practical terms. If you need a 23bit object you just structure it to be that. It’s a couple of AND or SHIFT ops when accessing, but so what? Even for 100Gbit networking you aren’t going to max out even a slightly appropriate CPU.
  - detaro 7y ago
    You probably could get the compiler to shout at you for a few more mistakes with explicit types?
  - zamadatix 7y ago
    The same argument could be made to get rid of all numeric types except the largest. That's likely how it would compile down to on platforms without 23 bit types though just it would be handled automatically based on target. I think the point of such a feature is to abstract you from thinking about if the machine has a native 23 bit type the same way you don't think if the machine has a native 64 bit type or a hardware float type today. Also when you do this manually you're now responsible for tracking the actual type and such too. Beyond that you also want to do operations on these fields not just store them and ignore them, does the IP match this policy? Have I learned this MAC? Is this TOS in an allowed range or does it need to be bleached? Constantly pulling these out and putting them back in, the above work isn't a one time thing. 100 Gigabit networking eats more CPU than you think, especially if you're actually looking at headers. It's an enormous portion of cloud CPU usage and a big reason networking is still driven by what's easy to put in an ASIC vs running the easier thing in software.
- 7y ago
steerablesafe 7y ago
Although it's static size, it could be a building block for bignum arithmetic. The last time I tried compilers were pretty bad at optimizing generic code for bignum addition, although it's pretty easy to hand-optimize in assembly.
moonchild 7y ago
They fixed autopromotion rules: > if a Binary expression involves operands which are both _ExtInt, rather than promoting both operands to int the narrower operand will be promoted to match the size of the wider operand, and the result of the binary operation is the wider type.
flohofwoe 7y ago
Admittedly also hardware-related, but: Arbitrary bit-width integers are great for writing computer emulator code. There's a ton of odd-width counters and registers in microchips, and being able to map those directly to integer variables instead of having to do a "bit-mask-dance" after each operation at least would increase readability (and probably also add a bit of type-safety). (Zig also has arbitrary bit-width integers up to 128 bits, but other then that I haven't seen this outside of hardware-description-languages).
strenholme 7y ago
Well, encryption research. RadioGatún (SHA-3’s direct predecessor), for example, allows the bit width to be any number between 1 and 64, so this will allow us to see how, say, 29-bit integers work with this algorithm. Most cryptographic algorithms (notably RC5 and RC6, but also Rijndael/AES) can be extended in to 128-bit word size variants, and having guaranteed support for 128-bit integers in C would be useful to see how these variants act, and run programs to evaluate their security margin.
bubblethink 7y ago
There's also the obvious compression use case. Assuming the rest of your code is sufficiently robust, you can shave off all the excess bits from your data storage. There may be a performance penalty, but you won't have to deal with low level ops or alignment issues. Most real world big data will exceed 32 bits (i.e., the identifiers will exceed 32 bits), but is nowhere close to 64 bits. The benefit is more meaningful if your data now fits in a cache/fast memory whereas it didn't before.
huit 7y ago
It's not C to gates if you had to rewrite all your C to manually specific the bit widths of every single signal Ideally, for FPGA design you only have to use the special bitwidths for the interface of a module. The implementation can be in normal wider C types. The compiler can optimize these operations to smaller bitwidths by realizing the higher input bits are zero/signextend and higher output bits are not used. You can help the optimizer by making some variables smaller bitwidths, but no need to rewrite everything. I implemented this once for a c-to-hardware compiler and it worked quite well. The compiler had a lot of builtin-types, all signed and unsigned integers from 1 to 64 bits wide, named __int1..int64. See 'extended integer types' in the manual: http://valhalla.altium.com/Learning-Guides/GU0122%20C-to-Hardware%20Compiler%20User%20Manual.pdf http://valhalla.altium.com/Learning-Guides/GU0122%20C-to-Har...

jschwartzi 7y ago

It provides another way to represent individual register fields without using bitfields. And probably gives you stronger guarantees about what happens when the bitfield overflows. It also provides a way to pass those values around without passing the whole register struct around.

deleted 7y ago

[deleted]

pjc50 7y ago

I was wondering that, and share your skepticism of autotranslation (it basically never works, and the only reason people like it is that the HDLs are stuck in the 80s). But I think the "no automatic promotion or conversion" combined with "will error if combined with different width" could actually make extint(8) and extint(16) useful - it's a massive hint to autovectorisers and lets you generate the SIMD instructions for those widths. Doubly so if they make sure never to write the words "undefined" where they mean "implementation-defined" for extint. At the moment normal arithmetic in C (x = x+1) is potentially undefined behaviour.

qppo 7y ago
High level synthesis works perfectly fine, just not from C. HDLs have chugged along too, it's just the toolchains are ridiculously expensive and risky to change. That's why hardware tech stacks lag behind the state-of-the-art. I share the skepticism of high level synthesis from C as being a bad motivation. The workflow is more like metaprogramming, and C is terrible at that.
- gpanders 7y ago
  > High level synthesis works perfectly fine, just not from C What other HLS languages have you used? I'm not aware of any apart from C (and a limited subset of C++).
  - nybble41 7y ago
    Clash[1] is one HLS language which generates HDL from a large subset of Haskell. The language is Haskell, actually, but not every construct can be synthesized; e.g. recursive data types and FFI calls have no HDL equivalent. Clash hooks into the compiler (GHC) and generates HDL from the intermediate representation. You can also run the Haskell code directly to see the simulated output. [1] https://clash-lang.org/ https://clash-lang.org/
    - gpanders 7y ago
      That is very cool. Alas, most of the other hardware engineers I work with can hardly write C, let alone Haskell, so I very much doubt I'll ever be able to use this at my job. But I like to see that there is innovation in this space and that people are trying new things.

mratsim 7y ago

Cryptography. Want to do finite field computation on a 254-bit integer? Now you can (BN254, very popular for zero-knowledge proofs) 381-bit? you're covered. It's very perf critical and the field modulus bitsize and values are known at compile-time. (example in my library where I basically add to implement the same machinery: https://github.com/mratsim/constantine/blob/ff9dec48/constantine/config/curves_declaration.nim#L79-L201 https://github.com/mratsim/constantine/blob/ff9dec48/constan...)

ori_b 7y ago
Does the compiler guarantee constant time? If not, it's still useless for cryptography. If it does, then it becomes useless for regular work because plain bigint will kick it's ass on performance, especially when doing division. This is an efficiency hack for fpga.
- steerablesafe 7y ago
  Compilers generally never guarantee constant time. The C and C++ standards have no notion of observing timing.
  - 0xFFC 7y ago
    What is observing timing?
    - qznc 7y ago
      One could imagine an annotation for if-statements that both branches should run for the same number of instructions or cycles.
      - deleted 7y ago
        [deleted]
    - steerablesafe 7y ago
      I meant "observation of timing".

elgfare 7y ago

I can see this being used in serialization protocols.

steerablesafe 7y ago

Generic code for getting the high 64 part from unsigned unsigned integer multiplication of 64 bit values. Can be useful for fixed-point math for example.

zamadatix 7y ago

Network protocols immediately came to mind for me. They love packed structs of weird bit sizes because anything that's not payload is overhead on every message for the rest of time. Fields can also be large, e.g. VLANs are 12 bits, VXLAN ids are 24 bits, MAC addresses are 48 bits, IPv6 addresses are 128 bits so it's not just limited to a couple of small sized bitflag style things.

SlowRobotAhead 7y ago
You can already do this in C though, If EVER SO SLIGHTLY wasteful in non-practical terms. If you need a 23bit object you just structure it to be that. It’s a couple of AND or SHIFT ops when accessing, but so what? Even for 100Gbit networking you aren’t going to max out even a slightly appropriate CPU.
- detaro 7y ago
  You probably could get the compiler to shout at you for a few more mistakes with explicit types?
- zamadatix 7y ago
  The same argument could be made to get rid of all numeric types except the largest. That's likely how it would compile down to on platforms without 23 bit types though just it would be handled automatically based on target. I think the point of such a feature is to abstract you from thinking about if the machine has a native 23 bit type the same way you don't think if the machine has a native 64 bit type or a hardware float type today. Also when you do this manually you're now responsible for tracking the actual type and such too. Beyond that you also want to do operations on these fields not just store them and ignore them, does the IP match this policy? Have I learned this MAC? Is this TOS in an allowed range or does it need to be bleached? Constantly pulling these out and putting them back in, the above work isn't a one time thing. 100 Gigabit networking eats more CPU than you think, especially if you're actually looking at headers. It's an enormous portion of cloud CPU usage and a big reason networking is still driven by what's easy to put in an ASIC vs running the easier thing in software.
7y ago

steerablesafe 7y ago

Although it's static size, it could be a building block for bignum arithmetic. The last time I tried compilers were pretty bad at optimizing generic code for bignum addition, although it's pretty easy to hand-optimize in assembly.

moonchild 7y ago

They fixed autopromotion rules: > if a Binary expression involves operands which are both _ExtInt, rather than promoting both operands to int the narrower operand will be promoted to match the size of the wider operand, and the result of the binary operation is the wider type.

flohofwoe 7y ago

Admittedly also hardware-related, but: Arbitrary bit-width integers are great for writing computer emulator code. There's a ton of odd-width counters and registers in microchips, and being able to map those directly to integer variables instead of having to do a "bit-mask-dance" after each operation at least would increase readability (and probably also add a bit of type-safety). (Zig also has arbitrary bit-width integers up to 128 bits, but other then that I haven't seen this outside of hardware-description-languages).

strenholme 7y ago

Well, encryption research. RadioGatún (SHA-3’s direct predecessor), for example, allows the bit width to be any number between 1 and 64, so this will allow us to see how, say, 29-bit integers work with this algorithm. Most cryptographic algorithms (notably RC5 and RC6, but also Rijndael/AES) can be extended in to 128-bit word size variants, and having guaranteed support for 128-bit integers in C would be useful to see how these variants act, and run programs to evaluate their security margin.

bubblethink 7y ago

There's also the obvious compression use case. Assuming the rest of your code is sufficiently robust, you can shave off all the excess bits from your data storage. There may be a performance penalty, but you won't have to deal with low level ops or alignment issues. Most real world big data will exceed 32 bits (i.e., the identifiers will exceed 32 bits), but is nowhere close to 64 bits. The benefit is more meaningful if your data now fits in a cache/fast memory whereas it didn't before.

huit 7y ago

It's not C to gates if you had to rewrite all your C to manually specific the bit widths of every single signal Ideally, for FPGA design you only have to use the special bitwidths for the interface of a module. The implementation can be in normal wider C types. The compiler can optimize these operations to smaller bitwidths by realizing the higher input bits are zero/signextend and higher output bits are not used. You can help the optimizer by making some variables smaller bitwidths, but no need to rewrite everything. I implemented this once for a c-to-hardware compiler and it worked quite well. The compiler had a lot of builtin-types, all signed and unsigned integers from 1 to 64 bits wide, named __int1..int64. See 'extended integer types' in the manual: http://valhalla.altium.com/Learning-Guides/GU0122%20C-to-Hardware%20Compiler%20User%20Manual.pdf http://valhalla.altium.com/Learning-Guides/GU0122%20C-to-Har...