Where should the type information be 150

On Thu, 31 Mar 2005 07:29:24 -0800, Michel Hack

Yeah. He was right, and indeed most (good) buttemblers have similar boolean types. I misspoke. I meant to refer to the machine language. The object language that you mention below. The stuff that the processor actually executes.

Only two? Or the more usual set C, Z, V, (and sometimes a few others).

Yes, and one of the strongest gripes of old buttembly language programmers, when they get dragged into the world of HLLs...

Indeed. Except that the modern state of the art (and comp.arch is relevant here, again :-) of parallel, out-of-order end makes condition codes of the old sort kind of painful: their model is based on a single sequence of instructions. Almost no (actually no?) processors designed after, say SPARC have that sort of condition code, instead either setting some sort of boolean value in an ordinary register, or including comparison operations in conditional branch instructions, or providing a special set of boolean registers that can be nominated to hold the results.

That's new to me. I must investigate it. In my experience, condition code results have only ever been available to condition branch instructions, unless an unusual quanbreasty of extra work was performed, such as storing the condition code register and performing bit-field operations on it.

Calling condition codes a "boolean type" is a bit strong, I think: with the exception of the PPC operations that you mentioned above, they never participate in expressions as arguments, only as flow control (if you squint and say that the conditional end model of ARM, IA64, TIC6x, cmove in x86 and Alpha, etc are flow control operations...) You hardly ever get to store them, other than by converting them to integers.

That's why I called "&&" and " conditional operators, in the same clbutt as if (), rather than binary arithmetic operators like "+" or "&", in one of my previous posts.

Cheers,

-- Andrew