Douglas McIlroy writes: I hate to take issue with Doug's explanation since he's a lot smarter than me. In my opinion, spaghetti code is a choice while random logic is not. In both cases, I have an underlying assumption that the hardware designer or coder is implementing someone else's design and doesn't have the ability to say "I could do a cleaner implementation if we could make a design change." While one could almost always do a "regular" implementation instead of a "random" one in hardware the regular one would likely be more expensive in terms of resources like speed, space, cost, and power than the random one. Of course, that's not always true. In the blast from the past department, I had to implement something around 1980 where there was no chance of meeting the timing requirements using random gates. At the time, and my memory is fuzzy here, AMD had a very fast 1Kx8 PROM. Instead of using random logic I used a couple of these, and wrote a compiler that converted logic equations into bit patterns for burning the PROMs. It was actually that project that got me back into doing software. Plus, of course, the fact that our department finally gave up on DEC operating systems and starting running UNIX. Random logic design is way different than it used to be. Back when I was in college, we had a Digital Logic Design course that focused on Karnaugh maps and all that sort of logic minimization stuff. I made a deal with my professor. I'd teach the class instead of taking it and annoying the crap out of him. In addition to the regular class material, I added TI's "The TTL Book". The new idea that I brought to the class was that gates came in packages, and one had to balance logic minimization with package minimization. So for example, if you needed an inverter and none was available but you had an extra NAND gate in a 7400 you could use it as an inverter instead of adding another package of which 5/6 of the gates would be unused. Today, all of this gets handled by CAD packages. The only time that one might have to get down into the dirt is in something like a very tight FPGA design where certain elements are in short supply and can clever misuse of other elements can get what's needed. Anyway, for yet another try, random logic is what you get when implementing an "unclean" specification while minimizing cost and other factors. Sort of like implementing a parser for FORTRAN :-) Speaking of FORTRAN and back to Doug's comment, I'm reminded of yet another story. Some decades ago I was the author of the C language binding for GKS, an absolutely stupid standard graphics package. The original GKS only had a FORTRAN binding, and many people on the ANSI committee were working on bindings for languages that their customers actually wanted. The FORTRAN binding was pretty much what you'd expect. When I did the C binding, among other things I defined a "point" data structure to hold x,y coordinates. At one of the meetings my friend Randy from Sandia complained about it. When pressed, he said that he had a program that started by labeling a map, and it was tedious for him to have code like p.x = 10; p.y = 20; gtext(p, "label"); when in FORTRAN he could just do gtext(10, 20, "label"); Once I understood his issue, I of course had to say "Well, if I was doing a map to monitor the nuclear test ban..." (because it was always fun to have people like him and the NSA person who pretended that we didn't know what they did), I taught him how to put the coordinates and labels into a static data structure making the rest a two-line program. He went back to Sandia and started teaching his peers how to write C in C instead of doing FORTRAN in C. I think that this is somewhat analogous to Doug's comment in that there was a choice on how to write the code, and Sandia's original choice wasn't very good. But, it was a choice, not something required by the specification. Different than, for example, logic that says that "an interrupt is generated when this or that or another goes high and this enable bit is high and this mask bit is low and the global interrupt enable is high." No sensible way to implement this except as a random hunk of logic because it's a one-off. Especially if there are other interrupts such as an NMI that has completely different rules. Hope that this all helps. Jon