> [...] Many architectures get register > windows wrong, but the Itanium has a variable-length register fill/ > spill engine that gets invoked automatically. Of course, you can > program the engine too.
what's the advantage of this over the stanford style? >I also REALLY like predicated instructions. like arm? > That is, you perform an operation and then predicate the instructions > that should execute if it comes out the way you want. It really > simplifies assembly-level if/then and switch-style blocks. unless it's an 8- or 16-bit part, i don't see why anyone cares if the assembly is simplier. but since this is an epic part, the assembly is never simple. how do you get around the fact that the parallelism is limited by the instruction set and the fact that one slow sub-instruction could stall the whole instruction? > The hardware also has built-in support for closures. Every function > executed is implicitly paired with a given local memory region. what's the difference between this and stack? > There is a *lot* to like about Itanium. there's a lot not to like about itanium. epic means that instructions need to be hand-crufted. in itanium land, you schedule instructions. in x86-64 land, instructions schedule you. what's to like about that? - erik
