4 ms·

I did some verilog in college. For many years I worked with a guy who only knew verilog and hardware design until he started coding late in his career. It was

I did some verilog in college. For many years I worked with a guy who only knew verilog and hardware design until he started coding late in his career. It was very interesting to work with his code. He used bitfields everywhere like in verilog. His functions tended to do a very small specific thing. He liked state machines and enums with long names. His style reminded me of verilog. I have not seen this coding style before or since.

CapacitorSet 10y ago
I wonder if such a "low-level" coding style, based on bitfields and state machines, generally leads to better performance than more abstract patterns. While the former is close to how a human would design hardware for that task, the latter can be better optimised by the compiler.
- robotjosh 10y ago
  It depends on if your state machine scheme is concise and makes human sense. Too many flags and state machines can become difficult to debug or work with.
- r_smart 10y ago
  In general, the consideration for bit fields is that your program will run slower but consume less memory. It's usually my opinion that we want to run as fast as possible while not running out of memory, so I'd say in general bit fields are less performant. If you can afford the memory, using a whole word for booleans will yield the fastest results, but will obviously consume way more memory. I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.
  - petra 10y ago
    With regards to state machines , there's the idea of "hierarchical state machines" which basically add hierarchy and abstraction to state machines - and they are used in some safety-critical systems and supposed to greatly help with bug prevention.
    - r_smart 10y ago
      Interesting, I've never heard of that (though I may just know it by another name). I'll have to look it up!
      - nickpsecurity 10y ago
        Variants on that are also called Abstract State Machines (ASM's), Interacting State Machines, and Composable State Machines. Those terms have most hits on Google.
  - moftz 10y ago
    Re: State Machines I'm neutral about state machines. Obviously in things like microcontrollers and HDL, state machines are really necessary. Outside of those two examples, state machines can either make code much more stable or just add unnecessary overhead with all the wasted cycles. They definitely have their place but there are better options available sometimes like threading a process. I had a project recently where we needed to build a custom message broker. A teammate wrote the entire thing in python as one big state machine. Everytime we needed to add another queue, it involved adding so much extra code to handle it. Another teammate suggested just having everything threaded so we reduce our code down to a template queue and can dynamically create them as needed. The state machine might have been more efficient memory-wise if we were doing it all in C on a PIC or more conservative in PLU usage if it was an FPGA but we were using python on a raspberry pi. We ended up with a broker that could handle more bandwidth in terms of how many queues we could publish to and consume from. Obviously we didn't really shrug off state machines. We just created many smaller ones (two states: wait for message, push message) rather than a huge one. I think the massive state machines we learn about in our freshman classes are unnecessary in many cases. Memory is so cheap that its not always worth it to be so conservative/old school. We could have just used something like rabbitmq but we didn't want the extra overhead of a service like that when we had so much more resource heavy stuff running on the pi.

CapacitorSet 10y ago

I wonder if such a "low-level" coding style, based on bitfields and state machines, generally leads to better performance than more abstract patterns. While the former is close to how a human would design hardware for that task, the latter can be better optimised by the compiler.

robotjosh 10y ago
It depends on if your state machine scheme is concise and makes human sense. Too many flags and state machines can become difficult to debug or work with.
r_smart 10y ago
In general, the consideration for bit fields is that your program will run slower but consume less memory. It's usually my opinion that we want to run as fast as possible while not running out of memory, so I'd say in general bit fields are less performant. If you can afford the memory, using a whole word for booleans will yield the fastest results, but will obviously consume way more memory. I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.
- petra 10y ago
  With regards to state machines , there's the idea of "hierarchical state machines" which basically add hierarchy and abstraction to state machines - and they are used in some safety-critical systems and supposed to greatly help with bug prevention.
  - r_smart 10y ago
    Interesting, I've never heard of that (though I may just know it by another name). I'll have to look it up!
    - nickpsecurity 10y ago
      Variants on that are also called Abstract State Machines (ASM's), Interacting State Machines, and Composable State Machines. Those terms have most hits on Google.
- moftz 10y ago
  Re: State Machines I'm neutral about state machines. Obviously in things like microcontrollers and HDL, state machines are really necessary. Outside of those two examples, state machines can either make code much more stable or just add unnecessary overhead with all the wasted cycles. They definitely have their place but there are better options available sometimes like threading a process. I had a project recently where we needed to build a custom message broker. A teammate wrote the entire thing in python as one big state machine. Everytime we needed to add another queue, it involved adding so much extra code to handle it. Another teammate suggested just having everything threaded so we reduce our code down to a template queue and can dynamically create them as needed. The state machine might have been more efficient memory-wise if we were doing it all in C on a PIC or more conservative in PLU usage if it was an FPGA but we were using python on a raspberry pi. We ended up with a broker that could handle more bandwidth in terms of how many queues we could publish to and consume from. Obviously we didn't really shrug off state machines. We just created many smaller ones (two states: wait for message, push message) rather than a huge one. I think the massive state machines we learn about in our freshman classes are unnecessary in many cases. Memory is so cheap that its not always worth it to be so conservative/old school. We could have just used something like rabbitmq but we didn't want the extra overhead of a service like that when we had so much more resource heavy stuff running on the pi.