so in my book i have a list for v0,v1,v2, etc, does anyone know a site that has a list of all the instructions including camera normal registers etc, i need like list with the meaning to each one.

It seems you understand it wrong.

There are several types of registers, the most important are:

• input registers (v#) - for vertex shader, these registers contain individual data from the vertex declaration, for pixel shader it contains colors etc.
• temporary registers (r#) - used only in the shader calculations, are not accesible from "outside"
• constant registers (c#, b#, i#) - can be accessed by the shader and the content of these registers can be set by the calling (c++) application
• samplers (s#) - a pseudo-register for texture samplers

What will be in each VS input register (v0, v1, v2...) depends purely on the vertex declaration in the application and the vertex shader declaration in asm code (dcl_position, dcl_normal...) - these two must match. But there is no rule saying that v1 MUST be vertex normals. I don't know what does the list in your book mean, but maybe it's just an example?

Constant registers can hold any day you want. It's just a memory space for numbers, exactly as a variable in c++ code (as mhagain said). Your vertex shader will probably need some camera data (view/projection matrix, maybe eye position etc.) and you pass these data using float constant registers (c0, c1, c2...). But it's COMPLETELY up to you which particular register you use. You can put the ViewProjection matrix to registers c0-c3, or c5-c8 or c10-c13 or.... (you need 4 registers for a matrix). You just need to use the same number in the c++ aplication (SetVertexShaderConstantF) and in the shader code (hlsl or asm).

Temporary registers can also be used for anything, there's no rule. If you're using HLSL to write shaders, you won't have to deal with them at all. You hovewer will most probably have to if you want to write (or at least be able to read) the asm shader code.

The only thing I'd add to this is that with SM4+ it's no longer possible to write asm shaders directly, so this is effectively a dead programming model. All new programs, and anyone learning D3D for the first time, should just use HLSL.

Oh, I didn't know this. I've been using HLSL from the start anyway.

I agree that it's always good to at least know how to get to the asm code generated from the HLSL source and how to read it, even if you don't understand all the asm instructions. Because it can be helpfull to be able to verify two versions of a shader and see which one results in less instructions.