if (a < b && (c < d || e < f))
{
    ...
}

if_lt a, b
{
    sub t, c, d
    cmp t, t, 0, 1
    sub s, e, f
    cmp s, s, 0, 1
    add t, t, s
    if_gt t, 0.5
    {
        ...
    }
}

So far the only way I have seen is smartly using floats to represent them, is there something easier/more efficient/more direct?

If they're dynamic branches (decisions that have to be made per-pixel/vertex), then yeah, you have to use float because there are no integer/bool registers in SM3.

The best way to deal with branching is to avoid doing branching

In your example, you end up using two different branches (one nested in the other). It would likely be much better to just use a single branch, due to how expensive they are on SM3 hardware...

By the way, the reason I have recently started learning shader assembly is that I have a shader for which both Cg and HLSL require too many temporaries to run, while I know it can be done with less

Does the compiler fail due to this, or the runtime?

Usually you can massage your HLSL code to produce better asm, rather then writing the asm yourself (e.g. by using the HLSL attributes such as branch, flatten, fastopt, forcecase, call, unroll, loop, isolate, or by writing more asm-like code).

e.g. to tell the compiler to use a series of cmp instructions and arithmetic for that branch, you could try something like:

[branch]
if( 0 < step(a,b) * (step(c,d) + step(e,f)) )

...you have to use float because there are no integer/bool registers in SM3.

Then WTF is these used for?

As noted on the page that deals with how to use those (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174580(v=vs.85).aspx) that's for static flow control. i.e. not determined at the shader execution time.

1. So in some places i would like to avoid switching shaders and i see that this static bool (constant for shader execution but different on per drawcall basis) and is costing 1 instruction (it says that in docs), is it cheaper then switching shader and is it cheaper then dynamic branching?

Saturate is supported as a modifier for certain instructions. So if you do something like x = saturate(y * z), you'll end up with a mul_sat instruction in your assembly.

This actually maps to how GPU's implement saturate in their native microcode.

I just checked, but saturate as a modifier is only available from shader model 4, while I am using shader model 3. According to documentation: http://msdn.microsoft.com/en-us/library/windows/desktop/hh447231(v=vs.85).aspx

The saturate function in HLSL has been around since shader model 1.