Actually, this means that your code is relying on undefined behaviour and, while it might not bite you in this particular compiler/OS, a number of ABIs have different calling conventions for variadic and non-variadic functions and so you can end up writing code that just doesn't work with the next compiler/OS/architecture. If you're lucky. If you're unlucky, you'll write code where the compiler can detect that it's undefined behaviour and optimise it all away.

It's fairly common to have a definition like this in code:

#ifndef NDEBUG
#define DEBUG(...) __VA_ARGS__
#else
#define DEBUG(...)
#endif

You can then write:

DEBUG(int some_variable;)
...
DEBUG(some_variable = 5;)
...

If you've got code that's only used for debugging, then strip it out with the preprocessor, don't just strip half of it...

Actually, it's not faster for any compiler made in the last 20 years. There are two cases:

• You're explicitly assigning a value to the variable in every code path

• You're not explicitly assigning a value to the variable in every code path

In the first case, redundant expression elimination will just delete the initial zero store. A local value that is written and never read is easy to track. Once it's in SSA form, it just becomes a value with no uses and gets deleted trivially.

In the second case, the result changes. It's now potentially a lot faster, because the compiler will propagate the undefined value through all arithmetic in the code paths where it is not assigned, eventually get to the end and you'll find that a big chunk of your code has now been optimised into an undefined value (the compiler will just pick any register, or if you're lucky will emit an illegal instruction so that you can catch the trap in the debugger).

Initialising to zero is nice for pointers, because it guarantees that you have a trap value, so if you try to use it then you'll get a hard error, rather than memory corruption. For integers / floats, it's less clear. It would be nice for floats to be initialised to a NaN value, but most processors have no trap representation for ints.

Last time I did this exercise, Clang generated enough warnings that it took me a few days to fix them all. Most of them were undefined behaviour, which were probably safe unless the compiler is clever enough to exploit them (i.e. turn on LTO and your code won't work). A few of them were security vulnerabilities. If you don't fix the relatively benign ones, then it's hard to find the rest...

In Clang, we also try to make sure that warning messages for things that have a reasonable chance of being false positives have a little hint telling you how to suppress the warning. For example, we'll warn on if (a = b), but tell you that if you really meant this you can write if ((a = b)) and the compiler won't warn again. I think gcc has also started doing this recently.

As you say, the point of warnings is to tell you when you've done something that is probably wrong. The point of errors is to tell you when you've done something that is definitely wrong. Sometimes the correct response to a warning is to read the code, realise that it's doing something that should be permitted, and tell the compiler to suppress the warning next time.

I can't be bothered to look up a citation, but check any HCI textbook.

Computers are a really bad example of this, because there are lots of objective criteria. Things like toothpaste and shampoo are much better. Most people have no idea, given two toothpastes, if one works better than the other. There's nothing on the packets that allows making an objective judgement. So people end up buying the one with the brand that they recognise. Somewhat depressingly, studies have shown that it doesn't even matter if their association with the brand is entirely negative - if brand A has done annoying things in the past and you've never heard of brand B, most people are more likely to choose brand A.

Advertisers don't like that one though, because it's hard to track. If you run an ad campaign that raises brand awareness, then you might see a spike in sales six months later when people start to actually need a product in the category that you sell and buy yours because now they trust your brand. Or you might see a spike in sales for a completely unrelated reason (e.g. increased seasonal demand caused by unusual weather).

Yes, we've also released the generated Verilog for anyone who wants to use just that. If you're a university, you can easily get a free license for Bluespec. If you're not, then you either most likely don't have the resources to get a decent FPGA (the ones that can run a processor at a useable speed start at about $3K), or you can probably afford the license. We're also talking to Bluespec about open sourcing their compiler, as most of their real value is from other services on top of it, but that's likely to take some time.

We're evaluating CHISEL, which is promising, but currently there's nothing else in the open source world that comes even vaguely close to Bluespec in terms of productivity for hardware designers, and CHISEL was not available when we started.

It made sense for the 20% of the population who thinks of structure primarily in terms of hierarchy. This 20% has a very large overlap with programmers (not surprisingly, as most structured programming languages are innately hierarchical), but is still a small subset of the total computer-using population. This is one of the main reasons why programmers tend to be a lot worse at designing UIs for non-programmers to use than they think they are.

Because everyone has (to a first approximation) the same ability to speak. The USA has several orders of magnitude disparity in control of money.

I've never understood this about the USA, it seems to completely miss the point of unions. Here, there are often two or three unions that are competing for members, so you get the benefits of collective bargaining and the benefits of competition. Collective bargaining via a monopoly that has no incentive to represent your interests is much the same position you're in with no union at all...

The core count isn't the interesting thing about this chip. The cores themselves are pretty boring off-the-shelf parts too. I was at the ISCA presentation about this last week and it's actually pretty interesting. I'd recommend reading the paper (linked to from the press release) rather than the press release, because the press release is up to MIT's press department's usual standards (i.e. completely content-free and focussing on totally the wrong thing). The cool stuff is in the interconnect, which uses the bounded latency of the longest path multiplied by single-cycle one-hop delivery times to define an ordering, allowing you to implement a sequentially consistent view of memory relatively cheaply.

Since I'm here, I'll also throw out a plug for the work we presented at ISCA, The CHERI capability model: Revisiting RISC in an age of risk . We've now open sourced (as a code dump, public VCS coming soon) our (64-bit) MIPS softcore, which is the basis for the experimentation in CHERI. It boots FreeBSD and there are a few sitting around the place that we can ssh into and run. This is pretty nice for experimentation, because it takes about 2 hours to produce and boot a new revision of the CPU.

Where on earth have you managed to find a university that has professors in IT?

In computer science, most academics put their papers online (sometimes preprints if the journal doesn't allow distribution) on their own web sites for free. If you find the paper in the ACM Digital Library, and then search the web for the paper title, you can probably find it. In physics, arxiv.org does a good job of centralising preprints for people to search.

The problem with this approach is that you need a fairly good grounding in the field to be able to understand the papers. You can probably get it by reading books, but it's a bit hit-and miss. The point of a university education is not to teach you the field, it's to give you a guided tour of your ignorance. This then lets you identify the things that you should know and learn them.